Subject: [Bridge-mib] Re: Draft-iet-bridge-bridgemib-smiv2-09.txt

From: "C. M. Heard" <[email-masked]>
Date: Mon, 24 Jan 2005 22:54:54 -0800 (PST)

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-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Jan 2005 09:19:55 +0100

> Here are the findings of a quick mini-review:

Thanks Mike. Let me briefly react to your comments.
 
> 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. ;-)
 
> 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?
 
> s/If a node does not implemented/If a node does not implement/

ack

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

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 25 Jan 2005 01:55:53 -0800 (PST)

> definitions in this way.)

Actually that is not legal;  conformance groups must be defined in
the same module with the objects or notifications that they contain.

> of deployed implementations of this MIB.

My problems are not just the vagueness of Section 3.2, but with the
outright inaccuracy of and 3.2.2, wrought by just changing the
reference from RFC 1213 to RFC 2863.  Specifically, 3.2.2 says:

   In the Interfaces Group MIB [RFC2863], the 'interfaces' subtree is
   defined as being mandatory for all systems and contains information
   on an entity's interfaces, where each interface is thought of as
   being attached to a `subnetwork'. 

As written that is false.  It would be true, however, if one
substituted "ifGeneralInformationGroup" in place of "'interfaces'
subtree", as that group is the only one that is unconditionally
mandatory for all interface types.

3.2.1 says:

   In the SNMPv2-MIB [RFC3418], the 'system' subtree is defined as being
   mandatory for all systems.  Thus, those objects apply to the entity
   as a whole irrespective of whether the entity's sole functionality is
   bridging, or whether bridging is only a subset of the entity's
   functionality.

What RFC 3418 actually says is that the systemGroup defines objects
that are common to all managed systems.  In this case it so happens
that the systemGroup contains all the objects in the 'system'
subtree, and no others.

In defense of my "minimal fix" proposal, note that (a) the two
groups do include all the objects from SNMPv2-MIB and IF-MIB that
are mentioned in Section 3.1, and (b) it is the simplest way I can
see to fix the inaccurate text in Section 3.2.2.

> > to go over the output from smidiff.  I noticed a couple of things:
...
> So which one ranks higher? I can go both ways. But whatever we do,

#1 is a CLR since it is there because people didn't like hyphens,
even though they did no harm (proof: SMIv1 was fine with them).

#2 is not a CLR since it is there to keep people from making changes
that cause existing MIB modules not to compile when a new rev is
introduced.

So, #2 trumps #1.

And in this case, #1 does not even apply:  RFC 2578 grants an
exemption to the no-hyphen rule for MIB modules that are translated
from SMIv1.

But as I said, I will not pick a fight about this.

> (There is unfortunately no SMI construct to reference another

There is no formal construct, but you can do so with the DESCRIPTION
clause.  See the compliance statements in RFCs 3535 and 3536 for
some examples.  Both of those require that implementations support
ifCompliance3.  And for the systemGroup stuff, you could IMPORT it
from SNMPv2-MIB and mention it in the MANDATORY-GROUPS clause.

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 25 Jan 2005 02:00:12 -0800 (PST)

On Tue, 25 Jan 2005, C. M. Heard wrote:
> See the compliance statements in RFCs 3535 and 3536

I meant to say RFCs 3635 and 3636.

//cmh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Jan 2005 11:41:27 +0100

> the same module with the objects or notifications that they contain.

You are right.
 
> see to fix the inaccurate text in Section 3.2.2.

See my conclusion at the end of this message.

> But as I said, I will not pick a fight about this.

I certainly do not want to discuss the merrit of these rules here. I
can life either way. But it would be good if the conclusion how we
deal with this case could be recorded so that we do things consistently
the next time this pops up.
 
> from SNMPv2-MIB and mention it in the MANDATORY-GROUPS clause.

So from this, I conclude that we probably want to add the following 
to the compliance statements:

	Note that compliance with this MIB module requires
	compliance with the ifCompliance3 MODULE-COMPLIANCE 
	statement of the IF-MIB (RFC2863) and compliance with
	the snmpBasicComplianceRev2 MODULE-COMPLIANCE of the
	SNMPv2-MIB (RFC3418).

Section 3.2.1 would be changed to the following:

	Implementations of the BRIDGE-MIB must comply with the
	snmpBasicComplianceRev2 MODULE-COMPLIANCE statement in 
	the SNMPv2-MIB [RFC2863].

Section 3.2.2 first paragraph would be changed to the following:

	Implementations of the BRIDGE-MIB must comply with the
	ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB
	[RFC2863]. In the IF-MIB terminology, an interface is
	thought of as being attached to a `subnetwork'.  (Note 
	that this term is not to be confused with `subnet' which 
	refers to an addressing partitioning scheme used in the 
	Internet suite of protocols.) The term 'segment' is used 
	in this memo to refer to such a subnetwork, whether it 
	be an Ethernet segment, a 'ring', a WAN link, or even an
        X.25 virtual circuit.

We may want to add after the first sentence (although this should 
be clear from reading the IF-MIB):

	This includes mandatory support of the ifFixedLengthGroup,
	the ifPacketGroup, and the ifCounterDiscontinuityGroup of
	the IF-MIB [RFC2863], which are conditionally mandatory
	in the ifCompliance3 statement.

Searching for the word subnetwork in the document, I found that
it is used in the description of dot1dTpLearnedEntryDiscards
and to be consistent, this should probably have been segment
rather than subnetwork.

/js

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 25 Jan 2005 08:22:31 -0500

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-masked]
co-chair, IETF Bridge WG

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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
>

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 25 Jan 2005 09:49:55 -0800 (PST)

On Tue, 25 Jan 2005, Juergen Schoenwaelder wrote:
> > > > bullet on p. 29.  [ ... ]
...
> the next time this pops up.

In that case I would ask that the original labels be reinstated, in
compliance with the MIB review guidelines, because I think that the
MIB review guidelines are correct as written.

> > > > statements do not spell out the prerequisites [ ... ]
...
> 	be an Ethernet segment, a 'ring', a WAN link, or even an

Making compliance with snmpBasicComplianceRev2 raises the bar quite
a bit higher than necessary.  That compliance statement imposes a
requirement for SNMP instrumentation.  Maybe that's a good thing to
have, but it's not necessary to support the BRIDGE-MIB.  If suffices
to support the systemGroup.  But, if it is agreed to go that route,
I will have no quarrel.

>       in the ifCompliance3 statement.

Leave that out.  Redundant text runs the risk of being
contradictory, and this is such a case.  ifFixedLengthGroup and
ifPacketGroup are mutually exclusive in ifCompliance3.  Let RFC 2863
speak for itself.

The one other fix that I would suggest along with the above would be
the following new text for Sec. 3.2:

   module will also implement the SNMPv2-MIB [RFC3418] and the IF-MIB
   [RFC2863].

> the IESG it has been independently reviewed.

In that case I will withdraw all of my merely "nice-to-have" comments,
and I can resubmit the remaining stuff as IETF Last Call comments.  That
would include the editorial stuff plus the two issues discussed above.

Mike

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 25 Jan 2005 13:03:23 -0500

Hi,

My responses to your comments, inline.

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

> things are corrected this can probably be left to the RFC Editor.

[as chair] The RFC editor can handle this if needed.

> (a) unexpanded acronym (PICS, in Sec. 3.1):
Good catch. However, I expect everybody implementing this mib module
will know this term from IEEE.
[as chair, if required by the RFC Editor, we can handle during 48hour
review]

> 3.1.3  The dot1dSr Subtree
[...]
I agree your text is cleaner, but the current text is "good enough"

> s/'interfaces' subtree/ifGeneralInformationGroup/ here and

1) We need to be backwards compatible with RFC1493. We should use
(roughly) the same text used there. RFC1493 had vague prerequisites;
we cannot tighten them now without potentially making compliant
implementations non-compliant. The RFC3418 systemGroup requires more
objects than the RFC1213 system subtree. If we want to make this
change in how relationships are described, then we should open RFC3418
and add a compliance for the RFC1213 set of system objects, much as we
have done in this document with bridgeCompliance1493.
2) RFC1493 does not refer to compliance groups, but to the system and
interface groups, which in SMIv1 modules meant subtrees. So I don't
agree that the text is inaccurate, just vague.
3) We've gone around in circles on all our documents, and documents
being developed in IEEE 802.1, about whether the expectation is for
the system group in RFC1213 or the one in RFC3418; the fact is that
the expected objects are all in RFC1213, and the additional objects
defined in RFC3418 are not related to the bridge mib objects. I can
live with either specification. I agree that having both creates
unnecessary normative references (i.e. document dependencies). The
argument is mostly related to IETF-internal issues, like the desire to
declare all SMIv1 modules historic, which has nothing to do with
making it easier to manage a network device.

> the specification of the prerequisites is just too vague.

As a MIB Doctor, I don't consider this a MUST FIX, and I can tell you
that all mib modules in development in the IEEE 802.1 WG do not have
the explicit compliances you consider a MUST FIX. This is also not in
the mib-review-guidelines, is it? 

It might be good to adopt tighter cross-compliances for new mib
modules, after suitable debate, but for updating "relationship" text
for SMIv1 mib modules, I question this approach if it makes compliant
implementations non-compliant. I also have concerns about creating
dependencies between mib module compliances. We moved away from the
MIB-I and MIB-II approach and moved to a modular approach because
having everything integrally tied together was not very workable
within the IETF standards process. I think having these cross-document
compiance-dependencies works against modularity. But this is a debate
for the MIB Doctor forum rather than the bridge mib forum.

If Bert or David consider this a MUST FIX, they can add it to the AD
review comments. Otherwise, I think we should leave it unchanged. 

> failure of a module that IMPORTS MacAdress from BRIDGE-MIB instead
I think changing this to import from SNMPv2-TC is the appropriate
thing to do since the mib module is being converted to SMIv2. The new
IMPORTS statement provides enough information for users to determine
where they should get the definition now, should their compilation
fail. 

As a contributor, I favor keeping it as is.
If Bert wants us to follow your proposal, he can add it to the AD
review.

> hyphens (as it does about legacy read-only index columns).

I do agree that technically this should not change for backwards
compatibility reasons. OTOH, the elimination of hyphaens makes it
easier to script using object names rather than OIDs. 

I don't consider this a major issue, relative to this enumeration,
because I don't think many application developers will utilize this
enumeration. In my mind, it makes no difference which we use.

If the Ads would like to see this revert to its RRFC1493 names, they
can add it to the AD Review and we'll make the change.

> The OPS AD for NM has been know to disagree with me on this :-)

I think discussions of additional nits for mib reviews belongs on the
MIB Doctor list rather than the bridge mib list.

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 25 Jan 2005 13:13:03 -0500

Mike, 

If you provide us with a list of necessary changes, we can discuss
them and make them part of the AD review process.

We are definitely looking to eliminate nice-to-have changes and
proposed mib review requirements that are not currently included in
the mib-review-guidelines-03. 

[soapbox]
Working against constantly moving targets is one major reason why
these documents have already taken three years. If it wasn't defined
as a requirement when we started WGLC, I don't want to hear about it
now.
[end soapbox]

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

> Sent: Tuesday, January 25, 2005 12:50 PM
> To: Bridge-Mib (E-mail)
> Subject: Re: [Bridge-mib] Re:
Draft-iet-bridge-bridgemib-smiv2-09.txt