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

Reply via email to