Hi Eliot,
I have, of course, read the draft that you cited below, but the term
"call home" is not defined or used in that draft...
The document does discuss the concept that either end of the SNMP
exchange could initiate the BEEP connection at the transport level,
but I don't see that it explains anywhere how/when/why a command
responder would _decide_ (or even know how) to contact a command
requestor and/or how a command responder could find a command
requestor if it were not at a fixed, globally addressable location.
IMO, there is a lot more to building a system that is capable of SNMP
initiation in both directions than simply having a mechanism to
set-up the transport connection from the command responder to the
command generator. It would also be possible to set-up an SSH
connection from either end, but I don't see how that even begins to
offer the benefits that you've attributed to "call home".
None of this seems very material to the ISMS discussion, though...
Today SNMP (whether it is running over UDP or TCP) doesn't have the
call home feature. Do you really think it is reasonable to tie the
addition of that feature to the definition of a new security
mechanism for the existing SNMP protocol? If so, why?
IMO, we need to try to do our work in manageable chunks in the right
groups/areas. A security area working group working on a new
security mechanism for the existing SNMP model is one chunk. Perhaps
an OPS area WG working on an optional SNMP call home mechanism is
another...? I don't see how the level of change/disruption to the
vendor community is substantially affected by whether these two
separate mechanisms are defined in one IETF working group or two.
Margaret
At 2:52 PM +0200 9/12/05, Eliot Lear wrote:
Margaret Wasserman wrote:
If you really believe that this solution is needed, I think you would do
best to write a draft and _then_ try to get it adopted by an appropriate
WG.
I (amongst others) *did*. draft-kaushik-isms-btsm-01.txt. What had
been missing up until this point was an SSH draft. And the working
group developed consensus on this non-existent draft. You've got to be
impressed.
Eliot
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf