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

Hi,

My responses to your comments, inline.

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

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of C. M. Heard
> 
> 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.

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

> 
> 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):
> 
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"

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

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.

> 
> Note: I consider the above to be a MUST FIX, since otherwise
> 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. 

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

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


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.


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

I think discussions of additional nits for mib reviews belongs on the
MIB Doctor list rather than the bridge mib list.
> 
> Mike Heard
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
>