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

On Tue, 25 Jan 2005, Juergen Schoenwaelder wrote:
> > (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.)

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

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

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

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

Mike