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

Hi,

Let me jump in as chair.

It is important to realize that we have already been through WGLC and
submitted the document for advancement, and cannot make any changes to
the document without "unsubmitting" it. We cannot publish a new
revision for minor changes.

I asked for an independent MIB Doctor review to ensure that there is
nothing **broken** in this document; given that it has been reviewed
by three of four MIB Doctors already, I didn't think it very likely we
missed anything, but an extra pair of eyes doesn't hurt, and reassures
the IESG it has been independently reviewed.

The editorial nits can probably be handled during the author 48-hour
period, but if they are not critical, we will probably just let it go
through as being "good enough".

If there are serious issues, I will alert the AD to include them in
the AD/IESG review and we can fix them during the advancement process
(or "unsubmit" the document an dtry again).

David Harrington
[email protected]
co-chair, IETF Bridge WG

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of C. M. Heard
> Sent: Tuesday, January 25, 2005 1:55 AM
> To: Bridge-Mib (E-mail)
> Subject: [Bridge-mib] 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
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
>