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

Speaking here as WG member ...

On Sun, 17 Nov 2002, Wijnen, Bert (Bert) wrote:
> - 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 [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.

> - 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
> 
> - [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.

> - 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)

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?

> - 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

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