AD review of draft-ietf-hubmib-wis-mib-04.txt

Sorry that this took so long

- SMICng tells me that Gauge32 is being used without being IMPORTED

- object etherWisDeviceTxTestPatternMode starts ENUM at zero.
  I see the other INTEGER based ENUM does too
  I know it is a CLR, but if it is no problem, then why not start 
  at 1 as recommended by RFC2578?

- thinking aloud: would it be good to do 2 MODULE COMPLIANCES?
  - one etherWisReadOnlyCompliance which is basically the one you now
    have
  - one etherWisFullCompliance that does not specify the min-access to
    read-only
  But I am not sure, cause we do not allow just read-only to the writable
  objects in this MIB module, while we do allow sonet objects to be
  read-only. Maybe I do not understand exactly why?

- Sections 3.1, 3.2 and 3.3 talk about requirements to implement pieces
  of other MIB modules. I see some of it (from sonet mib) back in the
  MODULE-COMPLIANCE. Should we not just include all of the required
  objects from other MIB modules in the MODULE-COMPLIANCE?

-  etherWisDeviceRxTestPatternErrors is a read-write Gauge32
   If I understand it correctly, then you can only SET a value of zero
   If this is a correct understanding, then I would expect to see that
   specified in the MODULE-COMPLIANCE with a WRITE-SYNTAX Gauge32(0)

- In the security section, it would be good to also say someting
  about (non-)vulnerability of read-only objects
   

Editorial/nits
- RFC-Editor no longer accepts more taht 5 authors on front page
  see http://www.rfc-editor.org/policy.html
- Not sure RFC-Editor will accept WAN as acronym in title
  see: http://www.rfc-editor.org/policy.html
- pls expand acronyms when they are first used. For example sect
  3 PCS, PMA, PHY
  see: http://www.rfc-editor.org/policy.html
- It would be good to add the wg mailinglist info to the DESCRIPTION
  clause of the MODULE-IDENTITY
- You talk in various MIB objects about ifAdminState, but I think the
  correct descriptor is ifAdminStatus
- etherWisSectionCurrentJ0Transmitted
  While it is a value "to be transmitted"
  WOuld it be good to reflect that in the descriptor, maybe
     etherWisSectionCurrentJ0ToBeTransmitted
  You have a few more of those

Questions:
- Can you explain why in sections 3.8.1, 3.8.2, 3.8.3 and 3.8.4 
  you use SHALL and not MUST ?? 
- Do we know if/when the IEEE normative document will be final
  so that the normative reference can be resolved?

Thanks,
Bert