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

From: John Flick <[email-masked]>
Date: Fri, 07 Mar 2003 18:35:59 -0800

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

As per subsequent discussion, I removed the "go to historic"
wording from 3.1 and 3.3, and state in the Abstract that this
document obsoletes 2668 and 1515.

Note: 1515 should have been obsoleted by 2239, so this is
just fixing an earlier oversight.

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

MODULE-IDENTITY REVISION now reads:

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

                       - Added OBJECT-IDENTITY definitions for
                         10 gigabit MAU types
                       - Added fiberLC jack type to JackType TC
                       - Extended ifMauTypeListBits with bits for
                         the 10 gigabit MAU types
                       - Added enumerations to ifMauMediaAvailable,
                         and updated its DESCRIPTION to reflect
                         behaviour at 10 Gb/s
                       - Added 64-bit version of ifMauFalseCarriers
                         and added mauIfGrpHCStats object group to
                         contain the new object
                       - Deprecated mauModIfCompl2 and replaced it
                         with mauModIfCompl3, which includes the new
                         object group

                        This version published as RFC XXXX."
       -- RFC Ed.: Replace XXXX with the actual RFC number & remove
       -- this note
 
> - 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

REFERENCE clauses added to all mauType OBJECT-IDENTITYs.

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

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 mauModRpCompl2 MODULE-COMPLIANCE statement as follows:

           DESCRIPTION "Compliance for MAUs attached to repeater
                       ports.

                       Note that compliance with this compliance
                       statement requires compliance with the
                       snmpRptrModCompl MODULE-COMPLIANCE statement of
                       the SNMP-REPEATER-MIB [RFC2108]."
 
> - 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

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 mauModIfCompl3 MODULE-COMPLIANCE statement as follows:

           DESCRIPTION "Compliance for MAUs attached to interfaces.

                       Note that compliance with this compliance
                       statement requires compliance with the
                       ifCompliance3 MODULE-COMPLIANCE statement of the
                       IF-MIB [RFC2863] and the dot3Compliance2
                       MODULE-COMPLIANCE statement of the
                       EtherLike-MIB [ETHERIF]."

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

Changed SYNTAX of rpMauType, ifMauType, and ifMauDefaultType to
AutonomousType, and added appropriate IMPORT.
 
> 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)

Changed to list myself as the Editor on the front page and in
the Author's Address section, and moved information about past
editors and contributers to the Acknowledgements section.

> - In the abstract, it is sufficient to list just the RFC that is
>   being obsoleted, no need to have the title too.

Done

> - you skip from sect 3.3. to sect 3.5
>   is 3.4 missing, or did the counter just bump?

Oops.  Fixed.

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

> - would it not be better to move the comments just before ifMauAutoNegTable
>   into the DESCRIPTION clause of the table itself?

Done

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

Moved most descriptions of why things were deprecated to the beginning
of the DESCRIPTION clauses.

> - You may want to add in DESCRIPTION clause of broadMauBasicTable why the
>   table was deprecated

DESCRIPTION of broadMauBasicTable now reads as follows:

           DESCRIPTION "********* THIS OBJECT IS DEPRECATED **********

                       This entire table has been deprecated.  There
                       have been no reported implementations of this
                       table, and it is unlikely that there ever will
                       be.  IEEE recommends that broadband MAU types
                       should not be used for new installations.

                       Table of descriptive and status information
                       about the broadband MAUs connected to
                       interfaces."
 
> 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

Note: also added copyright statement to MODULE-IDENTITY of both this
document and ether MIB document, as required by MIB Review guidelines.
_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: John Flick <[email-masked]>
Date: Fri, 07 Mar 2003 18:35:59 -0800

John

  

 

 

 

Done

Oops.  Fixed.

Done

Done