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

On Tue, Jan 25, 2005 at 01:55:53AM -0800, C. M. Heard wrote:

> > 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.)
> 
> Actually that is not legal;  conformance groups must be defined in
> the same module with the objects or notifications that they contain.

You are right.
 
> > 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.
> 
> 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.

See my conclusion at the end of this message.

> > > 10.) Technical content -- the extent of my technical review was
> > > to go over the output from smidiff.  I noticed a couple of things:
> ...
> > > (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.
> 
> #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.

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

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

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