AD review of draft-ietf-hubmib-etherif-mib-v3-02.txt

Sorry that it took so long

- sect 3.2.4.
  Talks about deprecated things in IANA registry
  Should also show up as an action in the IANA Considerations section
  (I think IANA already did this, but still better to document
   it as we would normally do)
- Sect 3.2.4 
  Should we recommend (also in IANA Considerations section) that IAN
  tries to contact registrants of those vendor specific ifTypes
  to ask them to deprecate those registrations based on recommendations
  in this document?
- sect 3.2.10
  the things about ifAdminStatus and ifOperStatus are actually things that
  we should also express in the MODULE-COMPLIANCE statements.
- sect 3.4 
  Should also be listed in IANA considerations section
- REVISION clause for this version... 
  - probably also should list which objects/other-things got deprecated
  - and from the change log in the appendix I get the impression we should
    probably list a few more things
- in DESCRIPTION of dot3StatsAlignmentErrors it says:
       Discontinuities in the value of this counter can
       occur at re-initialization of the management
       system, and at other times as indicated by the
       value of ifCounterDiscontinuityTime."
  we can express requirement for ifCounterDiscontinuitytime in the
  MODULE-COMPLIANCE. probably much more of IF-MIB is needed and so should
  or at least could be expressed in MODULE-COMPLIANCE
- I believe there are a number of deprecated objects that do not include
  a reason why they were deprecated in the DESCRIPTION clause.
- for line -- dot3 8 (on page 46) you have a reference [31] which I cannot
  find in the references section
- Missing IANA Considerations section
  IANA wants all actions nicely together in a one section so they can
  quickly see what needs to be done and so they can point people to
  one place as to why they did it.
- Security considerations
  - might be best to list the writeable objects and hwy they are
    sensitive.
  - Are there no other read-only objects that are sensitive? 
  The security ADs have become more picky on these things, so might want
  to review and update.

Nits admin stuff
- In the abstract, it is sufficient to list just the RFC that is
  being obsoleted, no need to have the title too.
- I see read-only access for various INDEX objects. I think we inherited
  this from old SMIv1 MIB modules. WOuld it be good to add a comment line
  that says something aka
    MAX-ACCESS read-only   -- read-only since originally an SMIv1 index
  that makes it clear to everyone, and then mib reviewers do not have to
  re-check all the time
- The references are not split according to the listed split we published
  and agreed upon on the mibs mailing list. But maybe better wait a little,
  cause the new MIB boilerplate is coming out RSN (I think/hope)
- smilint complains that
     709: warning: use Integer32 instead of INTEGER in SMIv2
  which is 
            dot3CollCount OBJECT-TYPE
               SYNTAX      INTEGER (1..16)
  I guess changing it to Integer32 would be OK since it is same base type.
  But... up to editor/wg

Thanks,
Bert