Re: Draft-iet-bridge-bridgemib-smiv2-09.txt

On Wed, 19 Jan 2005, David B Harrington wrote:
> Draft-iet-bridge-bridgemib-smiv2-09.txt has been submitted for
> advancement.
> It has already been reviewed by myself and Dan R. (WG chairs), and
> Juergen S. (the editor).
> We should have an independent MIB Doctor review of the document.
> Anybody willing to do this?

Here are the findings of a quick mini-review:

1.) I-D Boilerplate -- OK

2.) Abstract -- OK

3.) MIB Boilerplate -- OK

4.) Security Considerations Section -- OK

5.) IANA Considerations Section -- OK

6.) References -- OK

7.) Copyright Notices -- the one in the MIB module has a 2004
date.  That (and the LAST-UPDATED/REVISION clause dates) should
be brought up-to-date if another revision is spun;  if no other
things are corrected this can probably be left to the RFC Editor.

8.) IPR Notice -- OK

9.) Other issues -- a few editorial nits (and one item that I
consider important) were picked up:

(a) unexpanded acronym (PICS, in Sec. 3.1):

   Transmission Priority           These objects are not required
                                   as per the Pics Proforma and
                                   not considered useful.

If in the judgment of the editors the audience is likely to know
what a PICS Proforma is and that one would be found in IEEE Std
802.1D-1998 then maybe this is OK (it was not a problem for me).

(b) grammar:

3.1.2  The dot1dStp Subtree

   This subtree contains the objects that denote the bridge's state with
   respect to the Spanning Tree Protocol.  If a node does not
   implemented the Spanning Tree Protocol, this subtree will not be
   implemented.

s/If a node does not implemented/If a node does not implement/

(c) style:

3.1.3  The dot1dSr Subtree

   This subtree contains the objects that describe the entity's state
   with respect to source route bridging.  If source routing is not
   supported this subtree will not be implemented.  This subtree is
   applicable to source route only, and SRT bridges.  This subtree
   described in RFC 1525 [RFC1525] is applicable only to source route
   bridging.

The following replacement text is suggested:

   This subtree is described in RFC 1525 [RFC1525].  It contains the
   objects that describe the entity's state with respect to source route
   bridging.  If source routing is not supported then this subtree will
   not be implemented.

Or even:

   This subtree is described in RFC 1525 [RFC1525].

I like this last the best of all.

(d) inaccurate text:

3.2  Relationship to Other MIB Modules

   As described above, some IEEE 802.1D management objects have not been
   included in this MIB module because they overlap with objects in
   other MIB modules applicable to a bridge implementing this MIB.  In
   particular, it is assumed that a bridge implementing the BRIDGE-MIB
   module will also implement (at least) the 'system' subtree of the
   SNMPv2-MIB [RFC3418] and the 'interfaces' subtree of the IF-MIB
   [RFC2863].

Minimal fix:

s/'system' subtree/systemGroup/ here and in Section 3.2.1

s/'interfaces' subtree/ifGeneralInformationGroup/ here and
in Section 3.2.2

An alternate fix, to cater to old (RFC 1493) implementations,
would be to say in this section:

"In particular, it is assumed that a bridge implementing the
BRIDGE-MIB module will also implement (at a minimum) either
the 'system' and 'interface' subtrees of MIB-II [RFC1213] or
the systemGroup of the SNMPv2-MIB [RFC3418] and the
ifGeneralInformationGroup of the IF-MIB [RFC2863]."

with similar changes in 3.2.1 and 3.2.2.  Note that RFC 1213
would have to be added as a normative reference.

Note: I consider the above to be a MUST FIX, since otherwise
the specification of the prerequisites is just too vague.

10.) Technical content -- the extent of my technical review was
to go over the output from smidiff.  I noticed a couple of things:

(a) the following is (formally) a violation of the revision rules
in RFC 2578 Section 10, since it might result in a compilation
failure of a module that IMPORTS MacAdress from BRIDGE-MIB instead
of from SNMPv2-TC:

/usr/local/share/mibs/ietf/BRIDGE-MIB:17 [1] {type-removed} type
`MacAddress' has been deleted

An RFC content search revealed that all of the published IETF MIB
modules (other than BRIDGE-MIB) that use MacAddesss actually
import it from SNMPv2-TC.  However, that might not be true of
enterprise MIB modules or of MIB modules maintained by other SDOs,
and there is no effective way I know of to search for such usage.

So I wonder if it might not have been better to have left the
definition in place, but to make its status 'deprecated' and
have text pointing potential users to the version in SNMPv2-TC.

I won't squawk if the WG wants to leave this as is.

(b) also, the following changes violate our MIB review guidelines:

BRIDGE-MIB.mi2:194 [5] {named-number-changed} warning: named number
`transparent-only' changed to `transparentOnly' at type used in
`dot1dBaseType'
BRIDGE-MIB.mi2:194 [5] {named-number-changed} warning: named number
`sourceroute-only' changed to `sourcerouteOnly' at type used in in
`dot1dBaseType'

See draft-ietf-ops-mib-review-guidelines-03.txt, section 4.9, first
bullet on p. 29.  The WG will have to judge for itself whether the
issue raised there applies in this case (I think it does, but I am
not interested in picking a fight if the WG disagrees).  Note that
if this change is backed out then smilint will complain about the
hyphens (as it does about legacy read-only index columns).

(c) As a result of 9(d) above, I noticed that the compliance
statements do not spell out the prerequisites, as is has been
done in some recent MIB modules.  It might be worthwhile to
consider doing that here.  For bridgeCompliance1493 it would be
necessary to specifiy this information in the DESCRIPTION clause
(since, presumably, that one would call out the old MIB-II
subtrees).  For bridgeComplianceXXXX one could IMPORT the
systemGroup from SNMPv2-MIB and the ifGeneralInformationGroup
from IF-MIB and list them in the MANDATORY-GROUPS clause.

Note:  IMHO, this is just a nice-to-have.  Spelling out the
prerequisites in the text of Section 3 is good enough for me.
The OPS AD for NM has been know to disagree with me on this :-)

Mike Heard