please revive the unused references while you are at it Scott
On Jan 7, 2013, at 10:23 AM, "Romascanu, Dan (Dan)" <[email protected]> wrote: > Hi Ed, > > Please issue the next version of the draft - I would like to enter my Sponsor > Ballot comment in the next couple of days. > > Thanks and Regards, > > Dan > > > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Romascanu, Dan (Dan) >> Sent: Thursday, January 03, 2013 8:00 PM >> To: Edward Beili; [email protected] >> Cc: [email protected] >> Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt >> >> 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
