Re: Working Group Last Call

>>>>> On Sun, 30 Oct 2005, Romascanu, Dan (Dan) wrote:
Dan> This is a Working Group Last Call announcement for the following
Dan> Internet-Drafts:
Dan>
Dan> Ethernet in the First Mile Copper (EFMCu) Interfaces MIB  -
Dan> http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-cu-mib-04.txt
Dan> Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units
Dan> (MAUs) -
Dan> http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-rfc3636bis-02.txt
Dan>
Dan> The Working Group intents to submit these documents to the IESG for
Dan> consideration as Proposed Standards. Please send your comments to the WG
Dan> mail list until November 13, 2005.

Hi Dan, I have two comments about 3636bis.  These should not in any way be
construed as "blocking" comments -- I would be OK with the document going
forward as is -- but I do think that the WG might want to consider them.

1.) The first comment concerns this:

>>>>> On Mon, 24 Oct 2005, Edward Beili wrote:
Edward> 1. Currently the values for the ifMauTypeListBits are defined in the
Edward>    IANA-MAU-MIB, while the values for the ifMauAutoNegCapabilityBits,
Edward>    ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits
Edward>    objects are defined in MAU-MIB.
Edward>    While none of the newly added MAU types (10GBASE-CX4, 2BASE-TL,
Edward>    10PASS-TS, 100BASE-LX/BX, 1000BASE-LX/BX/PX) supports
Edward>    auto-negotiation, this may change in the future (e.g. I don't see
Edward>    a reason not to support it on P2P (-LX/BX) optical links as well as
Edward>    for some new types). I suggest to put TC for these objects in the
Edward>    IANA-MAU-MIB as well.

>>>>> On Mon, 24 Oct 2005, C. M. Heard replied:
C> The WG of course has the last word but this suggestion does seem logical
C> to me.  Since the SYNTAX clauses for the three above-mentioned objects
C> are identical, a single new IANA-maintained TC would suffice.

If there is a realistic possibility that future MAU types will support
auto-negotiation, then it is probably advantageous to put the capability
list under IANA maintenance so that it (like the MAU types) can be
expanded quickly upon approval of a new 802.3 standard.  The main
counter-argument would be that doing this would lengthen an already
protracted process.  In making a decision it might be useful to solicit
input from the 802.3 WG regarding the likelihood of the introduction of
new auto-negotiation capabilities.

2.) The second comment concerns the following issue from RFC 2578
Section 7.1.4:

   As part of updating an information module, for an object defined
   using the BITS construct, new enumerations can be added or existing
   enumerations can have new labels assigned to them.  After an
   enumeration is added, it might not be possible to distinguish between
   an implementation of the updated object for which the new enumeration
   is not asserted, and an implementation of the object prior to the
   addition.  Depending on the circumstances, such an ambiguity could
   either be desirable or could be undesirable.  The means to avoid such
   an ambiguity is dependent on the encoding of values on the wire;
   however, one possibility is to define new enumerations starting at
   the next multiple of eight bits.  (Of course, this can also result in
   the enumerations no longer being contiguous.)

For the TCs in the IANA-MAU-MIB -- including the one for auto-negotiation
capabilities, if it is added -- there is clearly no reason to allocate new
enumerations at multiples of 8 bits.  The only use of IANAifMauTypeListBits 
is in defining the read-only object ifMauTypeListBits, which advertises
capabilities of the MAU.  If new enumerations are defined but the
corresponding bits are not set by an agent, it has exactly the same meaning
to a management application as if the enumerations didn't exist to the
agent, namely, that the MAU cannot be set for those types.  And if bits
are set by the agent that the manager does not know about, it just means
that the MAU supports modes that the mamager does not know about;  it is
irrelevant whether the extra bits occur on a new octet boundary or not.

The situation with ifMauAutoNegCapabilityBits and ifMauAutoNegCapReceivedBits
is the same and with ifMauTypeListBits.  It is a little different with
ifMauAutoNegCapAdvertisedBits because the object is read-write, but the
action that needs to be taken by a manager to modify the value is already
prescribed by the DESCRIPTION clauses:  it needs to read
ifMauAutoNegCapabilityBits, clear the bits for capabilities it wishes to
turn off, and then write the value back to ifMauAutoNegCapAdvertisedBits.
Allocation of newly-defined bits on 8-bit boundaries does not offer any
help in this process.

I am belaboring this point because the smidiff tool always gives a
level [3] {named-bit-added-old-byte} error message for new named bits
that are allocated in an existing byte, and some people might be
convinced by this that they need to put gaps into bit allocations for
IANAifMauTypeListBits.  We might therefore want to consider including
the following in the DESCRIPTION clause for that TC:

  New enumerations need not be allocated on a multiple of 8 bits.

The same should be done for the proposed auto-negotiation capabilities TC
if it is implemented.

Let me reiterate once again that I would have no objection of the WG
chooses not to implement either of these suggestions.  Having the
document move forward in its present form would be OK by me.

Mike