RE: IANA Maintained TC for MAU types

On Tue, 26 Oct 2004, Edward Beili wrote:
> I've submitted the first revision of MAU-MIB -
> draft-ietf-hubmib-rfc3636bis-00 available at:
> http://www.actelis.com/efm/

I have finally (on account of the recent holiday) had an opportunity
to read this document.  Sorry for the long delay.  Other WG
participants please note: this draft has not been posted to the I-D
repository and much be accessed from the URL given above.

Before I get into technical issues, there is an important "just why
are we doing this" issue that I need to raise.  Specifically, the
draft as currently written requires a Standards Action (as defined
in RFC 2434) in order to make modifications to the proposed
IANA-maintained MIB module.  That, I think, is the right thing to
do, since we want the MAU types (and jack types) defined in that
module to be in sync with what is standardized by the IEEE.  On the
other hand, it does mean that prior to adding any MAU types (or jack
types) it will be necessary to get WG consensus and IESG approval to
have a standards-track RFC published.  It seems to me that very
little time or effort will be saved compared to doing what we do
now, namely getting WG consensus and IESG approval to issue a new
revision of the MAU-MIB.  If we cared about not recycling the
MAU-MIB at Proposed Standard, there would be a difference, but I do
not think that most WG participants care much about that. So before
we move forward with the proposed IANA-maintained MIB module I
suggest that we ask ourselves whether doing so will actually
accomplish the intended purpose -- viz., to get the IETF MAU-related
MIB updated to reflect revisions to IEEE 802.3 in a more timely and
efficient manner than we have done heretofore.  I have my doubts.

Setting those doubts aside for the moment, I will now comment on
some technical issues.

> As far as I can tell no publically available MIBs import
> dot3MauType OBJECT-IDENTITIES. However, if there is a problem, I
> would suggest to import from IANA-MAU-TC-MIB all
> OBJECT-IDENTITIES available in todays rfc3636 into the new
> MAU-MIB.

In looking over the draft I see that it is not just the dot3MauType*
OBJECT-IDENTITY definitions that are to be migrated from the MAU-MIB
to the IANA-maintained MIB module but also the JackType
TEXTUAL-CONVENTION definition.  I did an on-line search of my own
for any MIB modules (IETF or otherwise) that might import these
definitions, and I did not find any either.  However, my search of
non-IETF MIB modules can hardly be considered exhaustive, and I did
find the following enterprise MIB modules that import things from
the MAU-MIB:

http://www.enterasys.com/support/relnotes/SSR-E9191-MIB.txt
http://www.assure24.com/download/mibs/privatemibs/11/hpicf8023Rptr.mib
http://www.assure24.com/download/mibs/privatemibs/5812/port.mib

Fortunately, we do not need to take the risk of breaking anyone's
MIB module, since there is a way to accomplish the objectives
without losing backward compatibility.  It will not do to just
IMPORT the descriptors from the IANA-maintained MIB module, since
IMPORTS does not work recursively.  However, the following strategy
will work:

(a) in the MAU-MIB, change each of the dot3MauType* definitions from
an OBJECT-IDENITY definition to a simple OBJECT IDENTIFIER value
assignment;

(b) leave the JackType textual convention in the MAU-MIB, changing
its STATUS calue to 'deprecated', and call the new TC in the
IANA-maintained module something like IanaJackType;  then in the
MAU-MIB, use IanaJackType in place of JackType in the appropriate
object definitions.

Note that this will allow any existing MIB module that might have
IMPORTed the JackType TC or any of the dot3MauType* descriptors from
the MAU-MIB to continue to compile without changes, but will also
allow the migration to take place.  The duplicate definitions of the
dot3MauType* descriptors may draw warnings from some MIB compilers,
but they are perfectly legal under the following clause of RFC 2578
(it is in the last paragraph of Section 3.6):

   A descriptor is allowed to be associated with both a registration
   and an assignment, providing both are associated with the same
   OBJECT IDENTIFIER value and semantics.

As additional issues, I see that the maintenance instructions in the
proposed IANA-maintained MIB module do not mention jack types, and
it lacks the standard copyright notice mandated by RFC 3667.

Finally, I would suggest that if we go forward with this that the
name of the new IANA-maintained be IANA-MAU-MIB rather than
IANA-MAU-TC-MIB since it does contain definitions other than just
TCs.  I have sent versions of the MAU-MIB and IANA-MAU-MIB that
contain the changes described above to the draft author in an
off-line e-mail.  They generate a lot of noise from smilint but with
the appropriate switches will compile cleanly with SMICng.

One administrative issue I should mention is that the draft will
need to have a separate IANA Considerations section in order to pass
IESG muster.  See Section 3.7.1 of the MIB review guidelines
document for relevant guidelines.

> Also, while changing description of rpMauType and ifMauType, I
> noticed a text reference to unknownMauType OBJECT IDENTIFIER ::=
> { 0 0 }, which is never defined anywhere in the MIB. I suggest
> to import existing zerDotZero object from SNMPv2-SMI (defined as
> {0 0}), and adding DEFVAL { zeroDotZero } to rpMauType and
> ifMauType.

That seems to me to be a reasonable thing to do (regardless of
whether or not an IANA-maintained MIB module is created).  However,
since DEFVAL is only advisory, I would recommend retaining some
version of the existing language in the DESCRIPTION clause
(referring perhaps to zeroDotZero).

Regards,

Mike