[Hubmib] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt)

Benoit Claise <bclaise@cisco.com> Fri, 27 July 2012 23:13 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: hubmib@ietfa.amsl.com
Delivered-To: hubmib@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 75D2C11E80F2; Fri, 27 Jul 2012 16:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.373
X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fL3bVgzvFSzc; Fri, 27 Jul 2012 16:13:19 -0700 (PDT)
Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 91E8711E80C4; Fri, 27 Jul 2012 16:13:19 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from fire.cisco.com (localhost.cisco.com []) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6RNDIei000366; Fri, 27 Jul 2012 16:13:18 -0700 (PDT)
Received: from [] (sjc-vpn3-247.cisco.com []) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6RNDIU4005875; Fri, 27 Jul 2012 16:13:18 -0700 (PDT)
Message-ID: <5013208E.6020608@cisco.com>
Date: Fri, 27 Jul 2012 16:13:18 -0700
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: adslmib mailing list <adslmib@ietf.org>, hubmib@ietf.org
Content-Type: multipart/alternative; boundary="------------070800000707090109030301"
Cc: Ron Bonica <rbonica@juniper.net>, Howard Frazier <hfrazier@broadcom.com>, ops-area@ietf.org
Subject: [Hubmib] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt)
X-BeenThere: hubmib@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Ethernet Interfaces an Hub MIB WG <hubmib.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hubmib>, <mailto:hubmib-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hubmib>
List-Post: <mailto:hubmib@ietf.org>
List-Help: <mailto:hubmib-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2012 23:13:22 -0000

Dear all,

While DISCUSSing draft-ietf-adslmib-gbond-eth-mib-06.txt with the IESG, 
an issue was brought up. Let me explain.

The IETF is no longer developing any Ethernet-related MIB modules and 
has transferred the responsibility of these development of MIB modules 
for Ethernet to the IEEE 802.3 WG. This process has already started a 
few years ago, when the HUBMIB WG was shut down. This process also 
covers the last RFC produced by the HUBMIG WG, RFC 5066 - Ethernet in 
the First Mile Copper (EFMCu) Interfaces MIB 

This RFC5066 contains two MIB modules
1. the EFM-CU-MIB MIB module (Ethernet to the First Mile Copper), 
clearly Ethernet-specific
2. the IF-CAP-STACK MIB module is not Ethernet-specific, but generic
     For example, draft-ietf-adslmib-gbond-eth-mib-07.txt refers to this 
MIB module.

However, according to the agreement, it is within the IEEE competence to 
develop the IEEE8023-IF-CAP-STACK-MIB in 802.3.1 rather than refer RFC 
The issue was raised that it didn't make sense to refer to the 
IEEE8023-IF-CAP-STACK-MIB when this cross-connect functionality is not 
used for Ethernet, and that the reference RFC5056 was actually preferred.

This week, we had an IEEE/IESG meeting where this issue was discussed 
between Dan Romascanu (as the IEEE liaison), Howard Frazier (802.3.1) 
and myself.
The following has been agreed upon: the EFM-CU-MIB MIB module should be 
maintained by IEEE, while the IF-CAP-STACK-MIB should be maintained by 
the IETF.
Practically, it means:
1. Obsoleting RFC 5066
2. Creating RFC 5066bis. Extracting IF-CAP-STACK-MIB from RFC5056, with 
some wording emphasizing the generic nature of this module, and clearly 
mentioning that the IEEE 802.3.1 is responsible for EFM-CU-MIB.
     Ed Beili agreed to take the lead on this document.
3. The next version of draft-ietf-adslmib-gbond-eth-mib will contain the 
following text

    4.4 Relationship with the IEEE 802.3 MIB modules

    The IEEE 802.3 working group chartered a task force [IEEE802.3.1] which
    continues the development of standard MIB modules based on the initial
    work done in the IETF.  Future projects resulting from the work of this
    Task Force may include and possibly extend the work done in the IETF,
    such as [RFC5066].


    To Informative References add:

    [IEEE802.3.1] IEEE P802.3.1 Revision to IEEE Std 802.3.1-2011 (IEEE
    802.3.1a) Ethernet MIBs Task Force,

Thanks to Howard Frazier. Edward Beili, Menachem Dodge, Dan Romascanu, 
and Moti Morgenstern for helping with this issue. This shows an 
inter-SDO success story IMHO.

A second document has also been discussed.
It would be a good idea to have an informational RFC, similar to RFC 
4663 - Transferring MIB Work from IETF Bridge MIB WG to IEEE ... 
<http://tools.ietf.org/html/rfc4663>, with the following content.
1. Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011

    RFC 2108 -- Ethernet Repeater Devices
    RFC 3621 - Power Ethernet MIB
    RFC 3635 - Ethernet-like Interface Types
    RFC 3637 - Ethernet WAN Interface Sublayer
    RFC 4836 - Ethernet Medium Attachment Units (MAUs)
    RFC 4837 - Ethernet Passive Optical Networks (EPON)
    RFC 4878 - Operations, Administration, and Maintenance (OAM)
    Functions on Ethernet-Like Interfaces
    RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

2. A table mapping the old IETF MIB names with the corresponding new 
IEEE ones
3. Clarifications/rules on the IETF-IEEE interactions, mailing lists, 
4. Clarifications on the intellectual property considerations

Next to Dan and Ed, Howard agrees to co-author this document. And that 
sends a strong positive signal.

There is one open issue though with this second document: should we send 
to historic all the MIB modules mentioned above? What would be the 
impact for the equipment vendors and NMS applications?
Dan Romascanu will present this issue at the OPS-AREA meeting.

Finally, regarding the future cooperation between the IEEE and IETF 
regarding the development of the 802.3.1-2011, Howard Frazier mentioned 
that any feedback could be sent directly to him, and that he would 
insert it into the ballot.

Regards, Benoit (OPS A.D.)