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

Reply via email to