Subject: [Hubmib] AD review of draft-ietf-hubmib-mau-mib-v3-02.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 17 Nov 2002 05:23:12 +0100

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 
_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 19 Nov 2002 20:07:27 -0800 (PST)

Speaking here as WG member ...

On Sun, 17 Nov 2002, Wijnen, Bert (Bert) wrote:
>   So I wonder if I should not see that under [the] MODULE-COMPLIANCE

I disagree with that.  The DESCRIPTION clause is the place to
specify mandatory side-effects.  The compliance section does
not mention any IF-MIB objects, and for good reason:  the IF-MIB
ifCompliance3 statement is already (implicitly) incorporated by
reference, and since we are dealing with a packet-oriented interface,
it tells us that ifCounterDiscontinuityTime is mandatory.  Compliance
information from the IF-MIB that is incorporated by reference should
not be repeated in the MAU-MIB.

> - [Same] question for ifMauDefaultType

A possible counter-argument:  the DESCRIPTION clause for
AutonomousType says:

            "Represents an independently extensible type identification
            value.  It may, for example, indicate a particular sub-tree
            with further MIB definitions, or define a particular type of
            protocol or hardware."

The rub is that independently assigned values for ifMauType and
ifMauDefaultType -- while allowed -- are second-class citizens
compared to the ones that are defined in the MIB module.  All
the values defined locally have a corresponding bit position
in the object ifMauTypeListBits, which advertises the supported
values for ifMauType and ifMauDefaultType.  All independently
defined values are represented by the bOther(0) bit position.
This seems to me to go against the spirit of the DESCRIPTION
clause quoted above.

Having said all that, I won't object to the change if it still
seems like a good idea.

>   (this ection is talked about in the rfc-editor policy)

Maybe I missed something, but I didn't see a hard limit of five
authors.  In any case, would it not be reasonable to request that
documents this long in the pipeline be "grandfathered" as protection
against the shifting sands of changing rules?

>   that makes it clear to everyone, and then mib reviewers do not have to

This is a good idea, but it won't really save a MIB reviewer any work.
Trusting ASN.1 comments should not be part of a MIB reviewer's job
description, he/she should independently do the verification.

Thanks,

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 19 Nov 2002 20:07:27 -0800 (PST)

Thanks,

Mike Heard