Re: ISMS working group and charter problems

[Eliot Lear <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf