[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmp over tcp

----- Original Message ----- 
From: "Juergen Schoenwaelder" <schoenw@ibr.cs.tu-bs.de>
To: <glenn@cysol.co.jp>
Cc: <eos@ops.ietf.org>
Sent: Monday, April 08, 2002 6:52 PM
Subject: Re: snmp over tcp

> >>>>> Glenn Mansfield Keeni writes:
> Glenn> Juergen, The document is nicely done. A few minor comments.
> Glenn> You seem to have left unconfirmed traps out of the purview of
> Glenn> the draft - is this intentional ? Section 2 mentions
> Glenn> specifically about "request/response transaction" only.
> The purpose of the text you seem to refer to is to say that
> request/response transactions must happen over the same transport and
> that the initiator chooses the transport. We do not talk about
> unconfirmed traps here since it is more or less obvious that only the
> sender can choose the transport for these messages.
Ah ! I was mislead by the subsequent paragraphh which says 
"In general, originators of request/response transactions are free to
   use the transport they assume is the best in a given situation."
Trap senders have a choice too :-)
I would think that it is simpler to say that "the SNMP entity in role of
command generator or notification originator [ref rfc 2571] chooses the 
transport.protocol. The SNMP entity in the role of comand responder or 
notification receiver MUST NOT change the transport protocol. "
> Glenn> I think that we would do well with a word about "transaction"
> Glenn> and SNMP timers (application specific timers is probably
> Glenn> better).  [ I do not think that these have been discussed in
> Glenn> any of the SNMP documents]
> Please propose concrete text and explain why it is needed to implement
> SNMP over TCP. Note that this is not the document to describe things
> that you might find missing in other SNMP documents.
Avoid all references to transaction. Regarding the timers how about 
something like 
"it is recommended that applications are properly configured so that 
application specific timers do not timeout before the corresponding 
TCP timers have expired." ?
> Glenn> Ant then, the following substitutions may be better page 4
> Glenn> paragraph 1 s/per/by/ page 4 paragraph 2 s/coincide/align/
> Agreed. Fixed in my XML sources.