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

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



Thanks, comments inline for those points that need it.

Bert 

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
> Sent: Thursday, May 23, 2002 5:01 PM
> To: bwijnen@lucent.com
> Cc: eos@ops.ietf.org
> Subject: Re: draft-irtf-nmrg-snmp-tcp-08.txt
>
> 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.
>
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" ??


> 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.
> 
That makes me happy.

> 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.
> 
Since we do specify snmpEngineMaxMessageSize in that MIB.
And you use MUST language. Now the snmpEngineMaxMessageSize says:

       DESCRIPTION "The maximum length in octets of an SNMP message
                    which this SNMP engine can send or receive and
                    process, determined as the minimum of the maximum
                    message size values supported among all of the
                    transports available to and supported by the engine.
                   "

So if I have a UDP socket where I do not want fragmentation, then maybe
I want to set MaxMessageSize to 1472. But for TCP I MUST set if it to
8191 if I read your text correctly, so the 1472 is no longer valid
according to the description clause. 
Maybe I am just worrying too much here?

> 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".
> 
Thanks. works for me

> 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.
> 
Thanks

> 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.
> 
Looks better to me.

> 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.
> 
Thanks.

> 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.
> 
Thanks, Bert