Hi Ken,

My mistake, thank you for pointing that out.

My apologies,= Daniel, I accidentally overlooked your email when looking back through my e= mail folder.

So the list is then:

<= span style=3D'color:#1F497D'>

Markus Freudenberger, Nick Hancock,= Scott Baillie, Ken Kerpez, Daniel Cederholm, Edward Beili, Chris Croot.

Thank yo= u kindly,

Menachem

= From: K= enneth Kerpez (New Jersey) [mailto:kkerpez@assia-inc.com]
Sent: M= onday, July 23, 2012 2:31 PM
To: Menachem Dodge; adslmib@ietf.org<= br>Cc: Daniel Cederholm
Subject: RE: Vector of Profiles MIB=

Menachem= ,

Daniel Cederholm also expressed support= for the Vector of Profiles MIB, see below.

Ken Kerpez

From: adslmib-bou= nces@ietf.org [mail= to:adslmib-bounces@ietf.org] On Behalf Of Daniel Cederholm
= Sent: Monday, June 11, 2012 8:20 AM
To: adslmib@ietf.org
Subject: [Adslmib] MIB based on= the BBF TR-252i2

Hi,

In a liason from Broadband Forum to IETF ADSLMIB WG, IETF= is informed that TR-252i2 "xDSL Protocol-Independent Management Model&= quot; recently has been completed. The BBF also express support for developm= ent of an SNMP MIB based on this management model.

Ericsson supports this init= iative and with this mail I want to indicate that I'm willing to review the= MIB development work and possibly also to contribute.

Best Regards,<= o:p>

/Daniel Cederholm

3Dlin=

DANIEL CEDERHOLM
Res= arch Engineer

Ericsson= AB
Ericsson Research
F=E4r=F6gatan 6
164 80, Kista, Sweden
Phon= e +46 10 7172464
Mobile +46 761162463
daniel.cederholm@ericsson.com
www.ericsson.com

<= /span><= /o:p>

This Communicati= on is Confidential. We only send and receive email on the basis of the terms= set out at www.ericsson.com/email_disclaimer

From= : Menachem Dodge [mailto:Men= achem.Dodge@ecitele.com]
Sent: 20 July 2012 11:14
To: adslmib@ietf.org
Subject: Vector of Profiles MIB

Hi,=

I had discussions with the AD, Benoit, regarding the work on the Vector o= f Profiles MIB.

<= /p>

Looking back through my emails, I have the fol= lowing very committed people interested in moving this work forward:

Markus= Freudenberger, Nick Hancock, Scott Baillie, Ken Kerpez.

Please let= me know If I have missed anyone or if there are any additional interested p= arties.

Thank you kindly,

&nbs= p;

Menachem

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_283DD79798619346BF9B17D7B5035A1901991D4E964BILPTMAIL02e_-- --_005_283DD79798619346BF9B17D7B5035A1901991D4E964BILPTMAIL02e_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1417; creation-date="Mon, 23 Jul 2012 14:47:54 GMT"; modification-date="Mon, 23 Jul 2012 14:47:54 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqiLQCN XwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZopFYaag6U P8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3gqcKWpoNXACF nnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwcbDShL7kHVg9Dijwf b3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2pJQtTlQCHiyyeMyEldVut HwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCEqgCCtgCEpwCFnACJfwCKdgCL bWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlbmwCHjQ1Kjw5GjACLaz+kKgCQSRE5 g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQORRHO1FHsTYxaXPJEPXo++CYe7DACPSkkd bU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIYaAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwG VQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88C USecNRMwfq0JWACCs3m3EgCGmQCJgACIgpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYES YQF/tACBtQCJfZQOXQCKdEinJ4m8CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVu qCckdACFogCGkwCDsQJ7sQCKcgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4 rwCLagCNXgCOUwpYmQuUQLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMA AAj/AP/9y8cPFiFhUT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYV ulihsuWFgSNXrULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV 6tBOyBU9PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCp UIUdOejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgLESLA 5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUUUkox5RRU UlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHmGWiikWYaaqqx 5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLRZx9++t3yBSL//bMP PgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFHJbVUU09FNVVVV2W1VVdf hWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZZ5+FNlppp6W2WmuvxTZbbbfl tltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3X3335bffF/79ExAAOw== --_005_283DD79798619346BF9B17D7B5035A1901991D4E964BILPTMAIL02e_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1809; creation-date="Mon, 23 Jul 2012 14:47:54 GMT"; modification-date="Mon, 23 Jul 2012 14:47:54 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh9AFRAPcAAId6ryxvsAtXo8zr6BBJmdIaXiuWxACZi5nW17ritehtmC6skFWWx3YdbtfD 2ffg6qpUjgCXpb3X6gCYnGvHjKbbqaypzHvCQSmsSpnXzI3RjQCcZxKkauLx1OWUtcXjpq3ftkQj ed7r9ACMuieltdekwo5Xlbvh6ur25oy118MaYQiiUwCaeM7s3tc5dNbV5u71+hg7jnfE1tjuzZnS 4qbUcZXPb6bXiLIvcojM3MfmswN8uVW7tKrY5rWWve6jv+zh7ENysSpGlJ2bw5vZvaoaZWa8Q4TQ npYvd2g/iCwqgBGatpsbZ7R3p1m5RILEQMeVuunR4YUca3m32fL68wCeW5rM47Xfp/Tw9gCTsm9v qUu6cEahywOCurMaY3JRlG6Yxse10b3l1YjQuRSmT2e41UyFvZSjyhGhhEi6gt4oZ8tIgZ+52HbH cYrD3sOlxtTu223AUk62RY6v04jO00S2ld7y6+749atonUKzRka2U1W8nLTiw9SVuM3m8X3NoJDV rfXR3/rw9WbDpyhYobqGsTGFvq3M4zOiyFEgdeCjwamYwHMtemO/Wd3w9TQnfTq0ZTq1drW713fK s+NHfarezK6Hs+TC1tSzzmbCuL/iptmFrKGz1FtTmIGbxtrw2rXdms/c7BGdqnuu07qmyFas0glg qiKpe4k7gRWFvj+yR8rqzojJW14fc1S6VHSKu8V2pCEyh/Oyya6Xv4jPy2qp0fPC1Krd1BKSwIjS shpmrFW5xrfcjBd5t+azyzg6isLL4YvGPwZusjKvSO73+u+Us94ZXHvGXFikz2GDuY7JTbHA2w6k UUSww+Dm8ZGozn2mzjayVojFQCuvaavgx1aw0ojHTsLhmZzA3ZTKTFfAjMSFr4jQwpegx37ET1M6 iEBehn+Trr/J1xA1aJ+uwu/y9t/k68/X4WB5mzBQfCBDcprYqnCGpY+huK+8zE9rkqatz9brv7/R 5ZbNWRhusshmmI+r0Kvbm3TAQiKrW5dpobvfmt1XiaGJtgAoXv///ywAAAAA9AFRAAAI/gD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1L1qC5duHC iSvLtq3bqeTe+Zs7F93bu3jz/hSHbhzdv/7I6R1MuPBKc+zUAV4MzrDjx5AxlmuXbrFlf40ja97M uWDcy6Azdx5NWi9fv6BBCy7NurVYxIpTp2bnurZtrJMrywatjp2528CDPz0Xe7dldO6EK1+eVLfx v+nIlWNOvXrQc8/p9v5tvbt3neKe/o9Dt7bgOXbg3q3+zr49yvCywUkveLb4XNHu8+v3aP+vunbc DVQOOeCA1s5+CCZ40TmozTXeOQa5g85u+Clo4YULTYYOO+sNdF6D8WEo4ogOneXcc++QqOKKAg0o V3Z/JcfijBZKCCKM43RI447swQYjYOm0Mx2PRH7H4I/a+Vbkkt/19xxyTEbZHXzZyTeklFgyR6Vs 6oQT4EBxgQNOOFdmaeZo2KU2XnkEndMXkGWeKWdkBVqmnlnhOElXOHP2GVk5J/735T8DnnhZhX4m Opg7aUFYkDsvGoeoopQW5uaNu6VY6aaDmZMnknOxyemoZRUK6lzqyEjqqmGdEymo/u+oyuqsXblz qj/RxUnrrllhutt2vAbL1Za7jSersMheRWxo8yXrLFZp8ubls9RmVSdgD1arLW7X+nPntuBCS447 g4Zr7rnopqvuuuy26+678MYr77z01mvvvfiqe444/PKr0IBpkeMowOG0MzA5aRk8kDkIh+NovvRa tla3/uQoUKgChbPYP0fS1Rg5IGbGDpCO0lVegXxCfO5c6YgpJoQUzzUdxiOjCk5l/8TWcsv/oLZz Yxrf5/PF9wmEssor+yOq0XMRqttaoZpD14EC/eaggPClI2DPcx1YDmqC/TWxPykjDW7X/Z4cqjt+ jUO0OOSwbBBqvUFYTpK/wee2+UA181kXZv8cbfbZGweOrYyhBl02mIDZVfOe8InWTtFzSR2Y4INr W1daaTENWHmhTu7tQZfSBeFpdMWN60BB09a0xupgnjm1GBdU5z+i2/VPqNE+bNCLbAI6l62VC6Tb gU1/XTHZs2vuDzqcT3v73RW/bfjmef7zDjrttIOaOL2hhZo5E+L6WcUz+5Pxns1XK/H1Ar0YttKE xizOjY0tZpfwf42DuPqEQs3i2oes6HHuN+jJjDvExKe0BEhCLvNNOFwGDiH9I4Fi6lCYwKGkjJVN HGlZGgFHSMISmvCEKEyhClfIwha68IUwjKEMZ0jDGtrwhjjMYUUCAgA7 --_005_283DD79798619346BF9B17D7B5035A1901991D4E964BILPTMAIL02e_-- From bclaise@cisco.com Wed Jul 25 11:32:46 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632CC21F8714 for ; Wed, 25 Jul 2012 11:32:46 -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 P9aikNlkoyNu for ; Wed, 25 Jul 2012 11:32:45 -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 ACB8721F86F8 for ; Wed, 25 Jul 2012 11:32:45 -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 q6PIWjwL025498 for ; Wed, 25 Jul 2012 11:32:45 -0700 (PDT) Received: from [10.33.22.74] ([10.33.22.74]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6PIWjIU015176 for ; Wed, 25 Jul 2012 11:32:45 -0700 (PDT) Message-ID: <50103BCD.2020603@cisco.com> Date: Wed, 25 Jul 2012 11:32:45 -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 References: <20120725181735.29414.40738.idtracker@ietfa.amsl.com> In-Reply-To: <20120725181735.29414.40738.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120725181735.29414.40738.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020308060604070008080505" Subject: [Adslmib] Fwd: Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt) X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 18:32:46 -0000 This is a multi-part message in MIME format. --------------020308060604070008080505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Congrats to the authors, the WG, and the chair Regards, Benoit. -------- Original Message -------- Subject: Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt) Date: Wed, 25 Jul 2012 11:17:35 -0700 From: The IESG To: IETF-Announce CC: adslmib mailing list , adslmib chair , RFC Editor The IESG has approved the following document: - 'xDSL multi-pair bonding (G.Bond) MIB' (draft-ietf-adslmib-gbond-mib-11.txt) as Proposed Standard This document is the product of the ADSL MIB Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/ Technical Summary This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. Working Group Summary The WG process was smooth with no real controversies. All work took place on the mailing list. Document Quality No information is available about implementations. Personnel Menachem Dodge is the Document Shepherd for this document Dan Romascanu was the first responsible Area Director. Benoit Claise is the current responsible Area Director. --------------020308060604070008080505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Congrats to the authors, the WG, and the chair

Regards, Benoit.

-------- Original Message --------

Subject: Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt)

Date: Wed, 25 Jul 2012 11:17:35 -0700

From: The IESG <iesg-secretary@ietf.org>

To: IETF-Announce <ietf-announce@ietf.org>

CC: adslmib mailing list <adslmib@ietf.org>, adslmib chair <adslmib-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>

The IESG has approved the following document: - 'xDSL multi-pair bonding (G.Bond) MIB' (draft-ietf-adslmib-gbond-mib-11.txt) as Proposed Standard This document is the product of the ADSL MIB Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/ Technical Summary This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. Working Group Summary The WG process was smooth with no real controversies. All work took place on the mailing list. Document Quality No information is available about implementations. Personnel Menachem Dodge is the Document Shepherd for this document Dan Romascanu was the first responsible Area Director. Benoit Claise is the current responsible Area Director.

--------------020308060604070008080505-- From Menachem.Dodge@ecitele.com Wed Jul 25 12:15:47 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D429921F86AF for ; Wed, 25 Jul 2012 12:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.57 X-Spam-Level: X-Spam-Status: No, score=-104.57 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001, 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 TFExjX3Vmx63 for ; Wed, 25 Jul 2012 12:15:47 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 36D1421F8629 for ; Wed, 25 Jul 2012 12:15:45 -0700 (PDT) Received: from [85.158.143.35:19274] by server-1.bemta-4.messagelabs.com id 53/E7-24392-1E540105; Wed, 25 Jul 2012 19:15:45 +0000 X-Env-Sender: Menachem.Dodge@ecitele.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1343243743!11839913!2 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 504 invoked from network); 25 Jul 2012 19:15:44 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-7.tower-21.messagelabs.com with SMTP; 25 Jul 2012 19:15:44 -0000 X-AuditID: 93eaf2e7-b7fcf6d00000191a-d2-501042f75468 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 79.D0.06426.7F240105; Wed, 25 Jul 2012 22:03:19 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 25 Jul 2012 22:15:39 +0300 From: Menachem Dodge To: Benoit Claise , adslmib mailing list Date: Wed, 25 Jul 2012 22:15:37 +0300 Thread-Topic: [Adslmib] Fwd: Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt) Thread-Index: Ac1qk3+Juuwv4S0dSaCy0uj9nxomTwABTqUw Message-ID: <283DD79798619346BF9B17D7B5035A1901991D5D00A5@ILPTMAIL02.ecitele.com> References: <20120725181735.29414.40738.idtracker@ietfa.amsl.com> <50103BCD.2020603@cisco.com> In-Reply-To: <50103BCD.2020603@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_283DD79798619346BF9B17D7B5035A1901991D5D00A5ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTW2wMURjOmcua1k4dq6un5WEyLgm17LpEaYtUSIm0dYnrA9PdY3did2Yz My4rLvtQaYlL6xatByWlVENQl6gEpQSlSNylES2loqQh1KU1x6TVF2/f/33ff8l//sPRjt+2 JE5WDKwpUlC0xTK7Wtq+uL5nwBz3z69USsONe2xKbSOaQmXu/nmKzSwra6dyqMVRkCYpimpI BhZ8WPemizmavEryRkRB9qWLHlEIByUvDmHFSBelcBgrPnFSbJpJyoqAFa/qkxV/ujhjbrYr JWXcBJdHnDR0kGdMauy8gKwL2BWS5KAQwrou+bFgMmRAxYd9wnJVE4wAFrRlu+hAcXMpHc7P XXOkIo+NgrwFW0AMh+BY1F5VbrNwf3S/4aSJYzkHvAxQ64tjtBXsBWjPuSdmwHE26EFNO3uT hHiYhd7U1bIEM3AIatnewBJ/P1gI0M2drxkSxMMigF5V7qGsjNGoYGs+IJiHs9Gd6CGGFHXA Zejzi1mEjoHD0L79xxiCgTnRt9uVf1NpmICeNx2grEkhKrtUT1vYid43drCW34le5p8Ell9F 1Re20larvuhWcRNj+RPR1aNPmULgLOlRtqRHSkmPFIsfgUqr22wWTkZHDn6gu3DdlUaqJ18K elUApxwMG7khv9szEntlAwfxSK8aOg2se2m+AH4cGFwDIAdEO1/6Oi7HwUqr9EioBiRylOjk W81zcsTlqr5IQNIDS7WVQazXAMTRYjy/wWlqvE+KrMWa2iVNM9dfRCf19qrk4Y2lY9zu/wdi Al8eXZDtgH7zHFdgHMZaV52BHCciPmua2aKvhv14zXI5aPyTKS6GjGE3x5hMPLwelkK67Lf0 28DFba5qeA4cjKIqOCmBX0FMkJgCK5XuOuTXbOzs7GwBCeYC+vHTictunmx3pRazCWU2aZ4f R5qY36ZbSoqCyc6rn98dP/xmc8eckq9P9Ny6H30qHumFFeeaxk9/2BHjin+boS3ZUpDKVp8v yKq883Hbfru9NbvNa19/Eby9/GxYn8e19cnlM6s+Fp5pd/9K3pQZecompuXNssGpOxZNHDow 9bwW+fTA1r/+bPOJotF3t2fwA+rWfVrtupa1bsnCUYHrIqMHJM9wWtOlP12SH/oQBAAA Subject: Re: [Adslmib] Fwd: Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt) X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 19:15:48 -0000 --_000_283DD79798619346BF9B17D7B5035A1901991D5D00A5ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi, Congratulations to the editors! Many thanks to Benoit, the current AD, and Dan, the previous AD, for all the= ir efforts, feedback, comments, reviews and help in getting this document an= d the other G.Bond documents published. Best Regards, Menachem From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf O= f Benoit Claise Sent: Wednesday, July 25, 2012 9:33 PM To: adslmib mailing list Subject: [Adslmib] Fwd: Protocol Action: 'xDSL multi-pair bonding (G.Bond) M= IB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt) Congrats to the authors, the WG, and the chair Regards, Benoit. -------- Original Message -------- Subject: Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard= (draft-ietf-adslmib-gbond-mib-11.txt) Date: Wed, 25 Jul 2012 11:17:35 -0700 From: The IESG To: IETF-Announce CC: adslmib mailing list , adslmib ch= air , R= FC Editor The IESG has approved the following document: - 'xDSL multi-pair bonding (G.Bond) MIB' (draft-ietf-adslmib-gbond-mib-11.txt) as Proposed Standard This document is the product of the ADSL MIB Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/ Technical Summary This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. Working Group Summary The WG process was smooth with no real controversies. All work took place on the mailing list. Document Quality No information is available about implementations. Personnel Menachem Dodge is the Document Shepherd for this document Dan Romascanu was the first responsible Area Director. Benoit Claise is the current responsible Area Director. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_283DD79798619346BF9B17D7B5035A1901991D5D00A5ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable
<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'>Hi,

Congratulations to the editors!

Many thanks to Benoit, the current AD, and Dan, the prev= ious AD, for all their efforts, feedback, comments, reviews and help in gett= ing this document and the other G.Bond documents published.

Best Regards,
Men= achem

From: adslmib-bounces@ietf.org [mailto:adslmib-b= ounces@ietf.org] On Behalf Of Benoit Claise
Sent: Wednesday= , July 25, 2012 9:33 PM
To: adslmib mailing list
Subject: [Adslmib] Fwd: Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to= Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt)

Congrats to the authors, the WG, and the chair

Regards, Benoit.=

-------- Original Message ------= --
Date:
<= td style=3D'padding:0cm 0cm 0cm 0cm'>
Wed, 25 Jul 2012 1= 1:17:35 -0700
Subject: <= o:p>
Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed St= andard (draft-ietf-adslmib-gbond-mib-11.txt)
From:
The IESG <iesg-secretary@ietf.org>
To:
IETF-Announce <ietf-announce@ietf.org><= /p>
<= p class=3DMsoNormal align=3Dright style=3D'text-align:right'>CC:
a= dslmib mailing list <adslmib@ietf.org= >, adslmib chair <= ;adslmib-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
= ;
The IESG has approved the following document:
- 'xDSL multi-pair bonding (G.Bond) MIB'
= (draft-ietf-adslmib-gbond-mib-11.txt) as Proposed Standard
=

This document is the product of the ADSL MI= B Working Group.

The IESG c= ontact persons are Benoit Claise and Ronald Bonica.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/

&nb= sp;

Technical Summary=

   This document defines Ma= nagement Information Base (MIB) module for
  = use with network management protocols in TCP/IP-based internets.=
   This document proposes an extension to the Interface= s Group MIB with
   a set of common objects f= or managing multi-pair bonded Digital
   Subs= criber Line (xDSL) interfaces, defined in ITU-T recommendations
   G.998.1, G.998.2 and G.998.3. The MIB modules sp= ecific to each
   bonding technology are defi= ned in GBOND-ATM-MIB, GBOND-ETH-MIB and
   GB= OND-TDIM-MIB respectively.

= Working Group Summary

= ; The WG process was smooth with no real controversies.
   All work took place on the mailing list.

Document Quality

   No information is available about impl= ementations.

Personnel

   Menachem Dodge is= the Document Shepherd for this document
   D= an Romascanu was the first responsible Area Director.
&= nbsp; Benoit Claise is the current responsible Area Director.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.
--_000_283DD79798619346BF9B17D7B5035A1901991D5D00A5ILPTMAIL02e_-- From EdwardB@actelis.com Thu Jul 26 00:29:05 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FD211E807F for ; Thu, 26 Jul 2012 00:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 paei69Nv5BiB for ; Thu, 26 Jul 2012 00:29:03 -0700 (PDT) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id C7F8C21F8505 for ; Thu, 26 Jul 2012 00:29:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,659,1336338000"; d="scan'208,217";a="680816" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 26 Jul 2012 10:29:00 +0300 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Thu, 26 Jul 2012 10:29:00 +0300 From: Edward Beili To: Menachem Dodge , Benoit Claise , adslmib mailing list Date: Thu, 26 Jul 2012 10:28:59 +0300 Thread-Topic: [Adslmib] Fwd: Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt) Thread-Index: Ac1qk3+Juuwv4S0dSaCy0uj9nxomTwABTqUwABl9PCA= Message-ID: <4087887712E5C648B9F72BB9D912FD4602500BB3CE6C@il-mail07.actelis.net> References: <20120725181735.29414.40738.idtracker@ietfa.amsl.com> <50103BCD.2020603@cisco.com> <283DD79798619346BF9B17D7B5035A1901991D5D00A5@ILPTMAIL02.ecitele.com> In-Reply-To: <283DD79798619346BF9B17D7B5035A1901991D5D00A5@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4087887712E5C648B9F72BB9D912FD4602500BB3CE6Cilmail07act_" MIME-Version: 1.0 Subject: Re: [Adslmib] Fwd: Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt) X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 07:29:05 -0000 --_000_4087887712E5C648B9F72BB9D912FD4602500BB3CE6Cilmail07act_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I would like to thank Menachem, Dan and Benoit for their help, comments and= support in moving this document towards the approval. Regards, -E. From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf = Of Menachem Dodge Sent: Wednesday, July 25, 2012 22:16 To: Benoit Claise; adslmib mailing list Subject: Re: [Adslmib] Fwd: Protocol Action: 'xDSL multi-pair bonding (G.Bo= nd) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt) Hi, Congratulations to the editors! Many thanks to Benoit, the current AD, and Dan, the previous AD, for all th= eir efforts, feedback, comments, reviews and help in getting this document = and the other G.Bond documents published. Best Regards, Menachem From: adslmib-bounces@ietf.org [mailto:ads= lmib-bounces@ietf.org] On Behalf = Of Benoit Claise Sent: Wednesday, July 25, 2012 9:33 PM To: adslmib mailing list Subject: [Adslmib] Fwd: Protocol Action: 'xDSL multi-pair bonding (G.Bond) = MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt) Congrats to the authors, the WG, and the chair Regards, Benoit. -------- Original Message -------- Subject: Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standar= d (draft-ietf-adslmib-gbond-mib-11.txt) Date: Wed, 25 Jul 2012 11:17:35 -0700 From: The IESG To: IETF-Announce CC: adslmib mailing list , adslmib c= hair ,= RFC Editor The IESG has approved the following document: - 'xDSL multi-pair bonding (G.Bond) MIB' (draft-ietf-adslmib-gbond-mib-11.txt) as Proposed Standard This document is the product of the ADSL MIB Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/ Technical Summary This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. Working Group Summary The WG process was smooth with no real controversies. All work took place on the mailing list. Document Quality No information is available about implementations. Personnel Menachem Dodge is the Document Shepherd for this document Dan Romascanu was the first responsible Area Director. Benoit Claise is the current responsible Area Director. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_4087887712E5C648B9F72BB9D912FD4602500BB3CE6Cilmail07act_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
= Hello,
I would like= to thank Menachem, Dan and Benoit for their help, comments and support in = moving this document towards the approval.

Re= gards,
-E.

From: adslmib-bounces= @ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf Of Menachem Do= dge
Sent: Wednesday, July 25, 2012 22:16
To: Benoit Cla= ise; adslmib mailing list
Subject: Re: [Adslmib] Fwd: Protocol Ac= tion: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ie= tf-adslmib-gbond-mib-11.txt)

Hi,

Congratulations to the editors!

Many thanks to Benoit, the current AD, and Dan, the previous AD, for al= l their efforts, feedback, comments, reviews and help in getting this docum= ent and the other G.Bond documents published.

Best Regards,
Menachem

=

= From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf Of Benoit= Claise
Sent: Wednesday, July 25, 2012 9:33 PM
To: adsl= mib mailing list
Subject: [Adslmib] Fwd: Protocol Action: 'xDSL m= ulti-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gb= ond-mib-11.txt)
=
Congrats to the authors, the WG, and t= he chair

Regards, Benoit.

-------- Original Message --------
CC:
adslmib mailing li= st <adslmib@ietf.org>, adslmi= b chair <adslmib-chairs= @tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>

<= pre>The IESG has approved the following document:
- 'x= DSL multi-pair bonding (G.Bond) MIB'
(draft-iet= f-adslmib-gbond-mib-11.txt) as Proposed Standard
=
This document is the product of the ADSL MIB Working= Group.

The IESG contact p= ersons are Benoit Claise and Ronald Bonica.
= ;
A URL of this Internet Draft is:
http= ://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/

=

Technical Summary

   This document defines Man= agement Information Base (MIB) module for
  = use with network management protocols in TCP/IP-based internets.
   This document proposes an extension to the Interfa= ces Group MIB with
   a set of common object= s for managing multi-pair bonded Digital
   = Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations
   G.998.1, G.998.2 and G.998.3. The MIB modu= les specific to each
   bonding technology a= re defined in GBOND-ATM-MIB, GBOND-ETH-MIB and
&= nbsp; GBOND-TDIM-MIB respectively.

Working Group Summary

=
   The WG process was smooth with no real controversies.
   All work took place on the mailing list.

Document Quality<= /pre>

   No information is availa= ble about implementations.

Personnel

   M= enachem Dodge is the Document Shepherd for this document
   Dan Romascanu was the first responsible Area Director.=
   Benoit Claise is the current responsible Area= Director.

This e-mail messag= e is intended for the recipient only and contains information which is CONF= IDENTIAL and which may be proprietary to ECI Telecom. If you have received = this transmission in error, please inform us by e-mail, phone or fax, and t= hen delete the original and all copies thereof.
= --_000_4087887712E5C648B9F72BB9D912FD4602500BB3CE6Cilmail07act_-- From iesg-secretary@ietf.org Wed Jul 25 11:17:36 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B17221F8734; Wed, 25 Jul 2012 11:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 BX90SccZRTDF; Wed, 25 Jul 2012 11:17:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5304821F8751; Wed, 25 Jul 2012 11:17:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120725181735.29414.40738.idtracker@ietfa.amsl.com> Date: Wed, 25 Jul 2012 11:17:35 -0700 X-Mailman-Approved-At: Thu, 26 Jul 2012 09:22:10 -0700 Cc: adslmib mailing list , adslmib chair , RFC Editor Subject: [Adslmib] Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt) X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 18:17:36 -0000 The IESG has approved the following document: - 'xDSL multi-pair bonding (G.Bond) MIB' (draft-ietf-adslmib-gbond-mib-11.txt) as Proposed Standard This document is the product of the ADSL MIB Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/ Technical Summary This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. Working Group Summary The WG process was smooth with no real controversies. All work took place on the mailing list. Document Quality No information is available about implementations. Personnel Menachem Dodge is the Document Shepherd for this document Dan Romascanu was the first responsible Area Director. Benoit Claise is the current responsible Area Director. From bclaise@cisco.com Fri Jul 27 16:13:22 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@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: Ron Bonica , Howard Frazier , ops-area@ietf.org Subject: [Adslmib] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB 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 dromasca@avaya.com Sat Jul 28 18:09:39 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@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: [Adslmib] [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 01:09:39 -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 dromasca@avaya.com Sat Jul 28 22:59:01 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@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: [Adslmib] [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB 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 mrm@vmware.com Fri Jul 27 22:38:02 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@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__" X-Mailman-Approved-At: Mon, 30 Jul 2012 00:41:30 -0700 Cc: hfrazier@broadcom.com, ops-area@ietf.org Subject: Re: [Adslmib] =?utf-8?q?=5BOPS-AREA=5D_IEEE/IETF_relationship_on_Ethe?= =?utf-8?q?rnet-specific_MIB_Modules_=28was_DISCUSS_on_draft-ietf-adslmib-?= =?utf-8?q?gbond-eth-mib-07=2Etxt=29?= X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB 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 ietfdbh@comcast.net Fri Jul 27 21:55:03 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5593021F849C 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.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 khl-78eiiqMX for ; Fri, 27 Jul 2012 21:55:02 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id D0CD621F847E for ; Fri, 27 Jul 2012 21:55:01 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta13.westchester.pa.mail.comcast.net with comcast id fgu71j0031uE5Es5Dgv4Z2; 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 X-Mailman-Approved-At: Mon, 30 Jul 2012 00:42:11 -0700 Cc: Howard Frazier , ops-area@ietf.org Subject: Re: [Adslmib] [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB 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 ietfdbh@comcast.net Sat Jul 28 21:39:14 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DFC21F8609 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.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 bY-pI6M6XahD for ; Sat, 28 Jul 2012 21:39:13 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id A685C21F84EF for ; Sat, 28 Jul 2012 21:39:12 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta14.westchester.pa.mail.comcast.net with comcast id g4fF1j0030mv7h05E4fF7h; 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 X-Mailman-Approved-At: Mon, 30 Jul 2012 00:42:27 -0700 Cc: hfrazier@broadcom.com, ops-area@ietf.org Subject: Re: [Adslmib] [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB 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
Subject:
Protocol Action: 'xDSL mu= lti-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbo= nd-mib-11.txt)
Date:
Wed, 25 Jul 2012 11:17:35 -0700
From: <= /o:p>
The IESG <iesg-secretary@ie= tf.org>
To:
IETF-Announce <ietf-announce@ietf.org>

Subject:	Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-mib-11.txt)
Date:	Wed, 25 Jul 2012 11:17:35 -0700
From:	The IESG <iesg-secretary@ietf.org>
To:	IETF-Announce <ietf-announce@ietf.org>
CC:	adslmib mailing list <adslmib@ietf.org>, adslmib chair <adslmib-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>

Subject: <= o:p>	Protocol Action: 'xDSL multi-pair bonding (G.Bond) MIB' to Proposed St= andard (draft-ietf-adslmib-gbond-mib-11.txt)
From:	The IESG <iesg-secretary@ietf.org>
To:	IETF-Announce <ietf-announce@ietf.org><= /p>
<= p class=3DMsoNormal align=3Dright style=3D'text-align:right'>CC:	a= dslmib mailing list <adslmib@ietf.org= >, adslmib chair <= ;adslmib-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>

Subject:	Protocol Action: 'xDSL mu= lti-pair bonding (G.Bond) MIB' to Proposed Standard (draft-ietf-adslmib-gbo= nd-mib-11.txt)
Date:	Wed, 25 Jul 2012 11:17:35 -0700
From: <= /o:p>	The IESG <iesg-secretary@ie= tf.org>
To:	IETF-Announce <ietf-announce@ietf.org>