RE: Last Call: Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) to Proposed Standard (fwd)

Hub MIB folks --

Dan Romascanu asked me to forward the following message to the list.
The context of the discussion was a last call comment raised by the
IANA representative on the MAU-MIB regarding the following language
in the DESCRIPTION clauses of rpMauType and ifMauType:

  This object identifies the MAU type.  An initial set of MAU types
  are defined above.  The assignment of OBJECT IDENTIFIERs to new
  types of MAUs is managed by the IANA.

The issue raised by the IANA representative is that the above
language by itself does not provide any instructions on how to
administer MAU type assignments.

Despite the above language (which has been around since RFC 1515)
MAU type assignments for IEEE 802 standard have been historically
been managed by the working group.  The solution proposed below is
to reword the DESCRIPTION clauses to remove the "is managed by the
IANA" language.

Comments from other WG members are solicited.

Regards,

Mike Heard

---------- Forwarded message ----------
Date: Wed, 28 May 2003 09:56:58 -0700 (PDT)
From: C. M. Heard <[email protected]>
To: "Wijnen, Bert (Bert)" <[email protected]>
Cc: John Flick <[email protected]>,
     "Dan Romascanu (E-mail)" <[email protected]>, IANA <[email protected]>
Subject: RE: Last Call: Definitions of Managed Objects for IEEE 802.3 Medium
    Attachment Units (MAUs) to Proposed Standard

On Wed, 28 May 2003, Wijnen, Bert (Bert) wrote:
> Mmm... strange that I overlooked this.

Apparently we all did.

> I guess we (probably the WG) need to decide how we want to
> handle this. Seems like we have these choices:
> 
> a.We ask IANA to keep a registry under dot3MauType, in which
>   case we need to add an IANA Considerations section to explain
>   how to make new assignments. If we choose for this one, we might
>   be better of to make it an IANA maintained MIB Module.
> b.We state that new values can only be created by Standards Action
>   (as per RFC2434) and then we're basically done. Seems IANA need to
>   do nothing in this case. We could wonder if we want IANA
>   to administer these and make a public list of the assignments (to
>   make it easier in the future to recognize if conflicts would arise).
>   If so we need to tell them about that in IANA consoderations
>   If not, we may want to remove all IANA related text I think.
> c.Seems we have only been adding new values in this document itself.
>   So we could mention that the only valid values are 0.0 and the
>   ones listed within this MIB module. In that case there is also
>   no IANA considerations and we may want to remove the IANA text.
> 
> So... did we intend to ever allow other MIB modules to make
> MauType assignments? Did we intend to allow proprietary 
> MauTypes (e.g. OIDs that we do not control al all?)

Bert,

We probably want something a little different from any of these
alternatives.

In practice, the WG always has to manage the standard (i.e., IEEE
802.3) MAU type assignments since adding a new standard MAU type
requires that a corresponding bit position be defined for
ifMauTypeListBits. The language "assignment of OBJECT IDENTIFIERs to
new types of MAUs is managed by the IANA" in the DESCRIPTION clauses
of rpMauType and ifMauType dates all the way back to RFC 1515, but
it seems to be historical since (i) no IANA MAU type registry was
ever created (or if it was, I can't find any evidence of it now) and
(ii) the WG has been managing all new standard MAU types that have
appeared in the various revisions of the MAU-MIB (RFC 2239, RFC
2668, and the present document).  This has been a practical
necessity since the type list object ifMauTypeList (now replaced by
ifMauTypeListBits) was introduced in RFC 2239.

It was (and I think still is) the intent to allow non-standard MAU
types.  The DESCRIPTION clause for ifMauTypeListBits says:

           DESCRIPTION "A value that uniquely identifies the set of
                       possible IEEE 802.3 types that the MAU could be.
                       If auto-negotiation is present on this MAU, this
                       object will map to ifMauAutoNegCapabilityBits.

                       Note that this MAU may be capable of operating
                       as a MAU type that is beyond the scope of this
                       MIB.  This is indicated by returning the
                       bit value bOther in addition to any bit values
                       for capabilities that are listed above."

In view of this, I think the correct course of action would be:

(i) remove the language "assignment of OBJECT IDENTIFIERs to new
types of MAUs is managed by the IANA" and instead of saying that an
initial set of values is defined , say that values for standard IEEE
802.3 MAU types are defined;

(ii) inform the IANA that we don't need for them to create or
maintain an MAU type registry ... in fact we don't need for them to
do anything at all with respect to this document.

Here are the specific wording changes that I propose.

Change the DESCRIPTION clause of rpMauType as follows:

FROM:
           DESCRIPTION "This object identifies the MAU type.  An
                       initial set of MAU types are defined above.  The
                       assignment of OBJECT IDENTIFIERs to new types of
                       MAUs is managed by the IANA.  If the MAU type is
                       unknown, the object identifier

                       unknownMauType OBJECT IDENTIFIER ::= { 0 0 }

                       is returned.  Note that unknownMauType is a
                       syntactically valid object identifier, and any
                       conformant implementation of ASN.1 and the BER
                       must be able to generate and recognize this
                       value."

TO:
           DESCRIPTION "This object identifies the MAU type.  Values for
                       standard IEEE 802.3 MAU types are defined above.
                       If the MAU type is unknown, the object identifier

                       unknownMauType OBJECT IDENTIFIER ::= { 0 0 }

                       is returned.  Note that unknownMauType is a
                       syntactically valid object identifier, and any
                       conformant implementation of ASN.1 and the BER
                       must be able to generate and recognize this
                       value."

and change the DESCRIPTION clause of ifMauType as follows:

FROM:
           DESCRIPTION "This object identifies the MAU type.  An
                       initial set of MAU types are defined above.  The
                       assignment of OBJECT IDENTIFIERs to new types of
                       MAUs is managed by the IANA.  If the MAU type is
                       unknown, the object identifier

                       unknownMauType OBJECT IDENTIFIER ::= { 0 0 }

                       is returned.  Note that unknownMauType is a
                       syntactically valid object identifier, and any
                       conformant implementation of ASN.1 and the BER
                       must be able to generate and recognize this
                       value.

                       This object represents the operational type of
                       the MAU, as determined by either (1) the result
                       of the auto-negotiation function or (2) if
                       auto-negotiation is not enabled or is not
                       implemented for this MAU, by the value of the
                       object ifMauDefaultType.  In case (2), a set to
                       the object ifMauDefaultType will force the MAU
                       into the new operating mode."

TO:
           DESCRIPTION "This object identifies the MAU type.  Values for
                       standard IEEE 802.3 MAU types are defined above.
                       If the MAU type is unknown, the object identifier

                       unknownMauType OBJECT IDENTIFIER ::= { 0 0 }

                       is returned.  Note that unknownMauType is a
                       syntactically valid object identifier, and any
                       conformant implementation of ASN.1 and the BER
                       must be able to generate and recognize this
                       value.

                       This object represents the operational type of
                       the MAU, as determined by either (1) the result
                       of the auto-negotiation function or (2) if
                       auto-negotiation is not enabled or is not
                       implemented for this MAU, by the value of the
                       object ifMauDefaultType.  In case (2), a set to
                       the object ifMauDefaultType will force the MAU
                       into the new operating mode."

With those changes there would be no mention of IANA in the
document.  Note that this will still allow an enterprise to manage
equipment with proprietary MAU types;  the OID values to identify
the proprietary MAU types would be assigned under the enterprise's
OID tree and would not require any external coordination (other than
to get an enterprise number in the first place).

Comments?

Mike Heard

> > -----Original Message-----
> > From: IANA [mailto:[email protected]]
> > Sent: dinsdag 27 mei 2003 20:42
> > To: [email protected]
> > Cc: [email protected]
> > Subject: RE: Last Call: Definitions of Managed Objects for IEEE 802.3
> > Medium Attachment Units (MAUs) to Proposed Standard
> > 
> > 
> > IESG:
> > 
> > The IANA has reviewed the following Internet-Draft which is 
> > in Last Call: <draft-ietf-hubmib-mau-mib-v3-03.txt>, and 
> > has the following comments with regards to the publication of 
> > this document:
> > 
> > It is not clear what this document is requesting the IANA 
> > do.  Clarification is needed.
> > 
> > Please respond to the IANA about our concerns with regards to this
> > document.  Failing to do so may cause delay of the approval and
> > publication of your document.
> > 
> > Thank you.
> > 
> > Michelle S. Cotton
> > (on behalf of the IANA)