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

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi David,

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

Dan



> -----Original Message-----
> From: David Harrington [mailto:[e-mail]]
> Sent: Sunday, July 29, 2012 7:39 AM
> To: Romascanu, Dan (Dan); Michael MacFaden; [e-mail];
> [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific
MIB
> Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt)
> 
> Hi,
> 
> The original email said:
> >
> >    2. A table mapping the old IETF MIB names with the corresponding
> new
> >    IEEE ones
> 
> From RFC2578, section 10:
>   As experience is gained with an information module, it may be
>    desirable to revise that information module.  However, changes are
>    not allowed if they have any potential to cause interoperability
>    problems "over the wire" between an implementation using an
original
>    specification and an implementation using an updated
>    specification(s).
> 
> and:
> Note that changing the descriptor associated with an existing object
>    is considered a semantic change, as these strings may be used in an
>    IMPORTS statement.
> 
> 
> 
> And:
> if the semantics of any previously defined object are
>    changed (i.e., if a non-editorial change is made to any clause
other
>    than those specifically allowed above), then the OBJECT IDENTIFIER
>    value associated with that object must also be changed.
> 
> 
> So if the name will be changed, then the associated OID must be
changed,
> And interoperability will be harmed by changing the descriptor or the
> OID.
> 
> Implementations using the old mib module and implementations using the
> new mib module will likely have interoperability problems if the
> descriptor, the OID, or the semantics of an object are changed.
> 
> Tread carefully ...
> 
> 
> --
> David Harrington
> Internet Engineering Task Force (IETF)
> [e-mail]
> [phone]
> 
> 
> 
> 
> 
> On 7/28/12 9:09 PM, "Romascanu, Dan (Dan)" <[e-mail]> 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: [e-mail] [mailto:[e-mail]]
On
> >> Behalf Of Michael MacFaden
> >> Sent: Saturday, July 28, 2012 8:38 AM
> >> To: [e-mail]; [e-mail]; [e-mail];
> >> [e-mail]
> >> Cc: [e-mail]; [e-mail]
> >> 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 [[e-mail]]
> >> Received: Friday, 27 Jul 2012, 9:55pm
> >> To: Benoit Claise [[e-mail]]; adslmib mailing list
> >> [[e-mail]]; [e-mail]
> >> CC: Howard Frazier [[e-mail]]; [e-mail]
> >> 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
> >> [e-mail]
> >> [phone]
> >>
> >>
> >>
> >>
> >>
> >> On 7/27/12 7:13 PM, "Benoit Claise" <[e-mail]> 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
> >> >[e-mail]
> >> >https://www.ietf.org/mailman/listinfo/ops-area
> >>
> >>
> >> _______________________________________________
> >> OPS-AREA mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ops-area
>