Subject: Re: [Adslmib] [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Jul 2012 03:09:33 +0200

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Michael MacFaden
> Sent: Saturday, July 28, 2012 8:38 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> 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 [[email-masked]]
> Received: Friday, 27 Jul 2012, 9:55pm
> To: Benoit Claise [[email-masked]]; adslmib mailing list
> [[email-masked]]; [email-masked]
> CC: Howard Frazier [[email-masked]]; [email-masked]
> 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
> [email-masked]
> +1-603-828-1401
> 
> 
> 
> 
> 
> On 7/27/12 7:13 PM, "Benoit Claise" <[email-masked]> wrote:
> 
> >
> >
> >
> >
> >
> >
> >    Dear all,
> >
> >    While DISCUSSing draft-ietf-adslmib-gbond-eth-mib-06.txt with the
> >    IESG, an issue was brought up. Let me explain.
> >
> >    The IETF is no longer developing any Ethernet-related MIB modules
> >    and has transferred the responsibility of these development of MIB
> >    modules for Ethernet to the IEEE 802.3 WG. This process has already
> >    started a few years ago, when the HUBMIB WG was shut down. This
> >    process also covers the last RFC produced by the HUBMIG WG, RFC
> >      5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
> ><http://tools.ietf.org/html/rfc5066>.
> >
> >
> >    This RFC5066 contains two MIB modules
> >    1. the EFM-CU-MIB MIB module (Ethernet to the First Mile Copper),
> >    clearly Ethernet-specific
> >    2. the IF-CAP-STACK MIB module is not Ethernet-specific, but
> generic
> >        For example, draft-ietf-adslmib-gbond-eth-mib-07.txt refers to
> >    this MIB module.
> >
> >    However, according to the agreement, it is within the IEEE
> >    competence to develop the IEEE8023-IF-CAP-STACK-MIB in 802.3.1
> >    rather than refer RFC 5066.
> >    The issue was raised that it didn't make sense to refer to the
> >    IEEE8023-IF-CAP-STACK-MIB when this cross-connect functionality is
> >    not used for Ethernet, and that the reference RFC5056 was actually
> >    preferred.
> >
> >    This week, we had an IEEE/IESG meeting where this issue was
> >    discussed between Dan Romascanu (as the IEEE liaison), Howard
> >    Frazier (802.3.1) and myself.
> >    The following has been agreed upon: the EFM-CU-MIB MIB module
> should
> >    be maintained by IEEE, while the IF-CAP-STACK-MIB should be
> >    maintained by the IETF.
> >    Practically, it means:
> >    1. Obsoleting RFC 5066
> >    2. Creating RFC 5066bis. Extracting IF-CAP-STACK-MIB from RFC5056,
> >    with some wording emphasizing the generic nature of this module,
> and
> >    clearly mentioning that the IEEE 802.3.1 is responsible for
> >    EFM-CU-MIB.
> >        Ed Beili agreed to take the lead on this document.
> >    3. The next version of draft-ietf-adslmib-gbond-eth-mib will
> contain
> >    the following text
> >
> >      4.4 Relationship with the IEEE 802.3 MIB modules
> >
> >The IEEE 802.3 working group chartered a task force [IEEE802.3.1] which
> >continues the development of standard MIB modules based on the initial
> >work done in the IETF.  Future projects resulting from the work of this
> >Task Force may include and possibly extend the work done in the IETF,
> >such as [RFC5066].
> >
> >-------------
> >
> >To Informative References add:
> >
> >[IEEE802.3.1] IEEE P802.3.1 Revision to IEEE Std 802.3.1-2011 (IEEE
> >802.3.1a) Ethernet MIBs Task Force,
> >http://grouper.ieee.org/groups/802/3/1/index.html
> >
> >
> >
> >    Thanks to Howard Frazier. Edward Beili, Menachem Dodge, Dan
> >    Romascanu, and Moti Morgenstern for helping with this issue. This
> >    shows an inter-SDO success story IMHO.
> >
> >
> >    A second document has also been discussed.
> >    It would be a good idea to have an informational RFC, similar to
> RFC
> >      4663 - Transferring MIB Work from IETF Bridge MIB WG to IEEE ...
> ><http://tools.ietf.org/html/rfc4663>,
> >    with the following content.
> >    1. Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011
> >
> >      RFC 2108  Ethernet Repeater Devices
> >        RFC 3621 - Power Ethernet MIB
> >        RFC 3635 - Ethernet-like Interface Types
> >        RFC 3637 - Ethernet WAN Interface Sublayer
> >        RFC 4836 - Ethernet Medium Attachment Units (MAUs)
> >        RFC 4837 - Ethernet Passive Optical Networks (EPON)
> >        RFC 4878 - Operations, Administration, and Maintenance (OAM)
> >        Functions on Ethernet-Like Interfaces
> >        RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces
> >        MIB
> >
> >
> >    2. A table mapping the old IETF MIB names with the corresponding
> new
> >    IEEE ones
> >    3. Clarifications/rules on the IETF-IEEE interactions, mailing
> >    lists, reviews
> >    4. Clarifications on the intellectual property considerations
> >
> >    Next to Dan and Ed, Howard agrees to co-author this document. And
> >    that sends a strong positive signal.
> >
> >    There is one open issue though with this second document: should we
> >    send to historic all the MIB modules mentioned above? What would be
> >    the impact for the equipment vendors and NMS applications?
> >    Dan Romascanu will present this issue at the OPS-AREA meeting.
> >
> >    Finally, regarding the future cooperation between the IEEE and IETF
> >    regarding the development of the 802.3.1-2011, Howard Frazier
> >    mentioned that any feedback could be sent directly to him, and that
> >    he would insert it into the ballot.
> >
> >
> >    Regards, Benoit (OPS A.D.)
> >
> >
> >
> >
> >
> >
> >_______________________________________________
> >OPS-AREA mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ops-area
> 
> 
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Jul 2012 07:58:54 +0200

Hi David,

Of course existing management applications will not interoperate as-is
and will need to be changed in order to work with the new IEEE 802.3 MIB
modules. Did anybody claim differently? 

Dan

> From: David Harrington [mailto:[email-masked]]
> Sent: Sunday, July 29, 2012 7:39 AM
> To: Romascanu, Dan (Dan); Michael MacFaden; [email-masked];
> [email-masked]; [email-masked]
> The original email said:
> 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)
> [email-masked]
> +1-603-828-1401
> 
> 
> 
> 
> 
> On 7/28/12 9:09 PM, "Romascanu, Dan (Dan)" <[email-masked]> 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).
> >
> >> Is there a ***technical*** reason that forces a reassignment of
OIDs
> >> per
> >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.
> >> Subject: Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific
> >> MIB Modules (was DISCUSS on
draft-ietf-adslmib-gbond-eth-mib-07.txt)
> >> 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
> >>
> >>
> >> Subject: Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific
> >> MIB Modules (was DISCUSS on
draft-ietf-adslmib-gbond-eth-mib-07.txt)
> >> The IETF Bridge mib modules were widely deployed and used in
> >> Enterprise bridging.
> >> 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.
> >> 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.
> >>
> >> 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.
> >> Is there a ***technical*** reason that forces a reassignment of
OIDs
> >> per
> >> describes the process that was followed to transfer the Bridge MIBs
> >> to IEEE.
> >> The authors typically have granted the IETF the right to publish,
> >> copy, translate, etc. for IETF standardization purposes.
> >> As described in RFC4663 3.1, the authors must agree to allow the
IEEE
> >> to copy and make derivative works from the original documents.
> >> Will IEEE make subsequent 802.3 MIB documents freely available in
> >> text formats?
> >> >      5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces
> >> >MIB <http://tools.ietf.org/html/rfc5066>.
> >> >
> >> >
> >> >        For example, draft-ietf-adslmib-gbond-eth-mib-07.txt
refers
> to
> >> >    IEEE8023-IF-CAP-STACK-MIB when this cross-connect
functionality
> is
> >> >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].
> >> >
> >> >-------------
> >> >
> >> >      RFC 2108 - Ethernet Repeater Devices
> >> >    There is one open issue though with this second document:
should
> we
> >> >    send to historic all the MIB modules mentioned above? What
would
> be

---

From: Michael MacFaden <[email-masked]>
Date: Fri, 27 Jul 2012 22:38:00 -0700 (PDT)

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 

-----Original Message-----
From: David Harrington [[email-masked]]
Received: Friday, 27 Jul 2012, 9:55pm
To: Benoit Claise [[email-masked]]; adslmib mailing list [[email-masked]]; [email-masked]
CC: Howard Frazier [[email-masked]]; [email-masked]
Subject: Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt)

Hi,

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.

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?

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
[email-masked]
+1-603-828-1401

On 7/27/12 7:13 PM, "Benoit Claise" <[email-masked]> wrote:

>    2. the IF-CAP-STACK MIB module is not Ethernet-specific, but generic
>    The following has been agreed upon: the EFM-CU-MIB MIB module should
>    with some wording emphasizing the generic nature of this module, and
>    3. The next version of draft-ietf-adslmib-gbond-eth-mib will contain
>    the following text
>    
>    It would be a good idea to have an informational RFC, similar to RFC
>    2. A table mapping the old IETF MIB names with the corresponding new
>    IEEE ones

---

From: David Harrington <[email-masked]>
Date: Sun, 29 Jul 2012 00:39:07 -0400

Hi,

new

   problems "over the wire" between an implementation using an original

and:

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 ...

On 7/28/12 9:09 PM, "Romascanu, Dan (Dan)" <[email-masked]> wrote:

>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
>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).
>
>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
>