draft-squire-hubmib-efm-mib-00.txt

Here are some comments and questions on draft-squire-hubmib-efm-mib-00.txt. Please take them into consideration for the next revision of the document.

Regards,

Dan


A. Technical
A1. Oui should be defined as a Textual Convention. The editor note in the text asks the question 'Is this defined anywhere else?' As far as I know, it is not.
A2. Must include Conformance clause for the MIB module to compile correctly
A3. Wrt. the Technical note asking 'where in the existing MIB hierarchy we wish to hang these new capabilities' the current Draft got it right. The MIB Guidelines http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02.txt recommend to create new MIB modules under mib-2. You need to add however the following note to the RFC Editor:
-- RFC Ed.: replace XXX with IANA-assigned number & remove this note 
A4. I find contradictory the fact that while the DESCRIPTION clause of dot3OamTable states that 'There will be one row in this table for each Ethernet-like interface in the system that supports the Ethernet OAM functions', the rows in the table are created by managers. I think that row creation should be automatic, as the agent knows when an interface has OAM capabilities. If the OAM capabilities need not be activated on a given interface, the operator can use dot3AdminState to disable them.
A5. The editorial notes around dot3OamOperStatus seem to indicate that some changes are required in Clause 30. I would like to know where these changes are, taking into account the phase of the IEEE Draft, and I recommend that we make sure to have alignment before the two documents.
A6. I think that row creation in dot3OamPeerTable should be automatic. The agent knows the value of dot3OamOperStatus on the interface, and needs not wait for a manager command in order to activate the function on the interface.


B. Editorial - Major

B1. Must fill in the Reference section. Moreover, references need to be split in separate Normative and Informative references. See http://www.ops.ietf.org/mib-boilerplate.html
B2. I would like to have Section 3 more verbose about the other EFM MIB documents. A users of these MIBs will probably read this document first, and look for some guidance. The other two MIB modules should be mentioned in the Informative References, and the fact that it is expected that the Common OAM MIB be supported for any OAM flavor should be mentioned.
B3.Must include Security section
B4. Must Include Intellectual Property section
B5. Must include Copyright Notices section


C. Editorial - Minor

C1. It is strongly recommended that internet-drafts include a notice (with e-mail address) of where comments should be sent.
C2. The document does not belong to the 'Network Working Group' as specified in the header. As the next version will be an official WG document, I suggest to mention 'Ethernet Interfaces and Hub MIB'.
C3. References in the text should point to the IEEE document in the Normative References section, wherever relevant
C4. The DESCRIPTION Clause of efmCommonMib mentions the October version of the P802.3ah Draft. You need to include a note to the RFC editor to replace this reference with the normative standard reference, when it will be available.
C5. Get rid of the commented variables in the dot2OamTable, unless you intent to make some point that I am missing them by leaving them there.
C6. I suggest that the editorial note after dot3OamUnidirectional Support be introduced in the DESCRIPTION clause
C7. If 'OAM Frames' and 'OAM PDUs' are synonym, I suggest that frames be replaced by PDU in the DESCRIPTION clauses of dot3OamPduTx and dot3OamPduRx.
C8. Fill-in all TBD references in the MIB