Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

[Edward Beili <[e-mail]>]

David, Tom,
I tend to agree with you on the "Updates" vs. "Obsoletes" argument.

The main reason for this I-D was to let people who read IETF documents know about the move of the responsibility for further EFM-CU-MIB evolution from the IETF HUBMIB WG to the IEEE 802.3 and let them be aware of the new IEEE8023-EFM-CU-MIB module, which incorporated the old EFM-CU-MIB in its entirety (duplicating and renaming all the object definitions from the EFM-CU-MIB).

You are correct that there are existing implementations of the EFM-CU-MIB that would not be upgraded to IEEE8023-EFM-CU-MIB any time soon. In my opinion most equipment and NMS vendors, my company included, would not spend the effort of supporting the new MIB, unless the IEEE would introduce some amazing new functionality, which I highly doubt. Currently the IEEE8023-EFM-CU-MIB is an exact replica of the EFM-CU-MIB, with the exception of the naming prefixes. It is because of this reason I would prefer not to deprecate the EFM-CU-MIB.

I'm not that familiar with the Updates clause though. If we leave the RFC5066 valid can't we also leave the IF-CAP-STACK-MIB still defined there, having only some explanatory text in the rfc5066bis, letting the readers know about the IEEE document?


Now, with respect to your comment about the copyright:
1. I am the author of RFC 5066 and I can assure you that the phrase "greatly advanced" was a polite way of saying "commented and reviewed" as opposed to "co-authored".
2. The IEEE sought my sole permission already in Nov 2010 to grant the IEEE the right to include the RFC 5066 in the IEEE P802.3.1, here's a quote from the original communication:

"The IEEE 802.3 working group wishes to incorporate portions of IETF RFC 5066 as part of
IEEE Draft Standard IEEE P802.3.1 Ethernet MIBs and to develop, modify and evolve such
portions as part of the IEEE standardization process.
The IETF Trust has recently informed us that under the Intellectual Property provisions of IETF
RFC 3978 'IETF Rights in Contributions', the IETF Trust does not possess all rights needed for
the IEEE to make derivative works of IETF RFC 5066 outside the IETF Standards Process.
Instead such rights are retained by the original authors, and that the IEEE has to therefore obtain
such rights by contacting the original authors.
Since you are the author of IETF RFC 5066, the IEEE hereby requests that you kindly agree to
submit your contributions in IETF RFC 5066 to the IEEE for inclusion in IEEE P802.3.1. Please
note that IETF IESG is aware of this request.
Attached hereto, please find a copyright permission letter template that we ask you kindly
complete, sign and return, granting the aforementioned rights to the IEEE."

Since the IEEE has already obtained my permission with the IESG "blessing" and published the first version of the IEEE8023-EFM-CU-MIB, I don' think we should demand more than that for the rfc5066bis, which simply documents the current state of affairs.

Regards,
-E.

-----Original Message-----
From: ietfdbh [mailto:[e-mail]]
Sent: Thursday, January 10, 2013 22:13
To: 't.petch'; 'Scott O Bradner'
Cc: [e-mail]; Edward Beili
Subject: RE: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

Hi,

I agree Obsoletes is not accurate.
I think Updates might be accurate.

However, I think the text is inaccurate:
"That MIB module will be part of a separate
   document, maintained by the Institute of Electrical and Electronics
   Engineers (IEEE) 802.3 working group."
I disagree with this statement.

The EFM-CU-MIB is being frozen as is, and a NEW MIB module is being created, called IEEE8023-EFM-CU-MIB.
RFC2578 does not allow renaming of a MIB module:
" Note that any definition contained in an information module is
   available to be IMPORT-ed by any other information module, and is
   referenced in an IMPORTS clause via the module name.  Thus, a module
   name should not be changed.  Specifically, the module name (e.g.,
   "FIZBIN-MIB" in the example of Section 5.7) should not be changed
   when revising an information module (except to correct typographical
   errors), and definitions should not be moved from one information
   module to another.

   Also note that obsolete definitions must not be removed from MIB
   modules since their descriptors may still be referenced by other
   information modules, and the OBJECT IDENTIFIERs used to name them
   must never be re-assigned."

So claiming that the EFM-CU-MIB is being renamed is inaccurate because that would violate SMIv2 rules.
All the object definitions in EFM-CU-MIB will also need to be renamed and duplicated under IEEE8023-EFM-CU-MIB.
Otherwise NMS applications that import EFM-CU-MIB and IEEE8023-EFM-CU-MIB would not be able to easily distinguish which OID is appropriate.

Since EFM-CU-MIB cannot be legally "moved" to IEEE8023-EFM-CU-MIB, and existing devices and applications may continue to support it, I recommend the existing MIB module should retain its current status.
If we want to recommend that people utilize IEEE8023-EFM-CU-MIB, we can provide an Updates clause to update the RFC5066 status, but since it contains an active MIB it really should not be Obsoleted.
If we want to deprecate the EFM-CU-MIB and recommend IEEE8023-EFM-CU-MIB, then I think the EFM-CU-MIB MIB module would need to be published again with an SMIv2 deprecated status (and all the objects would presumably need to be deprecated as well).
If we deprecate the EFM-CU-MIB module and its objects, the "relationship to other MIB modules" would need some serious updating to discuss the impact of the deprecation on other modules (including proprietary MIB modules) that depend on EFM-CU-MIB.


David Harrington
[e-mail]
[phone]
-----Original Message-----
From: t.petch [mailto:[e-mail]]
Sent: Thursday, January 10, 2013 5:19 AM
To: ietfdbh; 'Scott O Bradner'
Cc: [e-mail]; 'Edward Beili'
Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

---- Original Message -----
From: "ietfdbh" <[e-mail]>
To: "'t.petch'" <[e-mail]>; "'Scott O Bradner'"
<[e-mail]>
Cc: <[e-mail]>; "'Edward Beili'" <[e-mail]>
Sent: Tuesday, January 08, 2013 10:07 PM

> Hi,
>
> I would be careful with assumptions about the existing IETF
standards-track
> MIB vanishing, even if IEEE is going to maintain comparable
definitions
> under an IEEE subtree going forward.
>
> Existing devices and managers might support the RFC5066 EFM-CU-MIB,
and
> those devices may never be updated to the new IEEE version.
> The IETF standards-track EFM-CU-MIB should still be considered a valid
MIB
> module; it just should not be modified going forward.
> The IEEE version should replace it for new implementations, and the
IEEE
> version could supplement the IETF EFM-CU-MIB in new and updated
> implementations, to support continued interoperability.

David

So in practical terms, what would you do?  Currently the I-D has an 'Obsoletes 5066' which I think wrong, since the new I-D omits the vast mass of 5066; and, as you rightly point out, the EFM-CU-MIB module could well be with us for a long time (and we have no change control over the IEEE module that one day may replace it).

Leave 5066 as Standards Track with this as an Updates (which it isn't, its a reproduce a small part thereof unchanged as far as I can see)?

I will go on objecting to Obsoletes even if I cannot see what the alternative should be:-)

Tom Petch

> David Harrington
> [e-mail]
> [phone]
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf Of
> t.petch
> Sent: Tuesday, January 08, 2013 5:18 AM
> To: Scott O Bradner
> Cc: [e-mail]; Edward Beili
> Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt
>
> ---- Original Message -----
> From: "Scott O Bradner" <[e-mail]>
> To: "t.petch" <[e-mail]>
> Cc: "Romascanu, Dan (Dan)" <[e-mail]>; "Edward Beili"
> <[e-mail]>; <[e-mail]>
> Sent: Saturday, January 05, 2013 2:25 PM
>
> On Jan 5, 2013, at 7:45 AM, t.petch <[e-mail]> wrote:
>
> > I wonder if this I-D should really supersede RFC5066.  I would
rather
> > see RFC5066 become Historic with this as an Updates.
>
> a historic document does not exist (standards track wise) so there
would be
> nothing to update -
>
> also- an update would not be a complete replacement (i.e. some of the
old
> document would still be in force) - is that the case here (i.e.
> do you think that this is not a full replacement?)
>
> Scott
>
> As Dan said,
> "RFC 5066 defines two MIB modules. One (this one) continues to be
maintained
> by the IETF. There is no need for a change. The other
> (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names
under
> the IEEE802 subtree. That document is now in Sponsor Ballot by the
IEEE-SA."
>
> so the vast majority of RFC5066 vanishes into IEEE and is transformed
> therein.
>
> The bit that is left, ifCapStackMIB, is unaltered from RFC5066 (hence
the
> reuse of the number in the mib tree).
>
> I do not know what the best way to describe this in our documentation
is!
>
> As to Copyright, RFC5066 has one editor but the work was "greatly
advanced
> by the contributions of the following people"
> which lists eight such people, so no, I do not think that the editor
of
> RFC5066bis can make the necessary grant.
>
> RFC5066 predates the change of rules, increasing the grants, by a
year.
>
> Tom Petch
>
> >
> > Should the Copyright carry the caveat about old material for which
the
> > current rules may not apply?  Since this MIB Module is going to see
> > extensive use by another SDO, this seems particularly relevant.
>
> the author of the old doc is the author of the new doc and is
submitting the
> new doc under the current rules (and gave himself permission to do
that)
>
> Scott
>
>
> > Tom Petch
> >
> >
> > ----- Original Message -----
> > From: "Romascanu, Dan (Dan)" <[e-mail]>
> > To: "Edward Beili" <[e-mail]>; <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Thursday, January 03, 2013 6:00 PM
> >
> >> Hi Ed,
> >>
> >>> 3. You probably meant "No action is required from IANA ..."
> >>
> >> Of course, thanks for catching this.
> >>
> >>
> >>> 4. Shall I wait for other comments or should I just issue the next
> >>> version of the draft?
> >>>
> >>
> >> Let us wait for a couple of days. Hopefully we will get an answer
> from
> > Howard concerning a better reference for the IEEE 802.3.1a Rev 2
> draft,
> > and maybe other comments from the OPSAWG or the IEEE folks.
> >>
> >> Please issue a revised version by the start of the next week, as I
> > plan to enter my Sponsor Ballot comment on the IEEE document, and I
> need
> > a reference to the best IETF I-D available at that moment.
> >>
> >> Thanks and Regards,
> >>
> >> Dan
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Edward Beili [mailto:[e-mail]]
> >>> Sent: Thursday, January 03, 2013 7:55 PM
> >>> To: Romascanu, Dan (Dan); [e-mail]
> >>> Cc: [e-mail]
> >>> Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt
> >>>
> >>> Dan,
> >>> Thank you for the comments, I agree with everything, except for
the
> >>> following:
> >>>
> >>> 2. I will leave the IEEE 803.2.1-2011 reference for now, until
IEEE
> >>> 802.3 would provide a publically accessible link.
> >>>
> >>> 3. You probably meant "No action is required from IANA ..."
instead
> > of
> >>> "New action is required form IANA ...", i.e. the correct paragraph
> > would
> >>> be:
> >>>
> >>> OLD:
> >>>
> >>>   Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have
> > been
> >>>   allocated by IANA in the MIB-2 sub-tree.
> >>>
> >>> NEW:
> >>>
> >>>   No action is required from IANA as the OID for ifCapStackMIB
> > MODULE-
> >>> IDENTITY
> >>>   was already allocated in [RFC5066].
> >>>
> >>> 4. Shall I wait for other comments or should I just issue the next
> >>> version of the draft?
> >>>
> >>> Regards,
> >>> -E.
> >>>
> >>> -----Original Message-----
> >>> From: [e-mail] [mailto:[e-mail]] On
> > Behalf
> >>> Of Romascanu, Dan (Dan)
> >>> Sent: Thursday, January 03, 2013 17:59
> >>> To: [e-mail]
> >>> Cc: [e-mail]
> >>> Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt
> >>>
> >>>
> >>> Thanks to Ed Beili for undertaking this work.
> >>>
> >>> A few comments:
> >>>
> >>> 1. In the Abstract you are making the statement that this
> > specification
> >>> moves the EFM-CU-MIB module to an IEEE document. In fact the IETF
> > does
> >>> not have the rights to do such a move alone, this document should
> > rather
> >>> just recognize this move.
> >>>
> >>> Suggested change:
> >>>
> >>> OLD:
> >>>
> >>>   It amends that specification by moving the entire EFM-CU-
> >>>   MIB module along with the relevant descriptive text, to a
> > separate
> >>>   document, maintained by the Institute of Electrical and
> > Electronics
> >>>   Engineers (IEEE) 802.3.1 working group.
> >>>
> >>> NEW:
> >>>
> >>>   It amends that specification by taking out the entire EFM-CU-
> >>>   MIB module along with the relevant descriptive text. That MIB
> > module
> >>>   will be part of a separate document, maintained by the Institute
> > of
> >>>   Electrical and Electronics Engineers (IEEE) 802.3 working group.
> >>>
> >>> Also in Section 1:
> >>>
> >>> OLD:
> >>>
> >>>   This
> >>>   version moves the entire EFM-CU-MIB module along with the
> > relevant
> >>>   descriptive text, to a separate document, maintained by the
> > Institute
> >>>   of Electrical and Electronics Engineers (IEEE) 802.3.1 working
> > group.
> >>>
> >>> NEW:
> >>>
> >>>   This version
> >>>   removes the entire EFM-CU-MIB module along with the relevant
> >>> descriptive
> >>>   text. That MIB module will be part of a separate document,
> > maintained
> >>> by
> >>>   the Institute of Electrical and Electronics Engineers (IEEE)
> > 802.3.
> >>>   working group.
> >>>
> >>> 2. In Section 3.1:
> >>>
> >>>   The EFM-CU-MIB module defined in the previous version of this
> >>>   document, along with the relevant descriptive text, is now moved
> > to a
> >>>   separate, IEEE maintained document, IEEE Std 802.3.1-2011
> > [802.3.1],
> >>>   which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB.
> >>>
> >>> - Instead of 'the previous version of this document' we should
just
> > say
> >>> [RFC5066].
> >>> - We should provide a more updated version of the IEEE standard
> > which
> >>> contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot
> > would
> >>> be fine, but the access is restricted. I suggest to ask advice
from
> >>> Howard Frazier.
> >>>
> >>> 3. I suggest that Section 7 mentions that no (new) IANA actions
are
> >>> required because it's the same root already allocated in RFC 5066.
> >>>
> >>> OLD:
> >>>
> >>>   Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have
> > been
> >>>   allocated by IANA in the MIB-2 sub-tree.
> >>>
> >>> NEW:
> >>>
> >>>   New action is required from IANA as the OID for ifCapStackMIB
> > MODULE-
> >>> IDENTITY
> >>>   was already allocated in [RFC5066].
> >>>
> >>> Regards,
> >>>
> >>> Dan
> >>>
> >>>
> >>> _______________________________________________
> >>> OPSAWG mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/opsawg
> >> _______________________________________________
> >> OPSAWG mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsawg
>
>
>
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
>
>