Margaret Wasserman wrote:
Hi Mike,
At 8:41 AM -0700 9/7/05, Michael Thomas wrote:
In answer to Margaret's question about how it would know
where to "call home", it seems to me to be about the same
problem as with traps/informs. I haven't had anything to do
with this wg, but it seems pretty plausible that you'd
initiate the session from the agent using a trap/inform
over tcp/ssh/whatever and then just reuse the connection
for subsequent pdu's sort of akin to http 1.1 reuse. It
would just all sort of fall out of the overall snmp
architecture.
So, every time a notification sender sends a trap or notification it
would set-up a TCP connection to each of the notification receivers in
its list and keep that connection up indefinitely? Would it reestablish
ithose connections when they fail? How long would it keep a connections
up if it never receives a command request on that particular
connection? Please remember that not all notification receivers _are_
command requestors, and not all command requestors are notification
receivers.
I think there's a fair amount of room between "never" and
"indefinitely" on how/when to keep a connection up. As I
mentioned, http 1.1 seems to handle this and if nothing
else we certain have a lot of data about its efficacy.
I do think that if you built a mechanism for a command responder to open
a connection to a command requestor, the MIB for configuring the new
mechanism might resemble the MIB that is used to determine notifications
should be sent, but I don't think that it will be identical and I do not
think that the current MIB should be overloaded in this way.
Correct me if I'm wrong, but I thought that http 1.1 was
pretty spartan on any sort of settings and/or negotiation
of the kinds of parameters you brought up. That is, each
side decides for itself what those values ought to be, and
the provisioning of them is out of scope. Since the web is
essentially an any-any kind of environment, is there some
reason to believe that a more restrictive relationship --
as one would expect manager to managed to be -- would bring
new or different considerations than we already have a lot of
experience with?
BTW, nothing about your note explains to me why you think that this
mechanism should be defined in a Security area WG that is working on a
completely separable problem. If you really think that defining call
home for SNMP is something that the IETF should do, I would encourage
you to get together with Eliot and request a BOF in the OPS area.
That's because I haven't formed an opinion on it. My main point
is that this doesn't seem to me to be any sort of wildly divergent
architectural proposition, at least on the front of who "initiates"
a connection. As Harald pointed out, I really can't see how you'd
prevent some industrious developers from using SNMP in this way
regardless of how the working group is chartered, and from that
standpoint it might be better to get ahead of the ball on it if
it were inevitable, and it does seem to have a fair number of
security considerations.
The question I have for Eliot though is why he believes that SNMP
is the right vehicle for this kind of "call home" functionality
in the first place. Maybe it's my own prejudice, but SNMP seems
a little klunky for what I'd envision "call home" is trying
to achieve.
Mike
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf