Comments on draft-ietf-hubmib-efm-mib-02.txt

Here are my comments on draft-ietf-hubmib-efm-mib-02.txt. This document being in Last Call, all comments need to be taken into consideration, including the minor ones the comments editorial in nature. 

First running idnits we get the following:

tmp/draft-ietf-hubmib-efm-mib-02.txt:

tmp/draft-ietf-hubmib-efm-mib-02.txt(319): Line has weird spacing: '...ficInfo   dot3...'
tmp/draft-ietf-hubmib-efm-mib-02.txt(325): Line has weird spacing: '...ationTx  dot3O...'
tmp/draft-ietf-hubmib-efm-mib-02.txt(326): Line has weird spacing: '...ationRx  dot3O...'
tmp/draft-ietf-hubmib-efm-mib-02.txt(347): Line has weird spacing: '...dConfig    dot...'
tmp/draft-ietf-hubmib-efm-mib-02.txt(355): Line has weird spacing: '...dConfig  dot3O...'
tmp/draft-ietf-hubmib-efm-mib-02.txt(1691): Line has weird spacing: '...smitted  on th...'

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3667/3668 boilerplate...
  * The document claims conformance with section 10 of RFC 2026, but uses
    some RFC 3667/3668 boilerplate.  As RFC 3667/3668 replaces section 10 of RFC
    2026, you should not claim conformance with it if you have changed to using
    RFC 3667/3668 boilerplate.
  * The document seems to lack an RFC 3667 Section 5.1 IPR Disclosure
    Acknowledgement  -- however, there's a paragraph with a matching beginning.
    Boilerplate error?

  (Expected a match on the following text: 
    "By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of RFC 3668."

   ... but found this:
    "By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    or will be disclosed, and any of which I become aware will be
    disclosed, in accordance with   RFC 3668 [RFC3668].")


  * The document seems to lack an RFC 3668 Section 5, para 3 IPR Disclosure
    Invitation -- however, there's a paragraph with a matching beginning.
    Boilerplate error?

  (Expected a match on the following text: 
    "The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    [email protected]."

   ... but found this:
    "The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    EFM OAM MIB                 October 2004")

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

  * The document seems to lack a 1id_guidelines paragraph about
    Internet-Drafts being working documents -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

  (Expected a match on the following text: 
    "Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-Drafts."

   ... but found this:
    "Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet Drafts.")

More:

Technical

T1. I do not agree with the assertion made in the Security Consideration section that the read-write objects defined in this MIB module do not impact the users traffic, because they are only controls of the OAM protocol. For example the dot3OamLoopbackCommand object, puts the link on loopback mode. Even if there is another object that allows for the remote device to ignore the loopback commands, this does not help if the loopback command objects are activated in an improper manner. Also, an object like dot3OamAdminState if set to disabled(1) will cut-off the OAM functionality of the device, which does have a negative impact on the network behavior and can be considered as a possible source of attack. I would suggest that the editor makes another pass through the read-write objects and explicitly describes all the potential security hazard resulting from inadequate write operations on these objects. 
T2. What is the DEFAULT value of read-write objects like dot3OamAdminState and dot3OamMode? You need to describe the desired behavior of the agent at initialization before the first SetRequest command
T3 In the Security section: 'By default, OAM is disabled on Ethernet-likeEthernet like interfaces and is therefore not a risk.' First there is an editorial problem (repeated words). Second, there may be a technical issue. As far as I remember from my participation in the EFM work, there is no interdiction in the standard to apply OAM to a non-EFM Ethernet interface. Did this change in the latest part of the work, when my attendance became rare?  




Editorial

E1. The expiration date on the footer of all pages excepting the first is longer than the accepted six months period.
E2. Section 3.1 - last phrase '...notifications into within the SNMP ...' needs to be fixed
E3.  Section 3.2, second paragraph - no need to capitalize DOES NOT
E4. Section 4, second phrase - replace 'affects' by 'effects'
E5. Section 4.1 - 'Ethernet-like' is duplicated
E6. Section 4.2 - correct 'ThisThe' in the first phrase
E7. Titles of Section 4 - replace 'MIBs' with 'MIB modules'
E8. First phrase of 4.2 - replace 'MIBs' by 'MIB modules' and MIB document'' by 'MIB module'
E9. Numbering of subsections 4.24.3 and 4.34.4 is broken
E10. Last phrase in 4.34.4 - replace 'MIB' by 'MIB module', decide about 'waymanner'
E11. I would strongly recommend to add UNITS clauses for all objects where these apply, especially for counters
E12. No need for something like  REFERENCE   "N/A". If there is no reference, there is no reference clause.
E13 Avoid using Traps, even in object names (dot3OamTraps, dot3OamTrapsPrefix, etc.) 
E14 Some characters seem to have been corrupted when copied to the [802.3ah reference]  



Regards,

Dan

_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib