RE: IANA Maintained TC for MAU types

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 protected] 
> [mailto:[email protected]]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
> 
> 
> 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.
> 

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

> 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 protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
>