Re: draft-irtf-nmrg-snmp-tcp-08.txt

"Wijnen, Bert (Bert)" wrote:
> 
> > Bert> - sect 2 2nd para you start to talk about a transaction.  not
> > Bert> sure it is clear to everyone what is meant by that, should
> > Bert> we/you explain a bit?
> >
> > RFC 1905 also uses the phrase "request-response transaction" on page
> > 8. I am not sure why this text is unclear or what needs to be
> > explained.
> >
> Mmm.. I think I see what bothered me.
> In RFC1905 it says "request-response transaction" which makes me
> think about a transaction that sends a request and gets back a response.
> 
> In the snmp-tcp doc I see request/response transaction where I thought
> about a request transaction or a response transaction. I guess the /
> confes (confuses) me. If you mean the same as in 1905, then I am fine
> with it. Are there others who would confuse the slash (/) to mean
> "or" ??
> 

To avoid this type of confusion and to be consistent, I'd suggest
changing to be request-response to be consistent with the earlier
document.

One other comment. I think it would be useful to include some more
discussion about how to manage the TCP connections. A suggested
practices. For instance, should a notification originator open the TCP
connection to the receiver and keep it open all of the time, or should
it only open the TCP connection when it needs to send a notification.
Similarly is there any suggestion as to how long a command generator
should keep its connection open? Should they be re-opened occassionally
or only on the framing errors as described? Or should they be
opened/closed if the polling intervals are greater than some number of
seconds? For both cases there are issues with how many simultaneous TCP
connections need to be supported for the manager.

Carl



-- 
Carl W. Kalbfleisch
NTT/VERIO
www.nttverio.com