Re: 484 octet limit (was: [802.1] MSTP MIB - mstpMapTable)

["C. M. Heard" <heard@pobox.com>]

[ Catching up on post-vacation e-mail ]

MIB Doctors,

I see that the issue of the 484 octet minimum SNMP msgMaxSize for
the preferred UDP transport has arisen in connection with the
mstpMapTable definition in the 802.1 MSTP MIB.  This topic, and how
it relates to the MIB review guidelines document, has been discussed
before on the mreview list.  Here are (hopefully representative)
excerpts of what I found in the archives.

>>>>> On Wed, 26 Feb 2003, Keith McCloghrie wrote (in a forwarded message):
KZM> I was just asked to advise/adjudicate between a (local) MIB submitter
KZM> who wants to use:
KZM> 
KZM>   OCTET STRING (SIZE(0..480))
KZM> 
KZM> and a (local) MIB reviewer who is working with a set of guidelines
KZM> which say that OCTET STRINGs should be limited to a maximum length of
KZM> 255 octets.
KZM> 
KZM> So, I thought I'd check out what it says in:
KZM> 
KZM>    draft-ietf-ops-mib-review-guidelines-01.txt
KZM> 
KZM> unfortunately, it wasn't very helpful.  It only says OCTET STRINGs must
KZM> be more restrictive than (0..65535), and includes among the examples:
KZM> (0..1024)
KZM> 
KZM> In the past, I have advised people to split a (fixed-length) string of
KZM> 1024 octets into multiple objects, e.g, four objects each of length
KZM> 256 octets.
KZM> 
KZM> The rationale for this, of course, is the 484-octet message length,
KZM> and I note that this is still maintained in RFCs 3411, 3412 and 3417.
KZM> The community didn't bite the bullet and say: SNMPv3 agents MUST
KZM> support messages of size 1472 octets.  As a result, MIB objects which
KZM> will not fit in a 484-byte message are not implementable by all
KZM> SNMP-compliant agents.  It is undoubtedly a bad idea to allow MIBs to
KZM> be defined that are not implementable by an SNMPv3-compliant agent.

This message did not (as far as I could tell) elicit any replies, but
the discussion arose again somewhat later, in the context of when the
484 octet limit would be an impediment to create-and-go operations in
dynamic tables:

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

>>>>> On Tue, 2 Sep 2003, Wijnen, Bert (Bert) replied:
BW> My views/comments:
BW> 
BW> - I am not checking (is anyone) if a single object does fit in
BW>   a single 484 octet SNMP message. I guess if such is required or
BW>   not depends a lot on the MIB module and the environment. I 
BW>   believe there are lots of environments where 1472 octet SNMP
BW>   messages are fine, and even where 4K or 8K SNMP messages are
BW>   fine. So... to follow the strict rule (CLR ??) to tell people
BW>   to split objects in max 256 octet chuncks ???
BW> 
BW> - When people define normal tables with normal RowStatus, I do
BW>   not check for SNMP message size for a SET createAndGo either.
BW>   It is when people refine the RowStatus SYNTAX in the 
BW>   MODULE-COMPLIANCE statement to make support for "createAndWait.
BW>   notReady (and sometimes for notInService) not reuired.
BW>   I then check if the PDU and SNMP Message will fit in 494 octets.
BW>   If they do then fine, if not, I bring it up as a possible
BW>   issue to at least consider and make a conscious decision if one
BW>   wants that or not.
BW> 
BW> Hope this helps. 
BW> I know that Keith indeed would be much more "disciplined" as he 
BW> calls it. 

The version of the MIB review guidelines that is now in the RFC Editor's queue,
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-04.txt,
remains silent on these matters.  It focuses exclusively on SMIv2 issues and
does not discuss problems that can arise from message size constraints in the
underlying protocol.  It does not refer to RFC 3412 or RFC 3417.

In the recent discussion the following proposal was aired:

>>>>> On Thu, 8 Sep 2005, Juergen Schoenwaelder wrote:
JS> If something should be added to the guidelines, then I think we should
JS> suggest something along the lines what Bert said:
JS>
JS>   MIB module authors should carefully check what the minimum message
JS>   requirements for a given MIB module are. In general, SNMP is only
JS>   guaranteed to support message sizes of 484 bytes over the default
JS>   UDP transport [RFC3417]. If the 484 byte maximum message size
JS>   constraint is too tight for a given application domain, MIB module
JS>   authors must state in the MIB module description that
JS>   implementations must support larger message sizes. Note that
JS>   [RFC3417] recommends that SNMP engines support message sizes up to
JS>   1472 bytes and so it might be viable for a given MIB module to
JS>   assume messages sizes up to 1472 bytes. However, assuming message
JS>   sizes above 1472 bytes is discouraged since such message sizes are
JS>   very likely to cause IP layer fragmentation.

This strikes me as a reasonable proposal, but it (or the alternative
of requiring all standard MIBs to be implementable by the least
capable SNMPv3-compliant agent) would represent a change in the way
we do business, and so (in my opinion) should not be added to the
document without going through a new last call.

My question, then is this:  is the problem sufficiently important to
warrant recalling the MIB review guidelines document from the RFC
Editor's queue and going through another last call?

Mike