[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thanks. I agree. see also below
I will now put revision 09 on IESG agenda for approval
to publish Experimental RFC.
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:email@example.com]
> Sent: Monday, May 27, 2002 10:27 AM
> To: firstname.lastname@example.org
> Cc: email@example.com; firstname.lastname@example.org
> Subject: Re: draft-irtf-nmrg-snmp-tcp-08.txt
> >>>>> Wijnen, Bert (Bert) writes:
> Bert> Mmm.. I think I see what bothered me. In RFC1905 it says
> Bert> "request-response transaction" which makes me think about a
> Bert> transaction that sends a request and gets back a response.
> Bert> In the snmp-tcp doc I see request/response transaction where I
> Bert> thought about a request transaction or a response transaction. I
> Bert> guess the / confes (confuses) me. If you mean the same as in
> Bert> 1905, then I am fine with it. Are there others who would confuse
> Bert> the slash (/) to mean "or" ??
> The updated ID uses request-response instead of request/response
> and so I consider the problem solved.
> 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> Since we do specify snmpEngineMaxMessageSize in that MIB. And
> Bert> you use MUST language. Now the snmpEngineMaxMessageSize says:
> Bert> DESCRIPTION "The maximum length in octets of an SNMP
> Bert> message which this SNMP engine can send or receive and process,
> Bert> determined as the minimum of the maximum message size values
> Bert> supported among all of the transports available to and supported
> Bert> by the engine. "
> Bert> So if I have a UDP socket where I do not want fragmentation,
> Bert> then maybe I want to set MaxMessageSize to 1472. But for TCP I
> Bert> MUST set if it to 8191 if I read your text correctly, so the
> Bert> 1472 is no longer valid according to the description clause.
> Bert> Maybe I am just worrying too much here?
> The intention is to say that every SNMP over TCP implementation must
> be able to accept or generate messages of a size of 8192 bytes. This
> does in my view not really affect snmpEngineMaxMessageSize since it is
> defined "as the minimum of the maximum message size values supported
> among all of the transports available". So in your example, the value
> of snmpEngineMaxMessageSize would be 1472.
> Still, an application which uses SNMP over TCP can rely on 8192 bytes
> since this is what the SNMP over TCP transport mapping guarantees you.
> Can you agree with this?
Yep, after re-reading the description clause once more, I see what
you say and agree.
> Juergen Schoenwaelder