Re: Latest rfc3636bis draft
C. M. Heard <heard <at> pobox.com>
2005-04-17 03:10:13 GMT
On Sat, 16 Apr 2005, Edward Beili wrote:
> I've submitted the latest draft of the rfc3636bis. I've implemented most of
> the changes you've suggested in the past, except for two:
>
> a) leaving dot3MauType* definitions in the MAU-MIB, changing each from
> an OBJECT-IDENITY definition to a simple OBJECT IDENTIFIER value
> assignment;
> and
> b) registering ianaMau module directly under mib-2
>
> For item a) I couldn't find any MIB that imports dot3MauType*
> definitions.
I have not found any either, however, my search was not reallu
exhaustive. The RFC Editor's Content Search tool pretty much
assures us that there are no such IMPORTS in standard MIB modules,
but it's much harder to track down proprietary modules. That said,
the web search engines I tried did not turn up anything.
> The method you have suggested creates a lot of warnings
> from the compiler.
What warnings and from which compiler? Send me details off-line. A
bug report might be in order, since the practice it is complaining
about is specifically permitted by RFC 2578 Section 3.6.
> As an alternative I was thinking may be we should
> leave the current dot3MauType* OBJECT-IDENITY definitions in the
> MAU-MIB and define equivalent dot3MauType* in the IANA-MAU-MIB as
> Textual Convention values. What do you think?
I am not sure what you mean, since you cannot define OBJECT
IDENTIFIER values with TEXTUAL-CONVENTIONs, only types.
If you mean to put OBJECT-IDENTITY definitions into both places,
that will not work. OBJECT-IDENTITY is a construct that "registers"
an OID, and only one registration is allowed (see RFC 2578 Section
3.6).
Although moving the OBJECT-IDENTITY definitions is not allowed under
a strict reading of SMIv2 rules for revising MIB modules, I can be
persuaded that it is justified in this case, and the MIB review
guidelines do allow for such exceptions, provided that they are
thoroughly documented. I'll have to review the new draft to see if
this exception is adequately documented.
> For the item b) - would it break some particular SNMP
> application, which would be looking for dot3MauType under
> snmpDot3MauMgt?
If some particular application expects the OIDs in a MIB module
to be related to the MODULE-IDENTITY value in some way -- e.g.,
that the MODULE-IDENTITY value is a prefix to every other OID in
the module -- then that application would be broken by the
EthernetLike-MIB, which has
etherMIB MODULE-IDENTITY
[ ... ]
::= { mib-2 35 }
etherMIBObjects OBJECT IDENTIFIER ::= { etherMIB 1 }
dot3 OBJECT IDENTIFIER ::= { transmission 7 }
with most of the objects under dot3.
Now, what you have in new IANA modues is:
ianaMauMIB MODULE-IDENTITY
[ ... ]
::= { mib-2 snmpDot3MauMgt(26) 7 } -- mauMod+1
dot3MauType OBJECT IDENTIFIER ::= { mib-2 snmpDot3MauMgt(26) 4 }
The problem with doing stuff like this is that it violates the
principle of least surprise ... a maintainer is likely to assume
that that the MAU-MIB will contain all of the under snmpDot3MauMgt,
since that is the usual practice. If a new one is needed the usual
practice is to allocate the next one that isn't defined. That
causes problems if that node resides in another MIB module,
unbeknownst to to the maintainer. That was the main reason for
suggesting a direct registration under mib-2.
However, the same objective can be achieved if in the MAU-MIB's
ASN.1 commentary you make it clear that the above nodes are defined
elsewhere. I'll look at the new draft to see if that's been done.
Dan, in view of the fact that a new draft has come in, would you
consider extending the last call period by, say, one week?
Thanks,
Mike
RSS Feed