From bclaise@cisco.com Fri Jul 27 16:13:22 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) 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-Level: 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [171.68.227.119]) 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 [127.0.0.1]) 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 [10.21.64.247] (sjc-vpn3-247.cisco.com [10.21.64.247]) 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 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 , hubmib@ietf.org Content-Type: multipart/alternative; boundary="------------070800000707090109030301" Cc: Howard Frazier , ops-area@ietf.org Subject: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 23:13:22 -0000 This is a multi-part message in MIME format. --------------070800000707090109030301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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 ... , 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.) --------------070800000707090109030301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 ..., 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.)




--------------070800000707090109030301-- From ietfdbh@comcast.net Fri Jul 27 21:55:03 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5589B21F8498 for ; Fri, 27 Jul 2012 21:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, 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 ofukTY+-+mH6 for ; Fri, 27 Jul 2012 21:55:02 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id D0C9621F8444 for ; Fri, 27 Jul 2012 21:55:01 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id fgtv1j0031uE5Es55gv4hm; Sat, 28 Jul 2012 04:55:04 +0000 Received: from [10.59.1.23] ([71.233.85.150]) by omta16.westchester.pa.mail.comcast.net with comcast id fgv71j00V3Ecudz3cgv9G8; Sat, 28 Jul 2012 04:55:11 +0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Sat, 28 Jul 2012 00:54:56 -0400 From: David Harrington To: Benoit Claise , adslmib mailing list , Message-ID: Thread-Topic: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) In-Reply-To: <5013208E.6020608@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Howard Frazier , 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) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 04:55:03 -0000 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" wrote: > > =20 > > =20 > =20 > =20 > Dear all, > =20 > While DISCUSSing draft-ietf-adslmib-gbond-eth-mib-06.txt with the > IESG, an issue was brought up. Let me explain. > =20 > 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 >. > =20 > =20 > 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. > =20 > 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. > =20 > 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 > =20 > 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 > =20 > > =20 > 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. > =20 > =20 > 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 ... >, > with the following content. > 1. Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011 > =20 > RFC 2108 =AD 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 > =20 > > 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 > =20 > Next to Dan and Ed, Howard agrees to co-author this document. And > that sends a strong positive signal. > =20 > 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. > =20 > 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. > =20 > =20 > Regards, Benoit (OPS A.D.) > =20 > =20 > =20 > =20 > =20 > >_______________________________________________ >OPS-AREA mailing list >OPS-AREA@ietf.org >https://www.ietf.org/mailman/listinfo/ops-area From mrm@vmware.com Fri Jul 27 22:38:02 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FFD11E8086; Fri, 27 Jul 2012 22:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, 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 4iGKQKnP9ePn; Fri, 27 Jul 2012 22:38:01 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id D61AE21F86C3; Fri, 27 Jul 2012 22:38:01 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 0713228E70; Fri, 27 Jul 2012 22:38:01 -0700 (PDT) Received: from zimbra-prod-mta-2.vmware.com (zimbra-prod-mta-2.vmware.com [10.113.160.174]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 02FA7B0346; Fri, 27 Jul 2012 22:38:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-prod-mta-2.vmware.com (Postfix) with ESMTP id E91FE24485; Fri, 27 Jul 2012 22:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra-prod-mta-2.vmware.com Received: from zimbra-prod-mta-2.vmware.com ([127.0.0.1]) by localhost (zimbra-prod-mta-2.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng3QozOREeh4; Fri, 27 Jul 2012 22:38:00 -0700 (PDT) Received: from zimbra-prod-mbox-2.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zimbra-prod-mta-2.vmware.com (Postfix) with ESMTP id CC5BB24413; Fri, 27 Jul 2012 22:38:00 -0700 (PDT) To: bclaise@cisco.com,adslmib@ietf.org,hubmib@ietf.org,ietfdbh@comcast.net From: Michael MacFaden Date: Fri, 27 Jul 2012 22:38:00 -0700 (PDT) X-Mailer: TouchDown X-Mailer: Zimbra 7.2.0_GA_2669 (MobileSync - TouchDown(MSRPC)/7.3.00015/) MIME-Version: 1.0 Message-ID: <2065366559.5993353.1343453880726.JavaMail.root@zimbra-prod-mbox-2.vmware.com> Content-Type: multipart/mixed;boundary="__1343453877857TOUCHDOWN_BOUNDARY__" Cc: hfrazier@broadcom.com, ops-area@ietf.org Subject: Re: [OPS-AREA] =?utf-8?q?IEEE/IETF_relationship_on_Ethernet-specific_?= =?utf-8?q?MIB_Modules_=28was_DISCUSS_on_draft-ietf-adslmib-gbond-eth-mib-?= =?utf-8?q?07=2Etxt=29?= X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 05:38:03 -0000 --__1343453877857TOUCHDOWN_BOUNDARY__ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I second David's concerns. Process mapping could also be made clear.=20 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.=20 Dan did answer questions on the overall doctors list at one point which hel= ped.=20 Mike MacFaden=20 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.o= rg]; hubmib@ietf.org CC: Howard Frazier [hfrazier@broadcom.com]; ops-area@ietf.org Subject: Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Mod= ules (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" wrote: > > =20 > > =20 > =20 > =20 > Dear all, > =20 > While DISCUSSing draft-ietf-adslmib-gbond-eth-mib-06.txt with the > IESG, an issue was brought up. Let me explain. > =20 > 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 >. > =20 > =20 > 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. > =20 > 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. > =20 > 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 > =20 > 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 > =20 > > =20 > 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. > =20 > =20 > 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 ... >, > with the following content. > 1. Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011 > =20 > RFC 2108 =C2=AD 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 > =20 > > 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 > =20 > Next to Dan and Ed, Howard agrees to co-author this document. And > that sends a strong positive signal. > =20 > 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. > =20 > 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. > =20 > =20 > Regards, Benoit (OPS A.D.) > =20 > =20 > =20 > =20 > =20 > >_______________________________________________ >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 --__1343453877857TOUCHDOWN_BOUNDARY__-- From dromasca@avaya.com Sat Jul 28 18:09:39 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66EE21F86D6; Sat, 28 Jul 2012 18:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, 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 KyNWqi4syYam; Sat, 28 Jul 2012 18:09:38 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id DA27D21F86D3; Sat, 28 Jul 2012 18:09:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFaMFFCHCzI1/2dsb2JhbABCA4VzsnJ6gQeCIAEBAQECAQEBAQ8RDQQ6AgIHBQcEAgEIDQQEAQEBAgIGBgwHBAECAgIBASUfCQgBAQQBCQkIDA6HXAMGBguceIoeiDkIiVOBIYovGwyDGoIPMmADll2EaYoQgmGBVg X-IronPort-AV: E=Sophos;i="4.77,673,1336363200"; d="scan'208";a="20106675" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 28 Jul 2012 21:04:20 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Jul 2012 20:49:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 29 Jul 2012 03:09:33 +0200 Message-ID: In-Reply-To: <2065366559.5993353.1343453880726.JavaMail.root@zimbra-prod-mbox-2.vmware.com> 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: Ac1sgyzDr2pUi9ueR9qN5HwJWX0a8QAoe82w References: <2065366559.5993353.1343453880726.JavaMail.root@zimbra-prod-mbox-2.vmware.com> From: "Romascanu, Dan (Dan)" To: "Michael MacFaden" , , , , 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) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 01:09:40 -0000 SSB1bmRlcnN0YW5kIGFuZCBJIHN5bXBhdGhpemUgd2l0aCB0aGUgY29uY2VybiBleHByZXNzZWQg YnkgRGF2aWQgYW5kIE1pa2UuIEFsbCB0aGUgZ29vZCBjb21tZW50cyBtYWRlIGJ5IERhdmlkIG5l ZWQgdG8gYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uIGluIHRoZSB3cml0aW5nIG9mIHRoZSBm dXR1cmUgUkZDLiBBdCB0aGUgc2FtZSB0aW1lIHdlICh0aGUgSUVURiBzaHJpbmtpbmcgY29tbXVu aXR5IHRoYXQgd2FzIG9uY2UgZGV2ZWxvcGluZyBNSUIgbW9kdWxlcyBmb3IgSUVFRSA4MDIgdGVj aG5vbG9naWVzKSBuZWVkIHRvIGNvbXBsZXRlIHRoZSBwcm9jZXNzIG9mIHRyYW5zaXRpb24gdG8g dGhlIHJlc3BlY3RpdmUgSUVFRSA4MDIgV29ya2luZyBHcm91cHMuIFRoaXMgaW5jbHVkZXMgaW4g bXkgb3BpbmlvbiBkZXByZWNhdGluZyB0aGUgSUVURiBNSUIgbW9kdWxlcyBhbmQgbWFraW5nIHRo ZSBSRkNzIGhpc3RvcmljYWwuIE1heWJlIHRoZSBtb21lbnQgaXMgbm90IG5vdywgYnV0IGluIDEs IDUsIG9yIDEwIHllYXJzLCBidXQgdGhhdCB0aW1lIHdpbGwgY29tZSAoYW5kIG1heSBiZSBkaWZm ZXJlbnQgZm9yIGh1Ym1pYiBhbmQgYnJpZGdlbWliKS4gDQoNCkNvbmNlcm5pbmcgRGF2aWQncyBx dWVzdGlvbjogDQoNCj4gSXMgdGhlcmUgYSAqKip0ZWNobmljYWwqKiogcmVhc29uIHRoYXQgZm9y Y2VzIGEgcmVhc3NpZ25tZW50IG9mIE9JRHMgcGVyDQo+IFNNSXYyIHJ1bGVzLCBhbmQgb2Jzb2xl c2NlbmNlIG9mIHRoZSBJRVRGIE1JQiBtb2R1bGVzPw0KDQpJIGRvIG5vdCBiZWxpZXZlIHRoYXQg d2UgYXJlIHRhbGtpbmcgYWJvdXQgYSByZWFzc2lnbm1lbnQgb2YgT0lEcywgYnV0IG9ubHkgb2Yg b2Jzb2xlc2NlbmNlIG9mIHRoZSBNSUIgbW9kdWxlcy4gVGhlIHJlYXNvbiBpcyBub3QgdGVjaG5p Y2FsLCBidXQgbWVyZWx5IHNlbmRpbmcgdGhlIGNsZWFyIHNpZ25hbCB0byBpbXBsZW1lbnRlcnMg b2YgdGhlIEV0aGVybmV0IG9yIEJyaWRnZSBNSUIgdGVjaG5vbG9naWVzIHdoZXJlIHRoZXkgbmVl ZCB0byBsb29rIGZvciB0aGUgbGF0ZXN0IHZlcnNpb25zIG9mIHRoZSBNSUIgbW9kdWxlcy4gVGhl IElFVEYgZGVjaWRlZCB0byBnZXQgb3V0IG9mIHRoaXMgYnVzaW5lc3MsIGFuZCBubyBtb3JlIE1J QiBtb2R1bGVzIGZvciBFdGhlcm5ldCBvciBCcmlkZ2luZyBhcmUgYmVpbmcgZGV2ZWxvcHBlZCAo YW5kIGZvciBhbGwgcHJhY3RpY2FsIG1hdHRlcnMgbWFpbnRhaW5lZCkgaW4gdGhlIElFVEYgLSB0 aGlzIGlzIHRoZSByZWFsaXR5LiBUaGUgYWRkcmVzcyBmb3IgdGhlIGxhdGVzdCBFdGhlcm5ldCBv ciBJRUVFIDgwMi4xIE1JQiBtb2R1bGVzIGlzIHRoZSBJRUVFLiANCg0KUmVnYXJkcywNCg0KRGFu DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3BzLWFyZWEtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm9wcy1hcmVhLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFs ZiBPZiBNaWNoYWVsIE1hY0ZhZGVuDQo+IFNlbnQ6IFNhdHVyZGF5LCBKdWx5IDI4LCAyMDEyIDg6 MzggQU0NCj4gVG86IGJjbGFpc2VAY2lzY28uY29tOyBhZHNsbWliQGlldGYub3JnOyBodWJtaWJA aWV0Zi5vcmc7DQo+IGlldGZkYmhAY29tY2FzdC5uZXQNCj4gQ2M6IGhmcmF6aWVyQGJyb2FkY29t LmNvbTsgb3BzLWFyZWFAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPUFMtQVJFQV0gSUVFRS9J RVRGIHJlbGF0aW9uc2hpcCBvbiBFdGhlcm5ldC1zcGVjaWZpYyBNSUINCj4gTW9kdWxlcyAod2Fz IERJU0NVU1Mgb24gZHJhZnQtaWV0Zi1hZHNsbWliLWdib25kLWV0aC1taWItMDcudHh0KQ0KPiAN Cj4gSSBzZWNvbmQgRGF2aWQncyBjb25jZXJucy4gUHJvY2VzcyBtYXBwaW5nIGNvdWxkIGFsc28g YmUgbWFkZSBjbGVhci4NCj4gDQo+IFNvIGZhciAgSSBoYXZlIGJlZW4gYWJsZSB0byBpbXBsZW1l bnQgYm90aCBJRVRGIGFuZCBJRUVFIGJyaWRnZSBtaWINCj4gbW9kdWxlcyBpdCdzIGxlc3MgY2xl YXIgaG93IHRvIGRldmluZSB0aGUgSUVFRSBtYXR1cml0eSBtb2RlbCBvciB3aGVyZQ0KPiB0byBw cm92aWRlIGltcGxlbWVudGF0aW9uIGZlZWRiYWNrIHJlcG9ydHMuDQo+IA0KPiBEYW4gZGlkIGFu c3dlciBxdWVzdGlvbnMgb24gdGhlIG92ZXJhbGwgZG9jdG9ycyBsaXN0IGF0IG9uZSBwb2ludCB3 aGljaA0KPiBoZWxwZWQuDQo+IA0KPiBNaWtlIE1hY0ZhZGVuDQo+IA0KPiANCj4gU2VudCBmcm9t IG15IEFuZHJvaWQgcGhvbmUgdXNpbmcgVG91Y2hEb3duICh3d3cubml0cm9kZXNrLmNvbSkNCj4g DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYXZpZCBIYXJyaW5n dG9uIFtpZXRmZGJoQGNvbWNhc3QubmV0XQ0KPiBSZWNlaXZlZDogRnJpZGF5LCAyNyBKdWwgMjAx MiwgOTo1NXBtDQo+IFRvOiBCZW5vaXQgQ2xhaXNlIFtiY2xhaXNlQGNpc2NvLmNvbV07IGFkc2xt aWIgbWFpbGluZyBsaXN0DQo+IFthZHNsbWliQGlldGYub3JnXTsgaHVibWliQGlldGYub3JnDQo+ IENDOiBIb3dhcmQgRnJhemllciBbaGZyYXppZXJAYnJvYWRjb20uY29tXTsgb3BzLWFyZWFAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPUFMtQVJFQV0gSUVFRS9JRVRGIHJlbGF0aW9uc2hpcCBv biBFdGhlcm5ldC1zcGVjaWZpYyBNSUINCj4gTW9kdWxlcyAod2FzIERJU0NVU1Mgb24gZHJhZnQt aWV0Zi1hZHNsbWliLWdib25kLWV0aC1taWItMDcudHh0KQ0KPiANCj4gDQo+IEhpLA0KPiANCj4g SSB0aGluayB0aGVyZSBhcmUgbWFueSBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlc2UgbWliIG1vZHVs ZXMuDQo+IEFwcGxpY2F0aW9ucyBrbm93IHdoZXJlIHRvIGZpbmQgdGhlc2UgZGF0YSBvYmplY3Rz IGJ5IHRoZSBleGlzdGluZyBPSURzLg0KPiANCj4gSW4gdGhlIEJyaWRnZSBNSUIgY2FzZSwgdGhl IElFVEYgc3RhbmRhcmRzIHJlbWFpbmVkIHN0YW5kYXJkcywgc28NCj4gZXhpc3RpbmcgaW1wbGVt ZW50YXRpb25zIHdlcmUgc3RpbGwgY29tcGxpYW50IHRvIHRoZSBJRVRGIHN0YW5kYXJkLg0KPiBU aGUgSUVURiBCcmlkZ2UgbWliIG1vZHVsZXMgd2VyZSB3aWRlbHkgZGVwbG95ZWQgYW5kIHVzZWQg aW4gRW50ZXJwcmlzZQ0KPiBicmlkZ2luZy4NCj4gVGhlIHN0cnVjdHVyZSBvZiB0aGUgSUVFRSBC cmlkZ2UgbW9kdWxlcyB3ZXJlIG1vZGlmaWVkIGZvciB0ZWNobmljYWwNCj4gcmVhc29ucyAtIHRo ZSBpbmRleGluZyBuZWVkZWQgdG8gYmUgY2hhbmdlZCB0byBhY2NvbW1vZGF0ZSBwZXItcHJvdmlk ZXINCj4gYnJpZGdpbmcuDQo+IFNvIHRoZSBJRUVFIGRldmVsb3BlZCBhIG1pYiBtb2R1bGUgdGhh dCB1c2VkIHRoZSBuZXcgaW5kZXhpbmcsIHdoaWNoIHdhcw0KPiBhIHN1cGVyc2V0IG9mIHRoZSBv bGQgSUVURiBNSUIgZGVzaWduLg0KPiBUaGlzIGNoYW5nZSByZXF1aXJlZCByZWFzc2lnbm1lbnQg b2YgT0lEcywgcGVyIFNNSXYyIHJ1bGVzLiBUaGlzIGlzDQo+IGRlc2NyaWJlZCBpbiBSRkM0NjYz IHNlY3Rpb24gMy4yLg0KPiBTbyB0aGUgSUVURiBCcmlkZ2UgTUlCKHMpIGFuZCBJRUVFIEJyaWRn ZSBNSUIocykgYXJlIGFjdHVhbGx5IGRpZmZlcmVudA0KPiBNSUIgbW9kdWxlcywgYm90aCBhcmUg ZXhpc3RpbmcgdmFsaWQgc3RhbmRhcmRzLCBhbmQgdGhleSBjYW4gY29leGlzdC4NCj4gDQo+IFlv dSBkb24ndCBkaXNjdXNzIHRoZSBqdXN0aWZpY2F0aW9ucyBmb3IgY2hhbmdpbmcgdGhlIG5hbWVz IGFuZCBPSUQNCj4gYXNzaWdubWVudHMgZm9yIGV4aXN0aW5nIG9iamVjdHMuDQo+IEV4cGVjdGlu ZyBhbGwgZGV2aWNlcyBhbmQgTk1TIGFwcGxpY2F0aW9ucyB0byBkbyBhIGZvcmtsaWZ0IHVwZ3Jh ZGUganVzdA0KPiB0byBkZWNsYXJlIHRoZXNlIG9iamVjdHMgdG8gYmUgaW4gdGhlIElFRUUgdHJl ZSB3b3VsZCBtYWtlIGxpdHRsZSBzZW5zZS4NCj4gTWFueSBsZWdhY3kgZGV2aWNlIGltcGxlbWVu dGF0aW9ucyB3aWxsIG5ldmVyIGJlIHVwZ3JhZGVkLCBzbyBOTVMNCj4gYXBwbGljYXRpb25zIHdp bGwgbmVlZCB0byBjb250aW51ZSB0byBzdXBwb3J0IHRoZSBJRVRGIE1JQiAgbW9kdWxlcy4NCj4g T2Jzb2xldGluZyB0aGVzZSBleGlzdGluZyBzdGFuZGFyZHMgc2hvdWxkIGhhdmUgYSBzdHJvbmcg anVzdGlmaWNhdGlvbi4NCj4gSXMgdGhlcmUgYSAqKip0ZWNobmljYWwqKiogcmVhc29uIHRoYXQg Zm9yY2VzIGEgcmVhc3NpZ25tZW50IG9mIE9JRHMgcGVyDQo+IFNNSXYyIHJ1bGVzLCBhbmQgb2Jz b2xlc2NlbmNlIG9mIHRoZSBJRVRGIE1JQiBtb2R1bGVzPw0KPiANCj4gUkZDNDY2MyBkb2VzIG5v dCBhY3R1YWxseSB0cmFuc2ZlciB0aGUgQnJpZGdlIE1JQnMgdG8gSUVFRTsgaXQgbWVyZWx5DQo+ IGRlc2NyaWJlcyB0aGUgcHJvY2VzcyB0aGF0IHdhcyBmb2xsb3dlZCB0byB0cmFuc2ZlciB0aGUg QnJpZGdlIE1JQnMgdG8NCj4gSUVFRS4NCj4gQ29weXJpZ2h0IGZvciBleGlzdGluZyBNSUIgbW9k dWxlIGRvY3VtZW50cyBhcmUgaGVsZCBieSB0aGUgb3JpZ2luYWwNCj4gYXV0aG9ycyAobm90IGJ5 IHRoZSBJRVRGKS4NCj4gVGhlIGF1dGhvcnMgdHlwaWNhbGx5IGhhdmUgZ3JhbnRlZCB0aGUgSUVU RiB0aGUgcmlnaHQgdG8gcHVibGlzaCwgY29weSwNCj4gdHJhbnNsYXRlLCBldGMuIGZvciBJRVRG IHN0YW5kYXJkaXphdGlvbiBwdXJwb3Nlcy4NCj4gVGhlIGV4YWN0IHJpZ2h0cyBkZXBlbmQgb24g dGhlIHN0YXRlIG9mIHRoZSBJUFIgcG9saWN5IGF0IHRpbWUgb2YNCj4gZG9jdW1lbnQgcHVibGlj YXRpb24uDQo+IFRoZSBJRVRGIGRvZXMgbm90IGhhdmUgdGhlIGF1dGhvcml0eSB0byB0cmFuc2Zl ciB0aGVzZSByaWdodHMgdG8gdGhlDQo+IElFRUUuDQo+IEFzIGRlc2NyaWJlZCBpbiBSRkM0NjYz IDMuMSwgdGhlIGF1dGhvcnMgbXVzdCBhZ3JlZSB0byBhbGxvdyB0aGUgSUVFRSB0bw0KPiBjb3B5 IGFuZCBtYWtlIGRlcml2YXRpdmUgd29ya3MgZnJvbSB0aGUgb3JpZ2luYWwgZG9jdW1lbnRzLg0K PiBJZiB0aGUgYXV0aG9ycyBoYXZlIGFzc2lnbmVkIGFsbCBpbnRlbGxlY3R1YWwgcHJvcGVydHkg dG8gdGhlaXINCj4gZW1wbG95ZXJzLCB0aGVuIHRoZSBjb21wYW5pZXMgbXVzdCBhZ3JlZS4NCj4g SGF2ZSBhbGwgdGhlIG9yaWdpbmFsIGF1dGhvcnMgYmVlbiBjb250YWN0ZWQgYW5kIGhhdmUgdGhl eSAoYW5kIHRoZWlyDQo+IGNvbXBhbmllcykgYWdyZWVkIHRvIGdyYW50IElFRUUgdGhlc2Ugcmln aHRzPw0KPiANCj4gDQo+IE1hbnkgTk1TIHRvb2xzIGltcG9ydCB0ZXh0IHZlcnNpb25zIG9mIE1J QiBkb2N1bWVudHM7IHRoZXkgdHlwaWNhbGx5DQo+IGNhbm5vdCBleHRyYWN0IGFuZCBpbXBvcnQg TUlCIG1vZHVsZXMgZnJvbSBQREZzLg0KPiBXaWxsIElFRUUgbWFrZSBzdWJzZXF1ZW50IDgwMi4z IE1JQiBkb2N1bWVudHMgZnJlZWx5IGF2YWlsYWJsZSBpbiB0ZXh0DQo+IGZvcm1hdHM/DQo+IFRo aXMgd2FzIGRvbmUgZm9yIHRoZSA4MDIuMSBNSUIgbW9kdWxlcy4NCj4gDQo+IElmIHRoZSBJRUVF IHdpbGwgZXh0ZW5kIHRoZSBleGlzdGluZyBNSUIgbW9kdWxlcywgd2l0aGluIHRoZSAxLjMuNi4x DQo+IGJyYW5jaCwgSSBiZWxpZXZlIHRoZXkgd2lsbCBuZWVkIHRvIGhhdmUgdGhlIG5ldyBPSURz IGFzc2lnbmVkIGJ5IElBTkEuDQo+IA0KPiBUaGVyZSBhcmUgcXVpdGUgYSBmZXcgaXNzdWVzIHdp dGggZG9pbmcgdGhpcyB0eXBlIG9mIHRyYW5zZmVyLCBhbmQgSQ0KPiByZWNvbW1lbmQgZG9jdW1l bnRpbmcgdGhlIHByb2Nlc3MgYW5kIHRoZSBjb25zdHJhaW50cyBvbiBmdXR1cmUNCj4gZGV2ZWxv cG1lbnQsIHNvIGZ1dHVyZSBjb250cmlidXRvcnMgdW5kZXJzdGFuZCB0aGUgaXNzdWVzIGFuZCBo b3cgdG8NCj4gZGVhbCB3aXRoIHRoZW0uDQo+IA0KPiANCj4gLS0NCj4gRGF2aWQgSGFycmluZ3Rv bg0KPiBJZXRmZGJoQGNvbWNhc3QubmV0DQo+ICsxLTYwMy04MjgtMTQwMQ0KPiANCj4gDQo+IA0K PiANCj4gDQo+IE9uIDcvMjcvMTIgNzoxMyBQTSwgIkJlbm9pdCBDbGFpc2UiIDxiY2xhaXNlQGNp c2NvLmNvbT4gd3JvdGU6DQo+IA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAg IERlYXIgYWxsLA0KPiA+DQo+ID4gICAgV2hpbGUgRElTQ1VTU2luZyBkcmFmdC1pZXRmLWFkc2xt aWItZ2JvbmQtZXRoLW1pYi0wNi50eHQgd2l0aCB0aGUNCj4gPiAgICBJRVNHLCBhbiBpc3N1ZSB3 YXMgYnJvdWdodCB1cC4gTGV0IG1lIGV4cGxhaW4uDQo+ID4NCj4gPiAgICBUaGUgSUVURiBpcyBu byBsb25nZXIgZGV2ZWxvcGluZyBhbnkgRXRoZXJuZXQtcmVsYXRlZCBNSUIgbW9kdWxlcw0KPiA+ ICAgIGFuZCBoYXMgdHJhbnNmZXJyZWQgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZXNlIGRldmVs b3BtZW50IG9mIE1JQg0KPiA+ICAgIG1vZHVsZXMgZm9yIEV0aGVybmV0IHRvIHRoZSBJRUVFIDgw Mi4zIFdHLiBUaGlzIHByb2Nlc3MgaGFzIGFscmVhZHkNCj4gPiAgICBzdGFydGVkIGEgZmV3IHll YXJzIGFnbywgd2hlbiB0aGUgSFVCTUlCIFdHIHdhcyBzaHV0IGRvd24uIFRoaXMNCj4gPiAgICBw cm9jZXNzIGFsc28gY292ZXJzIHRoZSBsYXN0IFJGQyBwcm9kdWNlZCBieSB0aGUgSFVCTUlHIFdH LCBSRkMNCj4gPiAgICAgIDUwNjYgLSBFdGhlcm5ldCBpbiB0aGUgRmlyc3QgTWlsZSBDb3BwZXIg KEVGTUN1KSBJbnRlcmZhY2VzIE1JQg0KPiA+PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzUwNjY+Lg0KPiA+DQo+ID4NCj4gPiAgICBUaGlzIFJGQzUwNjYgY29udGFpbnMgdHdvIE1JQiBt b2R1bGVzDQo+ID4gICAgMS4gdGhlIEVGTS1DVS1NSUIgTUlCIG1vZHVsZSAoRXRoZXJuZXQgdG8g dGhlIEZpcnN0IE1pbGUgQ29wcGVyKSwNCj4gPiAgICBjbGVhcmx5IEV0aGVybmV0LXNwZWNpZmlj DQo+ID4gICAgMi4gdGhlIElGLUNBUC1TVEFDSyBNSUIgbW9kdWxlIGlzIG5vdCBFdGhlcm5ldC1z cGVjaWZpYywgYnV0DQo+IGdlbmVyaWMNCj4gPiAgICAgICAgRm9yIGV4YW1wbGUsIGRyYWZ0LWll dGYtYWRzbG1pYi1nYm9uZC1ldGgtbWliLTA3LnR4dCByZWZlcnMgdG8NCj4gPiAgICB0aGlzIE1J QiBtb2R1bGUuDQo+ID4NCj4gPiAgICBIb3dldmVyLCBhY2NvcmRpbmcgdG8gdGhlIGFncmVlbWVu dCwgaXQgaXMgd2l0aGluIHRoZSBJRUVFDQo+ID4gICAgY29tcGV0ZW5jZSB0byBkZXZlbG9wIHRo ZSBJRUVFODAyMy1JRi1DQVAtU1RBQ0stTUlCIGluIDgwMi4zLjENCj4gPiAgICByYXRoZXIgdGhh biByZWZlciBSRkMgNTA2Ni4NCj4gPiAgICBUaGUgaXNzdWUgd2FzIHJhaXNlZCB0aGF0IGl0IGRp ZG4ndCBtYWtlIHNlbnNlIHRvIHJlZmVyIHRvIHRoZQ0KPiA+ICAgIElFRUU4MDIzLUlGLUNBUC1T VEFDSy1NSUIgd2hlbiB0aGlzIGNyb3NzLWNvbm5lY3QgZnVuY3Rpb25hbGl0eSBpcw0KPiA+ICAg IG5vdCB1c2VkIGZvciBFdGhlcm5ldCwgYW5kIHRoYXQgdGhlIHJlZmVyZW5jZSBSRkM1MDU2IHdh cyBhY3R1YWxseQ0KPiA+ICAgIHByZWZlcnJlZC4NCj4gPg0KPiA+ICAgIFRoaXMgd2Vlaywgd2Ug aGFkIGFuIElFRUUvSUVTRyBtZWV0aW5nIHdoZXJlIHRoaXMgaXNzdWUgd2FzDQo+ID4gICAgZGlz Y3Vzc2VkIGJldHdlZW4gRGFuIFJvbWFzY2FudSAoYXMgdGhlIElFRUUgbGlhaXNvbiksIEhvd2Fy ZA0KPiA+ICAgIEZyYXppZXIgKDgwMi4zLjEpIGFuZCBteXNlbGYuDQo+ID4gICAgVGhlIGZvbGxv d2luZyBoYXMgYmVlbiBhZ3JlZWQgdXBvbjogdGhlIEVGTS1DVS1NSUIgTUlCIG1vZHVsZQ0KPiBz aG91bGQNCj4gPiAgICBiZSBtYWludGFpbmVkIGJ5IElFRUUsIHdoaWxlIHRoZSBJRi1DQVAtU1RB Q0stTUlCIHNob3VsZCBiZQ0KPiA+ICAgIG1haW50YWluZWQgYnkgdGhlIElFVEYuDQo+ID4gICAg UHJhY3RpY2FsbHksIGl0IG1lYW5zOg0KPiA+ICAgIDEuIE9ic29sZXRpbmcgUkZDIDUwNjYNCj4g PiAgICAyLiBDcmVhdGluZyBSRkMgNTA2NmJpcy4gRXh0cmFjdGluZyBJRi1DQVAtU1RBQ0stTUlC IGZyb20gUkZDNTA1NiwNCj4gPiAgICB3aXRoIHNvbWUgd29yZGluZyBlbXBoYXNpemluZyB0aGUg Z2VuZXJpYyBuYXR1cmUgb2YgdGhpcyBtb2R1bGUsDQo+IGFuZA0KPiA+ICAgIGNsZWFybHkgbWVu dGlvbmluZyB0aGF0IHRoZSBJRUVFIDgwMi4zLjEgaXMgcmVzcG9uc2libGUgZm9yDQo+ID4gICAg RUZNLUNVLU1JQi4NCj4gPiAgICAgICAgRWQgQmVpbGkgYWdyZWVkIHRvIHRha2UgdGhlIGxlYWQg b24gdGhpcyBkb2N1bWVudC4NCj4gPiAgICAzLiBUaGUgbmV4dCB2ZXJzaW9uIG9mIGRyYWZ0LWll dGYtYWRzbG1pYi1nYm9uZC1ldGgtbWliIHdpbGwNCj4gY29udGFpbg0KPiA+ICAgIHRoZSBmb2xs b3dpbmcgdGV4dA0KPiA+DQo+ID4gICAgICA0LjQgUmVsYXRpb25zaGlwIHdpdGggdGhlIElFRUUg ODAyLjMgTUlCIG1vZHVsZXMNCj4gPg0KPiA+VGhlIElFRUUgODAyLjMgd29ya2luZyBncm91cCBj aGFydGVyZWQgYSB0YXNrIGZvcmNlIFtJRUVFODAyLjMuMV0gd2hpY2gNCj4gPmNvbnRpbnVlcyB0 aGUgZGV2ZWxvcG1lbnQgb2Ygc3RhbmRhcmQgTUlCIG1vZHVsZXMgYmFzZWQgb24gdGhlIGluaXRp YWwNCj4gPndvcmsgZG9uZSBpbiB0aGUgSUVURi4gIEZ1dHVyZSBwcm9qZWN0cyByZXN1bHRpbmcg ZnJvbSB0aGUgd29yayBvZiB0aGlzDQo+ID5UYXNrIEZvcmNlIG1heSBpbmNsdWRlIGFuZCBwb3Nz aWJseSBleHRlbmQgdGhlIHdvcmsgZG9uZSBpbiB0aGUgSUVURiwNCj4gPnN1Y2ggYXMgW1JGQzUw NjZdLg0KPiA+DQo+ID4tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPlRvIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgYWRkOg0KPiA+DQo+ID5bSUVFRTgwMi4zLjFdIElFRUUgUDgwMi4zLjEgUmV2aXNpb24g dG8gSUVFRSBTdGQgODAyLjMuMS0yMDExIChJRUVFDQo+ID44MDIuMy4xYSkgRXRoZXJuZXQgTUlC cyBUYXNrIEZvcmNlLA0KPiA+aHR0cDovL2dyb3VwZXIuaWVlZS5vcmcvZ3JvdXBzLzgwMi8zLzEv aW5kZXguaHRtbA0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgIFRoYW5rcyB0byBIb3dhcmQgRnJhemll ci4gRWR3YXJkIEJlaWxpLCBNZW5hY2hlbSBEb2RnZSwgRGFuDQo+ID4gICAgUm9tYXNjYW51LCBh bmQgTW90aSBNb3JnZW5zdGVybiBmb3IgaGVscGluZyB3aXRoIHRoaXMgaXNzdWUuIFRoaXMNCj4g PiAgICBzaG93cyBhbiBpbnRlci1TRE8gc3VjY2VzcyBzdG9yeSBJTUhPLg0KPiA+DQo+ID4NCj4g PiAgICBBIHNlY29uZCBkb2N1bWVudCBoYXMgYWxzbyBiZWVuIGRpc2N1c3NlZC4NCj4gPiAgICBJ dCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBoYXZlIGFuIGluZm9ybWF0aW9uYWwgUkZDLCBzaW1p bGFyIHRvDQo+IFJGQw0KPiA+ICAgICAgNDY2MyAtIFRyYW5zZmVycmluZyBNSUIgV29yayBmcm9t IElFVEYgQnJpZGdlIE1JQiBXRyB0byBJRUVFIC4uLg0KPiA+PGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzQ2NjM+LA0KPiA+ICAgIHdpdGggdGhlIGZvbGxvd2luZyBjb250ZW50Lg0KPiA+ ICAgIDEuIExpc3Rpbmcgb2YgYWxsIHRoZSBSRkNzIG9ic29sZXRlZCBieSB0aGUgSUVFRSA4MDIu My4xLTIwMTENCj4gPg0KPiA+ICAgICAgUkZDIDIxMDggwq0gRXRoZXJuZXQgUmVwZWF0ZXIgRGV2 aWNlcw0KPiA+ICAgICAgICBSRkMgMzYyMSAtIFBvd2VyIEV0aGVybmV0IE1JQg0KPiA+ICAgICAg ICBSRkMgMzYzNSAtIEV0aGVybmV0LWxpa2UgSW50ZXJmYWNlIFR5cGVzDQo+ID4gICAgICAgIFJG QyAzNjM3IC0gRXRoZXJuZXQgV0FOIEludGVyZmFjZSBTdWJsYXllcg0KPiA+ICAgICAgICBSRkMg NDgzNiAtIEV0aGVybmV0IE1lZGl1bSBBdHRhY2htZW50IFVuaXRzIChNQVVzKQ0KPiA+ICAgICAg ICBSRkMgNDgzNyAtIEV0aGVybmV0IFBhc3NpdmUgT3B0aWNhbCBOZXR3b3JrcyAoRVBPTikNCj4g PiAgICAgICAgUkZDIDQ4NzggLSBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiwgYW5kIE1haW50 ZW5hbmNlIChPQU0pDQo+ID4gICAgICAgIEZ1bmN0aW9ucyBvbiBFdGhlcm5ldC1MaWtlIEludGVy ZmFjZXMNCj4gPiAgICAgICAgUkZDIDUwNjYgLSBFdGhlcm5ldCBpbiB0aGUgRmlyc3QgTWlsZSBD b3BwZXIgKEVGTUN1KSBJbnRlcmZhY2VzDQo+ID4gICAgICAgIE1JQg0KPiA+DQo+ID4NCj4gPiAg ICAyLiBBIHRhYmxlIG1hcHBpbmcgdGhlIG9sZCBJRVRGIE1JQiBuYW1lcyB3aXRoIHRoZSBjb3Jy ZXNwb25kaW5nDQo+IG5ldw0KPiA+ICAgIElFRUUgb25lcw0KPiA+ICAgIDMuIENsYXJpZmljYXRp b25zL3J1bGVzIG9uIHRoZSBJRVRGLUlFRUUgaW50ZXJhY3Rpb25zLCBtYWlsaW5nDQo+ID4gICAg bGlzdHMsIHJldmlld3MNCj4gPiAgICA0LiBDbGFyaWZpY2F0aW9ucyBvbiB0aGUgaW50ZWxsZWN0 dWFsIHByb3BlcnR5IGNvbnNpZGVyYXRpb25zDQo+ID4NCj4gPiAgICBOZXh0IHRvIERhbiBhbmQg RWQsIEhvd2FyZCBhZ3JlZXMgdG8gY28tYXV0aG9yIHRoaXMgZG9jdW1lbnQuIEFuZA0KPiA+ICAg IHRoYXQgc2VuZHMgYSBzdHJvbmcgcG9zaXRpdmUgc2lnbmFsLg0KPiA+DQo+ID4gICAgVGhlcmUg aXMgb25lIG9wZW4gaXNzdWUgdGhvdWdoIHdpdGggdGhpcyBzZWNvbmQgZG9jdW1lbnQ6IHNob3Vs ZCB3ZQ0KPiA+ICAgIHNlbmQgdG8gaGlzdG9yaWMgYWxsIHRoZSBNSUIgbW9kdWxlcyBtZW50aW9u ZWQgYWJvdmU/IFdoYXQgd291bGQgYmUNCj4gPiAgICB0aGUgaW1wYWN0IGZvciB0aGUgZXF1aXBt ZW50IHZlbmRvcnMgYW5kIE5NUyBhcHBsaWNhdGlvbnM/DQo+ID4gICAgRGFuIFJvbWFzY2FudSB3 aWxsIHByZXNlbnQgdGhpcyBpc3N1ZSBhdCB0aGUgT1BTLUFSRUEgbWVldGluZy4NCj4gPg0KPiA+ ICAgIEZpbmFsbHksIHJlZ2FyZGluZyB0aGUgZnV0dXJlIGNvb3BlcmF0aW9uIGJldHdlZW4gdGhl IElFRUUgYW5kIElFVEYNCj4gPiAgICByZWdhcmRpbmcgdGhlIGRldmVsb3BtZW50IG9mIHRoZSA4 MDIuMy4xLTIwMTEsIEhvd2FyZCBGcmF6aWVyDQo+ID4gICAgbWVudGlvbmVkIHRoYXQgYW55IGZl ZWRiYWNrIGNvdWxkIGJlIHNlbnQgZGlyZWN0bHkgdG8gaGltLCBhbmQgdGhhdA0KPiA+ICAgIGhl IHdvdWxkIGluc2VydCBpdCBpbnRvIHRoZSBiYWxsb3QuDQo+ID4NCj4gPg0KPiA+ICAgIFJlZ2Fy ZHMsIEJlbm9pdCAoT1BTIEEuRC4pDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+T1BTLUFS RUEgbWFpbGluZyBsaXN0DQo+ID5PUFMtQVJFQUBpZXRmLm9yZw0KPiA+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHMtYXJlYQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9QUy1BUkVBIG1haWxpbmcgbGlz dA0KPiBPUFMtQVJFQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29wcy1hcmVhDQo= From ietfdbh@comcast.net Sat Jul 28 21:39:14 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E267B21F8623 for ; Sat, 28 Jul 2012 21:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, 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 izSE8Y2tEZSA for ; Sat, 28 Jul 2012 21:39:13 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id A68C421F8600 for ; Sat, 28 Jul 2012 21:39:12 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta12.westchester.pa.mail.comcast.net with comcast id g4fF1j0010mv7h05C4fFjs; Sun, 29 Jul 2012 04:39:15 +0000 Received: from [10.59.1.23] ([71.233.85.150]) by omta11.westchester.pa.mail.comcast.net with comcast id g4f61j0013Ecudz3X4f7Fg; Sun, 29 Jul 2012 04:39:09 +0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Sun, 29 Jul 2012 00:39:07 -0400 From: David Harrington To: "Romascanu, Dan (Dan)" , Michael MacFaden , , , Message-ID: Thread-Topic: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable 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) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 04:39:15 -0000 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)" 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) >>=20 >> I second David's concerns. Process mapping could also be made clear. >>=20 >> 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. >>=20 >> Dan did answer questions on the overall doctors list at one point which >> helped. >>=20 >> Mike MacFaden >>=20 >>=20 >> Sent from my Android phone using TouchDown (www.nitrodesk.com) >>=20 >>=20 >> -----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) >>=20 >>=20 >> Hi, >>=20 >> I think there are many implementations of these mib modules. >> Applications know where to find these data objects by the existing OIDs. >>=20 >> 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. >>=20 >> 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? >>=20 >> 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? >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> -- >> David Harrington >> Ietfdbh@comcast.net >> +1-603-828-1401 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 7/27/12 7:13 PM, "Benoit Claise" wrote: >>=20 >> > >> > >> > >> > >> > >> > >> > 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 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 ... >> >, >> > with the following content. >> > 1. Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011 >> > >> > RFC 2108 =A1=A9 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 >>=20 >>=20 >> _______________________________________________ >> OPS-AREA mailing list >> OPS-AREA@ietf.org >> https://www.ietf.org/mailman/listinfo/ops-area From dromasca@avaya.com Sat Jul 28 22:59:01 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@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: In-Reply-To: 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: From: "Romascanu, Dan (Dan)" To: "David Harrington" , "Michael MacFaden" , , , 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) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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?=20 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) >=20 > Hi, >=20 > The original email said: > > > > 2. A table mapping the old IETF MIB names with the corresponding > new > > IEEE ones >=20 > 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). >=20 > 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. >=20 >=20 >=20 > 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. >=20 >=20 > 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. >=20 > 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. >=20 > Tread carefully ... >=20 >=20 > -- > David Harrington > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 >=20 > On 7/28/12 9:09 PM, "Romascanu, Dan (Dan)" wrote: >=20 > >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" 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 . > >> > > >> > > >> > 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 > ... > >> >, > >> > 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 >=20 From bclaise@cisco.com Mon Jul 30 08:56:08 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5332521F85DD for ; Mon, 30 Jul 2012 08:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 i1O+lr9W7lFQ for ; Mon, 30 Jul 2012 08:56:07 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id DAAF021F84BD for ; Mon, 30 Jul 2012 08:56:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6UFu620000537 for ; Mon, 30 Jul 2012 08:56:06 -0700 (PDT) Received: from [10.21.90.198] (sjc-vpn5-710.cisco.com [10.21.90.198]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6UFu65f029209 for ; Mon, 30 Jul 2012 08:56:06 -0700 (PDT) Message-ID: <5016AE96.6030008@cisco.com> Date: Mon, 30 Jul 2012 08:56:06 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ops-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPS-AREA] OPS AREA open office hours X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 15:56:08 -0000 Dear all, There is no planned OPS-AREA open office hours during this week, due to a heavy agenda. However, if you have something specific to discuss with Ron and/or/ I, please let me know, and we will find the time. Regards, Benoit.