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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 17 Nov 2002 15:08:25 +0100

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

---

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

Speaking here as WG member ...

>   to ask them to deprecate those registrations based on recommendations

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.

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

>   Should also be listed in IANA considerations section

But dot3StatsEtherChipSet values are not maintained by IANA.

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

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

>   I guess changing it to Integer32 would be OK since it is same base type.

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

---

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

Regards,

Mike Heard