Re: AD review of draft-ietf-hubmib-mau-mib-v3-02.txt
John Flick <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
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 protected]
> 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.