Re: [Hubmib] [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt)
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Sun, 29 July 2012 05:59 UTC
Return-Path: <dromasca@avaya.com>
X-Original-To: hubmib@ietfa.amsl.com
Delivered-To: hubmib@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6107721F8608; Sat, 28 Jul 2012 22:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.424
X-Spam-Level:
X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGntdBzrJMBK; Sat, 28 Jul 2012 22:59:00 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id C52B221F8600; Sat, 28 Jul 2012 22:58:59 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFACbPFFDGmAcF/2dsb2JhbABCA7lfgQeCIAEBAQEDAQEBDx4KMgICAgcMBAIBCA0BAwQBAQEKBgwHBAEGASYfCQgBAQQBCQkIDA6HXAMMC5x8kkIIiVOLUBsMgxqCQWADll2EaYoQgmGBVgc
X-IronPort-AV: E=Sophos;i="4.77,674,1336363200"; d="scan'208";a="359422546"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Jul 2012 01:55:06 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Jul 2012 01:54:40 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 29 Jul 2012 07:58:54 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0407E23D32@307622ANEX5.global.avaya.com>
In-Reply-To: <CC3A3460.2446B%ietfdbh@comcast.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt)
Thread-Index: Ac1tRBsmSiJfjROwTDK3bQwANp9FewACpIeQ
References: <EDC652A26FB23C4EB6384A4584434A0407E23D23@307622ANEX5.global.avaya.com> <CC3A3460.2446B%ietfdbh@comcast.net>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: David Harrington <ietfdbh@comcast.net>, Michael MacFaden <mrm@vmware.com>, bclaise@cisco.com, adslmib@ietf.org, hubmib@ietf.org
Cc: hfrazier@broadcom.com, ops-area@ietf.org
Subject: Re: [Hubmib] [OPS-AREA] 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: Sun, 29 Jul 2012 05:59:01 -0000
Hi David, Of course existing management applications will not interoperate as-is and will need to be changed in order to work with the new IEEE 802.3 MIB modules. Did anybody claim differently? Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Sunday, July 29, 2012 7:39 AM > To: Romascanu, Dan (Dan); Michael MacFaden; bclaise@cisco.com; > adslmib@ietf.org; hubmib@ietf.org > Cc: hfrazier@broadcom.com; ops-area@ietf.org > Subject: Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB > Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) > > Hi, > > The original email said: > > > > 2. A table mapping the old IETF MIB names with the corresponding > new > > IEEE ones > > From RFC2578, section 10: > As experience is gained with an information module, it may be > desirable to revise that information module. However, changes are > not allowed if they have any potential to cause interoperability > problems "over the wire" between an implementation using an original > specification and an implementation using an updated > specification(s). > > and: > Note that changing the descriptor associated with an existing object > is considered a semantic change, as these strings may be used in an > IMPORTS statement. > > > > And: > if the semantics of any previously defined object are > changed (i.e., if a non-editorial change is made to any clause other > than those specifically allowed above), then the OBJECT IDENTIFIER > value associated with that object must also be changed. > > > So if the name will be changed, then the associated OID must be changed, > And interoperability will be harmed by changing the descriptor or the > OID. > > Implementations using the old mib module and implementations using the > new mib module will likely have interoperability problems if the > descriptor, the OID, or the semantics of an object are changed. > > Tread carefully ... > > > -- > David Harrington > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > On 7/28/12 9:09 PM, "Romascanu, Dan (Dan)" <dromasca@avaya.com> wrote: > > >I understand and I sympathize with the concern expressed by David and > >Mike. All the good comments made by David need to be taken into > >consideration in the writing of the future RFC. At the same time we > >(the IETF shrinking community that was once developing MIB modules for > >IEEE > >802 technologies) need to complete the process of transition to the > >respective IEEE 802 Working Groups. This includes in my opinion > >deprecating the IETF MIB modules and making the RFCs historical. Maybe > >the moment is not now, but in 1, 5, or 10 years, but that time will > >come (and may be different for hubmib and bridgemib). > > > >Concerning David's question: > > > >> Is there a ***technical*** reason that forces a reassignment of OIDs > >> per > >> SMIv2 rules, and obsolescence of the IETF MIB modules? > > > >I do not believe that we are talking about a reassignment of OIDs, but > >only of obsolescence of the MIB modules. The reason is not technical, > >but merely sending the clear signal to implementers of the Ethernet or > >Bridge MIB technologies where they need to look for the latest versions > >of the MIB modules. The IETF decided to get out of this business, and > >no more MIB modules for Ethernet or Bridging are being developped (and > >for all practical matters maintained) in the IETF - this is the > >reality. The address for the latest Ethernet or IEEE 802.1 MIB modules > is the IEEE. > > > >Regards, > > > >Dan > > > >> -----Original Message----- > >> From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On > >> Behalf Of Michael MacFaden > >> Sent: Saturday, July 28, 2012 8:38 AM > >> To: bclaise@cisco.com; adslmib@ietf.org; hubmib@ietf.org; > >> ietfdbh@comcast.net > >> Cc: hfrazier@broadcom.com; ops-area@ietf.org > >> Subject: Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific > >> MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) > >> > >> I second David's concerns. Process mapping could also be made clear. > >> > >> So far I have been able to implement both IETF and IEEE bridge mib > >> modules it's less clear how to devine the IEEE maturity model or > >> where to provide implementation feedback reports. > >> > >> Dan did answer questions on the overall doctors list at one point > >> which helped. > >> > >> Mike MacFaden > >> > >> > >> Sent from my Android phone using TouchDown (www.nitrodesk.com) > >> > >> > >> -----Original Message----- > >> From: David Harrington [ietfdbh@comcast.net] > >> Received: Friday, 27 Jul 2012, 9:55pm > >> To: Benoit Claise [bclaise@cisco.com]; adslmib mailing list > >> [adslmib@ietf.org]; hubmib@ietf.org > >> CC: Howard Frazier [hfrazier@broadcom.com]; ops-area@ietf.org > >> Subject: Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific > >> MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) > >> > >> > >> Hi, > >> > >> I think there are many implementations of these mib modules. > >> Applications know where to find these data objects by the existing > OIDs. > >> > >> In the Bridge MIB case, the IETF standards remained standards, so > >> existing implementations were still compliant to the IETF standard. > >> The IETF Bridge mib modules were widely deployed and used in > >> Enterprise bridging. > >> The structure of the IEEE Bridge modules were modified for technical > >> reasons - the indexing needed to be changed to accommodate > >> per-provider bridging. > >> So the IEEE developed a mib module that used the new indexing, which > >> was a superset of the old IETF MIB design. > >> This change required reassignment of OIDs, per SMIv2 rules. This is > >> described in RFC4663 section 3.2. > >> So the IETF Bridge MIB(s) and IEEE Bridge MIB(s) are actually > >> different MIB modules, both are existing valid standards, and they > can coexist. > >> > >> You don't discuss the justifications for changing the names and OID > >> assignments for existing objects. > >> Expecting all devices and NMS applications to do a forklift upgrade > >> just to declare these objects to be in the IEEE tree would make > little sense. > >> Many legacy device implementations will never be upgraded, so NMS > >> applications will need to continue to support the IETF MIB modules. > >> Obsoleting these existing standards should have a strong > justification. > >> Is there a ***technical*** reason that forces a reassignment of OIDs > >> per > >> SMIv2 rules, and obsolescence of the IETF MIB modules? > >> > >> RFC4663 does not actually transfer the Bridge MIBs to IEEE; it merely > >> describes the process that was followed to transfer the Bridge MIBs > >> to IEEE. > >> Copyright for existing MIB module documents are held by the original > >> authors (not by the IETF). > >> The authors typically have granted the IETF the right to publish, > >> copy, translate, etc. for IETF standardization purposes. > >> The exact rights depend on the state of the IPR policy at time of > >> document publication. > >> The IETF does not have the authority to transfer these rights to the > >> IEEE. > >> As described in RFC4663 3.1, the authors must agree to allow the IEEE > >> to copy and make derivative works from the original documents. > >> If the authors have assigned all intellectual property to their > >> employers, then the companies must agree. > >> Have all the original authors been contacted and have they (and their > >> companies) agreed to grant IEEE these rights? > >> > >> > >> Many NMS tools import text versions of MIB documents; they typically > >> cannot extract and import MIB modules from PDFs. > >> Will IEEE make subsequent 802.3 MIB documents freely available in > >> text formats? > >> This was done for the 802.1 MIB modules. > >> > >> If the IEEE will extend the existing MIB modules, within the 1.3.6.1 > >> branch, I believe they will need to have the new OIDs assigned by > IANA. > >> > >> There are quite a few issues with doing this type of transfer, and I > >> recommend documenting the process and the constraints on future > >> development, so future contributors understand the issues and how to > >> deal with them. > >> > >> > >> -- > >> David Harrington > >> Ietfdbh@comcast.net > >> +1-603-828-1401 > >> > >> > >> > >> > >> > >> On 7/27/12 7:13 PM, "Benoit Claise" <bclaise@cisco.com> wrote: > >> > >> > > >> > > >> > > >> > > >> > > >> > > >> > 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 <http://tools.ietf.org/html/rfc5066>. > >> > > >> > > >> > 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 5066. > >> > 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, > >> >http://grouper.ieee.org/groups/802/3/1/index.html > >> > > >> > > >> > > >> > 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, reviews > >> > 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.) > >> > > >> > > >> > > >> > > >> > > >> > > >> >_______________________________________________ > >> >OPS-AREA mailing list > >> >OPS-AREA@ietf.org > >> >https://www.ietf.org/mailman/listinfo/ops-area > >> > >> > >> _______________________________________________ > >> OPS-AREA mailing list > >> OPS-AREA@ietf.org > >> https://www.ietf.org/mailman/listinfo/ops-area >
- [Hubmib] IEEE/IETF relationship on Ethernet-speci… Benoit Claise
- Re: [Hubmib] [OPS-AREA] IEEE/IETF relationship on… Romascanu, Dan (Dan)
- Re: [Hubmib] [OPS-AREA] IEEE/IETF relationship on… Romascanu, Dan (Dan)
- Re: [Hubmib] [OPS-AREA] IEEE/IETF relationship on… David Harrington
- Re: [Hubmib] [OPS-AREA] IEEE/IETF relationship on… Michael MacFaden
- Re: [Hubmib] [OPS-AREA] IEEE/IETF relationship on… David Harrington
- Re: [Hubmib] [OPS-AREA] IEEE/IETF relationship on… Howard Frazier