I wonder if this I-D should really supersede RFC5066. I would rather see RFC5066 become Historic with this as an Updates.
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. 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
