Re: RE: Last Call: Definitions of Managed Objects for IEEE 802.3 MediumAttachment Units (MAUs) to Proposed Standard (fwd)
John Flick <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
I agree with Mike's interpretation below. The "IANA" text below
has been there since the initial version of this document. We have
never had, or intended to have, an IANA registry, and we have always
allowed for proprietary MAU types, and this has been used in several
cases:
- vendors who ship products using pre-standard MAUs, or for which
the IEEE standard is done but the MIB update isn't. For example,
many vendors were shipping gigabit MAUs, and supporting the MAU
MIB for them, long before we finished RFC 2668.
- widely implemented, but non-standard MAU types. A good example
here is long-haul gigabit, for which there is no IEEE standard,
but many vendors have implemented it.
- truly proprietary MAU types. I know we have at least one of
these.
I will make the updates Mike suggests below, as well as fixing the
other outstanding nits that Mike found in March, and post a new
version today or tomorrow.
John
"C. M. Heard" wrote:
>
> 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)
>
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib