Re: AD review of draft-ietf-hubmib-etherif-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.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
[email protected].
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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib