Randy,
Regardless of whether "call home functionality" as you defined it is
desirable, I disagree with the claim that it wouldn't represent a
major architectural change to SNMP. For notification originators, it
is a quite natural extension, and I have no problem with it. For command
responders, I think this would be a fairly significant addition to the
architecture.
I'm neutral on the question of whether it is needed, and perhaps we only
differ in what we perceive as "major", but I think we need to be clear that
it would indeed require changing the SNMP architecture.
There is a difference between a connection and a request. Reversing the
transport connection direction doesn't say that we reverse request
directions or notification directions. Quite the contrary. They stay
the same. To me that means no substantial change over what is already
proposed.
Indeed the currently envisioned approach guarantees that either
notifications or requests will be broken because one connection will
initiate in one direction and another will initiate in the reverse. FTP
all over again, as I said.
I also disagree that it is the use of SSH or TCP that results in the
architectural
changes. TCP use without "call home" (as in RFC 3430) requires no
architectural changes.
Clearly since SSH is now carrying authentication information there is a
substantial change, where SNMP inherits bonafides from the process
below. That is not the case in 3430.
Eliot
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf