RE: 484 octet limit (was: new feature in smilint?)

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

My views/comments

- I am not checking (is anyone) if a single object does fit in
  a single 484 octet SNMP message. I guess if such is required or
  not depends a lot on the MIB module and the environment. I 
  believe there are lots of environments where 1472 octet SNMP
  messages are fine, and even where 4K or 8K SNMP messages are
  fine. So... to follow the strict rule (CLR ??) to tell people
  to split objects in max 256 octet chuncks ???

- When people define normal tables with normal RowStatus, I do
  not check for SNMP message size for a SET createAndGo either.
  It is when people refine the RowStatus SYNTAX in the 
  MODULE-COMPLIANCE statement to make support for "createAndWait.
  notReady (and sometimes for notInService) not reuired.
  I then check if the PDU and SNMP Message will fit in 494 octets.
  If they do then fine, if not, I bring it up as a possible
  issue to at least consider and make a conscious decision if one
  wants that or not.

Hope this helps. 
I know that Keith indeed would be much more "disciplined" as he 
calls it. 
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: dinsdag 2 september 2003 19:36
> To: Mreview (E-mail)
> Subject: Re: 484 octet limit (was: new feature in smilint?)
> 
> 
> On Tue, 2 Sep 2003, Wijnen, Bert (Bert) wrote:
> > [Juergen Schoenwaelder wrote:]
> > > Perhaps we should just declare 484 dead. :-)
> > > 
> > I thought we tried that a year or so ago when we were defining
> > snmpEngineMaxMessageSize ???  If I remember correctly we were
> > trying to go for 1472 or something like that as a minimum.
> > I remember a lot of resistance...
> 
> I think you are right, unfortunately.  But I also think that in
> practice we have a lot of MIB modules that simply won't work with
> agents (or mamagers) that enforce such a limit.  Anything with a
> sufficiently large OCTET STRING would cause such an agent or manager 
> to break (cf. LongUtf8String from RFC 2287).  I know our documents
> still say 484, but is it a problem worth worrying about in practice?
> The MIB review guidelines document is silent on this point, and I
> know that it's not something I look for in MIB reviews;  do I need
> to mend my ways and/or fix the guidelines document?
> 
> //cmh
> 
>