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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf