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 Harrington [email protected] +1-603-828-1401 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of t.petch Sent: Tuesday, January 08, 2013 5:18 AM To: Scott O Bradner Cc: [email protected]; Edward Beili Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt ---- Original Message ----- From: "Scott O Bradner" <[email protected]> To: "t.petch" <[email protected]> Cc: "Romascanu, Dan (Dan)" <[email protected]>; "Edward Beili" <[email protected]>; <[email protected]> Sent: Saturday, January 05, 2013 2:25 PM On Jan 5, 2013, at 7:45 AM, t.petch <[email protected]> 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)" <[email protected]> > To: "Edward Beili" <[email protected]>; <[email protected]> > Cc: <[email protected]> > 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:[email protected]] >>> Sent: Thursday, January 03, 2013 7:55 PM >>> To: Romascanu, Dan (Dan); [email protected] >>> Cc: [email protected] >>> 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: [email protected] [mailto:[email protected]] On > Behalf >>> Of Romascanu, Dan (Dan) >>> Sent: Thursday, January 03, 2013 17:59 >>> To: [email protected] >>> Cc: [email protected] >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/opsawg >> _______________________________________________ >> OPSAWG mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
