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

[John Flick <[e-mail]>]

As you have probably already seen, I submitted an updated I-D which
I believe addresses Bert's comments below.  See below for more
details on the changes to the doc.

John

"Wijnen, Bert (Bert)" wrote:
> 
> Sorry that it took so long

Sorry I took almost as 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)

I added the following IANA considerations section:

10.  IANA Considerations

   This document does not define any new name space to be administered
   by IANA.  However, section 3.2.4 does specify that some of the
   defined values in a current IANA-maintained name space are to be
   marked as deprecated or obsolete.  In particular, the following
   enumerated values in the IANAifType TEXTUAL-CONVENTION in the
   IANAifType-MIB module need to have an ASN.1 comment added stating
   that they have been deprecated:

       - iso88032Csmacd(7)
       - starLan(11)

   In addition, the following enumerated values need to have an ASN.1
   comment added stating that they are obsolete:

       - fastEther(62)
       - fastEtherFX(69)
       - gigabitEthernet(117)

   In all of the above cases, the ASN.1 comment should indicate that
   ethernetCsmacd(6) should be used instead of these values.


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

I didn't add this recommendation, since the WG consensus on deprecating
those ifTypes was pretty clear.  Not sure if IANA contacts registrants on
a change like this anyway, but I don't think that it would change the
WG consensus.

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

As a result of subsequent comments from Mike Heard, and based on the MIB
Review guidelines that were recently published, I updated the  DESCRIPTION
of the MODULE-COMPLIANCE statement as follows:

           DESCRIPTION "The compliance statement for managed network
                       entities which have ethernet-like network
                       interfaces.

                       Note that compliance with this MIB module
                       requires compliance with the ifCompliance3
                       MODULE-COMPLIANCE statement of the IF-MIB
                       [RFC2863].  In addition, compliance with this
                       MIB module requires compliance  with the
                       mauModIfCompl3 MODULE-COMPLIANCE statement of
                       the MAU-MIB [MAU-MIB]."

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

As noted in a message from Mike Heard, IANA does not maintain the
chip set OID name space, so there is nothing to add to IANA considerations
here.

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

REVISION clause now reads as follows:

           REVISION    "200302280000Z"  -- February 28, 2003
           DESCRIPTION "Updated to include support for 10 Gb/sec
                        interfaces.  This resulted in the following
                        revisions:

                        - Updated dot3StatsAlignmentErrors and
                          dot3StatsSymbolErrors DESCRIPTIONs to
                          reflect behaviour at 10 Gb/s
                        - Added dot3StatsRateControlAbility and
                          dot3RateControlStatus for management
                          of the Rate Control function in 10 Gb/s
                          WAN applications
                        - Added 64-bit versions of all counters
                          that are used on high-speed ethernet
                          interfaces
                        - Added object groups to contain the new
                          objects
                        - Deprecated etherStatsBaseGroup and
                          split into etherStatsBaseGroup2 and
                          etherStatsHalfDuplexGroup, so that
                          interfaces which can only operate at
                          full-duplex do not need to implement
                          half-duplex-only statistics
                        - Deprecated dot3Compliance and replaced
                          it with dot3Compliance2, which includes
                          the compliance information for the new
                          object groups

                        In addition, the dot3Tests and dot3Errors
                        object identities have been deprecated,
                        since there is no longer a standard method
                        for using them.

                        This version published as RFC XXXX."
       -- RFC Ed.: Replace XXXX with the actual RFC number & remove
       -- this note

> - 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 this is covered by the changes to the DESCRIPTION clause in
the MODULE-COMPLIANCE shown above.

> - I believe there are a number of deprecated objects that do not include
>   a reason why they were deprecated in the DESCRIPTION clause.

I believe these are all covered now.

> - for line -- dot3 8 (on page 46) you have a reference [31] which I cannot
>   find in the references section

Updated to [RFC2666].

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

See above.

> - Security considerations
>   - might be best to list the writeable objects and hwy they are
>     sensitive.

Added the following:

   There is one management object defined in this MIB that has a MAX-
   ACCESS clause of read-write.  That object, dot3PauseAdminMode, may be
   used to change the flow control configuration on a network interface,
   which may result in dropped packets, or sending flow control packets
   on links where the link partner will not understand them.  Either
   action could be detrimental to network performance.

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

Added the following:

   Most of the objects in this MIB module contain statistical
   information about particular network links.  In some network
   environments, this information may be considered sensitive.
 
> 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.

Abstract now reads:

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines objects for managing Ethernet-like
   interfaces.

   This memo obsoletes RFC 2665.  It updates that specification by
   including management information useful for the management of 10
   Gigabit per second (Gb/s) Ethernet interfaces.

   Distribution of this memo is unlimited.  Please forward comments to
   [e-mail].

The paragraph about ongoing evolution of Ethernet was moved to the Intro,
to keep the Abstract short and to the point.

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

Done

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

Done - updated boilerplate, and updated references accordingly.

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

Fixed.

> 
> Thanks,
> Bert
> _______________________________________________
> Hubmib mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/hubmib
_______________________________________________
Hubmib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hubmib