[Hubmib] My review of: draft-ietf-hubmib-efm-cu-mib-06.txt

["Wijnen, Bert (Bert)" <[e-mail]>]

My WG LC review comments are here.
For the EFM-U-MIB itself I will do a separate posting to the list.

- Abstract 3rd line

    This document proposes an extension to the Ethernet-like Interfaces

  By the time we get published as RFC, we no longer "propose".
  So how about:

    This document describes extensions to the Ethernet-like Interfaces

- Page 7, a nit:
           // pottentially be connected to the PCS
  s/pottentially/potentially/
                 // for PCS[i] and there room for another PME in the
  s/there room/there is room/ ??

- A nit/typo on page 10:
   | ifIndex       | Interface index. Note that each PME and each PCS  |
   |               | in the EFMCu PHY MUST have a unique index, as     |
   |               | there some PCS and PME specific attributes        |
   |               | accessible only on the PCS or PME level.          |

  s/as there some/as there are some/ ??

- a type in 2nd para in sect 4.2

   The PME profiles are defined in efmCuPme2BProfileTable and
   efmCu10PProfileTable for 2BASE-TL and 10PASS-TS PMEs respectively.

  I think: s/efmCu10PProfileTable/efmCuPme10PProfileTable/
  So insert "Pme"

- SMICng IF-CAP-STACK-MIB tells me:

    W: f(IF-CAP-STACK-MIB.mi2), (195,17) Row "ifInvCapStackEntry"
       does not have a consistent indexing scheme - index items must
       be in same order as used in INDEX clause for "base row"
       ifStackEntry

  The above is OK, it is an INVERTED table.
  So we can ignore the warning.

    E: f(IF-CAP-STACK-MIB.mi2), (291,13) Item "ifInvStackGroup"
       should be IMPORTed

  I think that error should be fixed and we shoul dimport that group.

- SMICNg EFM-CU-MIB tells me:

    W: f(EFM-CU-MIB.mi2), (300,21) Item "efmCuPAFDiscoveryCode" should
       have SIZE specified

   Do we know a reasonable size for this? In the pseudo code on pages 7/8
   it speaks about a 6-byte (octet) code. And so does the DESCRIPTION 
   clause. Is it always fixed to 6 octets?
   Now and in future? If so, I would suggest to use

        SYNTAX      PhysAddress (SIZE(6))

    W: f(EFM-CU-MIB.mi2), (1178,21) Item "efmCuPAFRemoteDiscoveryCode"
       should have SIZE specified

   Same story for the above.

    W: f(EFM-CU-MIB.mi2), (2925,23) For "efmCuPmeSubTypesSupported",
       syntax is identical

   This is probably OK, although it looks a bit weird:
          OBJECT      efmCuPmeSubTypesSupported
          SYNTAX      BITS {
            ieee2BaseTLO(0),
            ieee2BaseTLR(1),
            ieee10PassTSO(2),
            ieee10PassTSR(3)
          }
          DESCRIPTION
            "Support for all subtypes is not required. However at least
            one value SHALL be supported"

- W.r.t. the SYNTAX of objects ifCapStackStatus and ifInvCapStackStatus
  I think it would be much better to use a SYNTAX of TruthValue.
  See my separate posting on this topic to the HubMIB WG list.

- I believe that instead of

      ifCapStackConformance OBJECT IDENTIFIER
      ::= { ifCapStackObjects 3 }

  It would be better to adhere to the strcuture suggested by RFC4181 page 38
  and so use instead:

     ifCapStackConformance  OBJECT IDENTIFIER ::= { ifCapStackMIB 2 }

- I still need to review the EFM-CU-MIB module. I will do a separate posting
  on that one once I am done.

- In the Security Considerations section I see capitalized MAY
  which I think is not what RFC2119 intended. Unless you can 
  explain to me why this capilaized MAY makes sense, I would
  prefer if we change it to just lowercase "may" for all
  occurences in the Security Considerations section.

- 2nd para on page 83 (a NIT):
    Even if the network itself is secure (for example by using IPSec),
  pls change "IPSec" into "IPsec", that is a lower case "s".
  The current MIB security template has it fixed. I know that the
  Security ADs want/prefer the proper spelling.

- IANA Considerations.
  Since you state that some values SHALL be defined in the
  IANA-MAU-MIB, I think that you make rfc3636bis a normative
  reference, while it is now listed under informative. And by making
  that document normative, you/we automagically make sure that this
  efmCuMIB will not get published before 3636bis.

  You must also request/ask (in IANA COnsiderations section) that 
  IANA assigns two new OID branches for 

     ifCapStackMIB ::= { mib-2 ZZZ }

     efmCuMIB  ::= { mib-2 YYY }

- If/wehen we do a revision, we must adhere to new boilerplate.
  That means we must change all occurences of:

     Copyright (C) The Internet Society (2006).

  into 

     Copyright (C) The IETF Trust (2006).

  If you are using xml2rfc, thsi can be achieved with:

        ipr="full3978update"

  You can/could not yet know this. I know that this starts on Nov 1st
  (because I was asked to update the IDChecklist.html.

Bert

_______________________________________________
Hubmib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hubmib