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

>>>>> Wijnen, Bert (Bert) writes:

Bert> Questions/comments

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.

Bert> - sect 2 last para talks about "SNMP timers to fire..."  not
Bert> sure that everyone immediately understands what is meantg here.

I have changed "SNMP timers" to "SNMP retransmission timers" in case
that was the problem. If you are concerned about the verb, please note
that other protocols such as OSPF version 2 (RFC 2328) also talk about
timers that fire.

Bert> - sect 2.2 last para Does this have an impact on FRAMEWORK-MIB?
Bert> Or how does it relate to that?  Might be good to explain.  

I have no idea why you think the message size affects the
SNMP-FRAMEWORK-MIB.

Bert> You talk about being able to "accept messages of at least 8192
Bert> octets". Could someone interpret that you are not required to be
Bert> able to send them? Nitpicking I guess

I changed "accepting" to "accepting and generating".

Bert> - sect 2.3 last para Maybe it is better to speak about
Bert> "confirmed operations" instead of "confirmed requests" ??

I have replaced "confirmed requests" with "confirmed operations" as
suggested.

Bert> - 1st para on page 6.  you claim that a response to an inform
Bert> indicates that the notification was delivered to a notification
Bert> receiver application.  I believe we had a lot of discussion on
Bert> this back in the SNMPv3 WG days... and I am not sure that we all
Bert> agree that that would necessarily be the case. I think we said
Bert> the response indicates that the inform was received and
Bert> processed by the SNMP engine but it could have been just queued
Bert> up for a notification receiver application to be dispatched
Bert> after the response has been generated.

I replaced "delivered to" with "queued for delivery to" to make this
subtle point clearer. With some additional editoral changes, the
revised paragraph becomes:

   With a confirmed SNMP operation, the receiving SNMP engine
   acknowledges that the data was actually received.  Depending on the
   SNMP protocol operation, a confirmation may indicate that further
   processing was done.  For example, the response to an inform-request
   protocol operation indicates to the notification originator that the
   notification passed the transport, the security model and that it was
   queued for delivery to the notification receiver application.
   Similarily, the response to a set-request indicates that the data
   passed the transport, the security model and that the write request
   was actually processed by the command responder.

Bert> - sect 3.  I wonder if it would not be better to uppercase the 2
Bert> cases of recommended to RECOMMENDED. This to make use of
Bert> security a much stronger recommendation.
  
No problem with this suggested change.

Due to some offline comments from an implementor, I also added a
clarification that the TCP connection SHOULD be closed when the
receiver looses framing (e.g. due to ASN.1 parse errors).

I will submit a new ID with these changes in place.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>