IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt)
Benoit Claise <[email protected]> Fri, 27 Jul 2012 16:13:18 -0700
| Newsgroups | gmane.ietf.hubmib,gmane.ietf.adslmib,gmane.ietf.ops |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============9086378527263073356==
Content-Type: multipart/alternative;
boundary="------------070800000707090109030301"
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
<http://tools.ietf.org/html/rfc5066>.
This RFC5066 contains two MIB modules
1. the EFM-CU-MIB MIB module (Ethernet to the First Mile Copper),
clearly Ethernet-specific
2. the IF-CAP-STACK MIB module is not Ethernet-specific, but generic
For example, draft-ietf-adslmib-gbond-eth-mib-07.txt refers to this
MIB module.
However, according to the agreement, it is within the IEEE competence to
develop the IEEE8023-IF-CAP-STACK-MIB in 802.3.1 rather than refer RFC
5066.
The issue was raised that it didn't make sense to refer to the
IEEE8023-IF-CAP-STACK-MIB when this cross-connect functionality is not
used for Ethernet, and that the reference RFC5056 was actually preferred.
This week, we had an IEEE/IESG meeting where this issue was discussed
between Dan Romascanu (as the IEEE liaison), Howard Frazier (802.3.1)
and myself.
The following has been agreed upon: the EFM-CU-MIB MIB module should be
maintained by IEEE, while the IF-CAP-STACK-MIB should be maintained by
the IETF.
Practically, it means:
1. Obsoleting RFC 5066
2. Creating RFC 5066bis. Extracting IF-CAP-STACK-MIB from RFC5056, with
some wording emphasizing the generic nature of this module, and clearly
mentioning that the IEEE 802.3.1 is responsible for EFM-CU-MIB.
Ed Beili agreed to take the lead on this document.
3. The next version of draft-ietf-adslmib-gbond-eth-mib will contain the
following text
4.4 Relationship with the IEEE 802.3 MIB modules
The IEEE 802.3 working group chartered a task force [IEEE802.3.1] which
continues the development of standard MIB modules based on the initial
work done in the IETF. Future projects resulting from the work of this
Task Force may include and possibly extend the work done in the IETF,
such as [RFC5066].
-------------
To Informative References add:
[IEEE802.3.1] IEEE P802.3.1 Revision to IEEE Std 802.3.1-2011 (IEEE
802.3.1a) Ethernet MIBs Task Force,
http://grouper.ieee.org/groups/802/3/1/index.html
Thanks to Howard Frazier. Edward Beili, Menachem Dodge, Dan Romascanu,
and Moti Morgenstern for helping with this issue. This shows an
inter-SDO success story IMHO.
A second document has also been discussed.
It would be a good idea to have an informational RFC, similar to RFC
4663 - Transferring MIB Work from IETF Bridge MIB WG to IEEE ...
<http://tools.ietf.org/html/rfc4663>, with the following content.
1. Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011
RFC 2108 -- Ethernet Repeater Devices
RFC 3621 - Power Ethernet MIB
RFC 3635 - Ethernet-like Interface Types
RFC 3637 - Ethernet WAN Interface Sublayer
RFC 4836 - Ethernet Medium Attachment Units (MAUs)
RFC 4837 - Ethernet Passive Optical Networks (EPON)
RFC 4878 - Operations, Administration, and Maintenance (OAM)
Functions on Ethernet-Like Interfaces
RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
2. A table mapping the old IETF MIB names with the corresponding new
IEEE ones
3. Clarifications/rules on the IETF-IEEE interactions, mailing lists,
reviews
4. Clarifications on the intellectual property considerations
Next to Dan and Ed, Howard agrees to co-author this document. And that
sends a strong positive signal.
There is one open issue though with this second document: should we send
to historic all the MIB modules mentioned above? What would be the
impact for the equipment vendors and NMS applications?
Dan Romascanu will present this issue at the OPS-AREA meeting.
Finally, regarding the future cooperation between the IEEE and IETF
regarding the development of the 802.3.1-2011, Howard Frazier mentioned
that any feedback could be sent directly to him, and that he would
insert it into the ballot.
Regards, Benoit (OPS A.D.)
--------------070800000707090109030301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear all,<br>
<br>
While DISCUSSing draft-ietf-adslmib-gbond-eth-mib-06.txt with the
IESG, an issue was brought up. Let me explain.<br>
<br>
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, <a
href="http://tools.ietf.org/html/rfc5066" class="l vst"
onmousedown="return
rwt(this,'','','','1','AFQjCNGfUc1D_f6yYmSxPX0qS8wq9WIhpg','vXNHYg3zZGRSYutRsQ1E7w','0CGUQFjAA',null,event)">RFC
5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB</a>.
<br>
<br>
This RFC5066 contains two MIB modules<br>
1. the EFM-CU-MIB MIB module (Ethernet to the First Mile Copper),
clearly Ethernet-specific<br>
2. the IF-CAP-STACK MIB module is not Ethernet-specific, but generic<br>
For example, draft-ietf-adslmib-gbond-eth-mib-07.txt refers to
this MIB module.<br>
<br>
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. <br>
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.<br>
<br>
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.<br>
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.<br>
Practically, it means:<br>
1. Obsoleting RFC 5066<br>
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<span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">.</span><br>
Ed Beili agreed to take the lead on this document.<br>
3. The next version of draft-ietf-adslmib-gbond-eth-mib will contain
the following text<br>
<blockquote>
<pre wrap="">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,
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://grouper.ieee.org/groups/802/3/1/index.html">http://grouper.ieee.org/groups/802/3/1/index.html</a></pre>
</blockquote>
<br>
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.<br>
<br>
<br>
A second document has also been discussed.<br>
It would be a good idea to have an informational RFC, similar to <a
href="http://tools.ietf.org/html/rfc4663" class="l vst"
onmousedown="return
rwt(this,'','','','1','AFQjCNFYWDvf7Mw7PO9z1oBMf2ttu5a7xA','3vZkxZpUGtZO4WK45vxc0g','0CGYQFjAA',null,event)">RFC
4663 - Transferring MIB Work from IETF Bridge MIB WG to IEEE ...</a>,
with the following content.<br>
1. Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011<br>
<blockquote>
<p class="MsoNormal">RFC 2108 – Ethernet Repeater Devices<br>
RFC 3621 - Power Ethernet MIB<br>
RFC 3635 - Ethernet-like Interface Types<br>
RFC 3637 - Ethernet WAN Interface Sublayer<br>
RFC 4836 - Ethernet Medium Attachment Units (MAUs)<br>
RFC 4837 - Ethernet Passive Optical Networks (EPON)<br>
RFC 4878 - Operations, Administration, and Maintenance (OAM)
Functions on Ethernet-Like Interfaces<br>
RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces
MIB</p>
</blockquote>
2. A table mapping the old IETF MIB names with the corresponding new
IEEE ones<br>
3. Clarifications/rules on the IETF-IEEE interactions, mailing
lists, reviews<br>
4. Clarifications on the intellectual property considerations<br>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1
level1 lfo2"></p>
Next to Dan and Ed, Howard agrees to co-author this document. And
that sends a strong positive signal.<br>
<br>
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?<br>
Dan Romascanu will present this issue at the OPS-AREA meeting.<br>
<br>
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.<br>
<br>
<br>
Regards, Benoit (OPS A.D.)<br>
<br>
<br>
<br>
<br>
</body>
</html>
--------------070800000707090109030301--
--===============9086378527263073356==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Hubmib mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hubmib
--===============9086378527263073356==--