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

Sorry that it took so long

- Sect 3.1 claims/states that rfc2668 will go to historic.
  Well, you can recommend that in this document, but the WG cannot
  just declare it. Maybe it is best to wriet a small doc that
  recommends this action, similar to the way it was done for
    draft-ietf-hubmib-1643-to-historic-01.txt
  And maybe at the same time you can ask to make 2239 Historic
  (instead of claiming so in sect 3.2) And are you also trying
  to get 1515 to historic per sect 3.3?
- MODULE-IDENTITY latest (time wise) revision clause says
  that updates were done for 10G support. I think that that
  is indeed correect, but it would be probably good to add
  that you also therefor added 64 bit counters, 
  And how about the new enumerations as listed under (6) in sect 
  A.1.?

- When I see things like:
          dot3MauType10Base5 OBJECT-IDENTITY
           STATUS      current
           DESCRIPTION "thick coax MAU (per 802.3 section 8)"
           ::= { dot3MauType 2 }
  then I thing that (per 802.3 section) is probably better captured
  in some sort of REFERENCE clause, no?
  You have a few more of those
- in DESCRIPTION for  rpMauJabberingStateEnters I read
      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 rptrMonitorPortLastChange."
  So I wonder if I should not see that under teh MODULE-COMPLIANCE

- in DESCRIPTION clause of ifMauMediaAvailableStateExits I read:
                     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."
  So I wonder if I should not see that under teh MODULE-COMPLIANCE

- I wonder if it would not be wise to change
      ifMauType OBJECT-TYPE
          SYNTAX      OBJECT IDENTIFIER
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "This object identifies the MAU type.  An
                      initial set of MAU types are defined above.  The
                      assignment of OBJECT IDENTIFIERs to new types of
  into
      ifMauType OBJECT-TYPE
          SYNTAX      AutonomousType
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "This object identifies the MAU type.  An
                      initial set of MAU types are defined above.  The
                      assignment of OBJECT-IDENTITIES to new types of
  I think it is cleaner and I think it is a change that is allowed,
  the underlying datatype is still OBJECT IDENTIFIER

- Smae question for ifMauDefaultType

Nits and administrative comments

- The RFC-Editor does no longer accept more than 5 authors/editors
  on front page, see: http://www.rfc-editor.org/policy.html
  I know I suggested the current format a year or so ago.
  But RFC-Editor is changing the rules. Probably it is best to
  keep John as Editor on front page and move the other names
  in the acknowledgement section or in a contributors section
  (this ection is talked about in the rfc-editor policy)
- In the abstract, it is sufficient to list just the RFC that is
  being obsoleted, no need to have the title too.
- you skip from sect 3.3. to sect 3.5 
  is 3.4 missing, or did the counter just bump?
- 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
- would it not be better to move the comments just before ifMauAutoNegTable
  into the DESCRIPTION clause of the table itself?
- You have a number of objects and compliances that are deprecated.
  It would be good to add a sentence (or two) to explain why.
  Oops, I see that is stated at the end of the DESCRIPTION clause.
  Mmm.. maybe would have been better at the beginning.
- You may want to add in DESCRIPTION clause of broadMauBasicTable why the
  table was deprecated

OK, I am still waiting for output from a smidiff run to check if indeed
all changes are legal. So based on that output I may have some more.

Thanks,
Bert