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

On Mon, Jan 24, 2005 at 10:54:54PM -0800, C. M. Heard wrote:
 
> Here are the findings of a quick mini-review:

Thanks Mike. Let me briefly react to your comments.
 
> 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.

I probably need to learn how to let xml2rfc put in the right year
automatically. ;-)
 
> 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).

Would be no problem to spell out Protocol Implementation Conformance
Statement (PICS) or to simply add a reference to 802.1D-1998 if
someone confirms that this document actually contains the PICS
referred to here. Can someone please check?
 
> (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/

ack

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

Either if find with me. The second is probably more user friendly while
the last one is surely the least problematic one.
 
> (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.

This text has been vague in RFC 1493 and I just tried to keep it 
vague. Note that s/'system' subtree/systemGroup/ does not really 
work since the systemGroup includes objects that did not really 
exit when RFC 1493 was published. I also prefer to avoid the 
introduction of a normative reference to [RFC1213]. So if you 
want clarity, the right approach is IMHO to simply list the 
system objects that did exist when RFC 1493 was published.
(We could even define this formally in the compliance statement 
by importing the objects and defining a suitable group. The 
IETF so far to my knowledge has never done formal dependency 
definitions in this way.)

Note that the some reasoning applies to the 'interfaces' subtree.
I again doubt that ifGeneralInformationGroup is exactly what was
meant when RFC 1493 was published. If we dive deeper, then we
have to note that things like ifInNUcastPkts, which were current
definitions at the time RFC 1493 was published, are now deprecated.
So do we document what was meant by RFC 1493 or do we document 
what makes sense with our current interpretation of the IF-MIB? 
Since we now go for Proposed rather Standard, we might actually 
do the later. But still, we should be careful since we have lots 
of deployed implementations of this MIB.
 
> 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.

The formally correct solution would have been to keep the MacAddress
definition, changing the status to obsolete and to import the
MacAddress from SNMPv2-TC and use it throughout the MIB module.
Since both TCs have the same name, one would have to use module
qualified names (SNMPv2-TC.MacAddress). While this is legal and
would formally precisely say what we are trying to achieve, doing
so very likely breaks a number of simple minded MIB parsers...
 
> (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).

CLR #1: hyphens are not allowed in named numbers labels
CLR #2: you should not change named number labels

So which one ranks higher? I can go both ways. But whatever we do,
it won't be perfect.
 
> (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.

As I wrote above, simply using the systemGroup and the
ifGeneralInformationGroup may not cut it. Thers is also the
ifFixedLengthGroup and the ifPacketGroup that I think applies
and conditionally the ifHCFixedLengthGroup and ifHCPacketGroup
and all the other material in RFC 2863. Can we not simply
request that implementations must comply to ifCompliance3?
(There is unfortunately no SMI construct to reference another
compliance statement.)

/js
 
-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany