[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
To me what was left out of the specification was the addition of MIB
objects to manage running SNMP over TCP. There could be configuration
objects, such as how long to keep open connections after no activity, etc.
Stats, such as how many connections were opened and closed, number
of bytes sent over connections, etc. Error counts, such as number
of times a connection was terminated due to ASN.1 parse errors, etc.
The approach as to what to add should follow the normal approach, that is,
define the minimal number of objects and notifications such that
there are clearly defined uses to determine if operation is OK,
and if not, then to change the configuration to make operation OK.
At 05:45 PM 5/24/2002 -0500, Carl W. Kalbfleisch wrote:
>"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
>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 W. Kalbfleisch
/david t. perkins