Subject: RE: [Hubmib] IANA Maintained TC for MAU types

From: "C. M. Heard" <[email-masked]>
Date: Sun, 28 Nov 2004 17:02:05 -0800 (PST)

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

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 29 Nov 2004 10:30:47 +0100

Thanks for the review Mike.

W.r.t. the first point (i.e. does it make sense to do an IANA 
maintained MIB module) see my comment inline.

Bert

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of C. M. Heard
> Sent: Monday, November 29, 2004 02:02
> To: Hub Mib
> Subject: RE: [Hubmib] IANA Maintained TC for MAU types
> 
> 

So instead of requiring RFC2434 Standards Action, we could do a
"Specification Required" and/or "Expert Review", 
For expert review we would make sure that we check with IEEE of course.

Thinking aloud here.

Bert

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 29 Nov 2004 08:23:38 -0800 (PST)

On Mon, 29 Nov 2004, Wijnen, Bert (Bert) wrote:
> [Mike Heard wrote:]
> > [... T]he 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. 	[ ... ] 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.
> 
> "Specification Required" and/or "Expert Review", For expert
> review we would make sure that we check with IEEE of course.

Perhaps then the optimal arrangement would indeed be Expert Review,
provided that the IANA Considerations language in the MIB module
explicitly state that new MAU types are to be added when & only when
they are added to IEEE Std 802.3

In an offline e-mail on another matter, Juergen Schoenwaelder wrote:
> Regarding the MIB that triggered your email: I think this MIB module
> should be registered directly below mib-2 anyway.

I think I agree with this.  Note that it means just that as OID
value of the form { mib-2 xxx } would be assigned to the
MODULE-IDENTITY descriptor (which, BTW, should probably be
ianaMauMib rather than ianaMauTC if my module name change suggestion
is accepted);  all of the OBJECT-IDENTITY definitions would remain
as they are now.

Mike