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

Speaking here as WG member ...

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

Hmm, it seems to me that listing desultory maintenance details is
not not what RFC 2434 says an IANA considerations section is for.
It is supposed to give IANA instructions on how to administer a
namespace, which in this case is the set of values of IANAifType.
That belongs in the (next version of the) IF-MIB and not here.
This document should not need an IANA considerations section.
What we should do is just make sure that IANA adds the appropriate
ASN.1 comments to the IANAifType.  Once it is done we don't need
to have the action item documented in for posterity in an RFC.

> - sect 3.2.10
>   the things about ifAdminStatus and ifOperStatus are actually things that
>   we should also express in the MODULE-COMPLIANCE statements.

Please no!  We've never been required before to do this, and it would
make for a LOT of compliance section maintenance work.  Notice that
this is new requirement (change of rules) to which EVERY ONE of the
media-specific MIBs would be subjected.

There is a very good practical reason, BTW, to leave matters as they
are.  In order to put these semantic refinements which traditionally
have been documented in the narative part of the MIB document into
the compliance section we'd have to duplicate all of the applicable
information that is already present in the IF-MIB's ifCompliance3
statement, because the SMI does not provide a way to refine a compliance
statement.  All of that duplicate information would, in my opinion,
create a tremendous maintenance burden.  Compliance information from
the IF-MIB should be incorporated by reference, with the necessary
semantic refinements done as they are now, in English prose.

> - sect 3.4 
>   Should also be listed in IANA considerations section

But dot3StatsEtherChipSet values are not maintained by IANA.

> - 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 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 EtherLike-MIB.

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

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

This is inherited from the original definition in RFC 1643, which was
written in SMIv1 (where Integer32 didn't exist).  I'm OK either way.

Regards,

Mike Heard