Re: Draft-harrington-8021-mib-transition-00.txt

["C. M. Heard" <heard@pobox.com>]

>>>>> On 7 Oct 2005, David B Harrington wrote, in a message to Mreview:
dbh> This is the current plan for transitioning the responsibility for
dbh> work on subsequent bridge-related MIB modules from the Bridge WG
dbh> to the IEEE 802.1 WG.
dbh> 
dbh> Please review this document.

Thank you for the opportunity to comment on this document.

I see one very big "red flag" at the beginning of Section 3.1:

   [discuss] We need to work out just how the transition of
   responsibility for existing MIB modules will happen.  The IETF will
   not want to give up all rights to the documents, and have the 802.1
   WG simply republish the existing documents under the IEEE name.

More years ago than I care to admit a very wise boss of mine stated
that "responsibility without authority is untenable".

In my considered opinion, if the IETF is going to transfer
maintenance responsibility for the following MIB modules to
the IEEE 802.1 WG:

BRIDGE-MIB (RFC 4188)
RSTP-MIB (draft-ietf-bridge-rstpmib-09.txt)
P-BRIDGE-MIB DEFINITIONS (draft-ietf-bridge-ext-v2-07.txt)
SOURCE-ROUTING-MIB (RFC 1525)

then the IETF and/or the IAB should make whatever grant of rights is
necessary so that the 802.1 WG will have exactly the same authority
to modify those MIB modules that the Bridge MIB WG or any other IETF
WG would have if responsibility for maintaining those MIB modules
were being kept in the IETF.

>>>>> On 7 Oct 2005, Juergen Schoenwaelder put it this way:
js> I do believe that we will see valid requests for changes of these
js> MIB modules and we better plan ahead for that. Otherwise, people
js> will indeed end up copying lots of objects under new OIDs which
js> is a [pain] for interoperability and a clear failure of our
js> process (which puts interoperability first).  In other words, I
js> believe we need to agree that the IETF either (a) continues to
js> publish updates to the relevant 802 MIB under IETF control or
js> that (b) the IETF officially transfers the control of the
js> toplevel OIDs used by these MIBs over to the IEEE.

and I agree completely.

The mechanics that I would suggest would be something like this:

- as long as the MIB modules in the above-mentioned publications
  are satisfactory to the 802.1 WG, the IEEE may continue to
  incorporate the IETF Proposed Standard RFCs by reference.

- if the 802.1 WG concludes that one of these MIB modules needs to
  be modified, it will include the modified module in an approved
  802.1 standard, along with whatever narrative material is
  appropriate, and will also make the MIB module available for
  download in machine-readable (i.e., ASCII) form.  The 802.1 WG
  will also submit an Internet-Draft (to be published as an
  informational RFC) explaining why the modifications were
  necessary and asking the IESG to reclassify the now-obsolete
  MIB document as HISTORIC.  It is expected that the 802.1 WG
  will submit the modified MIB module for MIB Doctor review
  prior to approval, in order to ensure that it meets requisite
  standards of quality (e.g., it must compile) and that there
  are no changes that are not allowed by the SMI.

--------------------------------------------------------------------
The rest of this memo consists of comments on the various section of
the draft in the orer in which they appear.

Section 1:  should not the Q-BRIDGE-MIB, RFC 2764, be listed amongst
the IETF bridging-related MIB modules whose upkeep is being
discussed in the draft?

 RFC 2674 Definitions of Managed Objects for Bridges with Traffic
 Classes, Multicast Filtering and Virtual LAN Extensions E. Bell,
 A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie

Also, the newtrk WG is planning to ask the IESG to reclassify RFC
1525 as HISTORIC as part of the bulk decomissioning experiment in
http://www.ietf.org/internet-drafts/draft-ietf-newtrk-decruft-experiment-00.txt
If responsibility for the SOURCE-ROUTING-MIB is going to be
transferred to the IEEE, then this RFC should be excluded from
the bulk decomissioning experiment.  On the other hand, if RFC
1525 is going to be made HISTORIC, then there will be no further
maintenance and and there is no reason to transfer responsibility.


Section 2.2:  I don't think that the concern expressed in the
following paragraph is really a problem, as long as the recommended
narrative is included in the published IEEE standard that contains
the MIB module.  IEEE standards are, after all, publically
available, and are freely available six months after publication.

   There may be some issues about what gets included in the freely
   available specification.  The MIB module alone will probably be
   insufficient; some discussion of the structure of the MIB, the
   anticipated use cases for MIB objects, the relationship to other MIB
   modules, and security considerations will also need to be made
   available to ensure appropriate implementation and deployment of the
   MIB module within the Internet environment.

I would, therefore, be inclined to eliminate the above paragraph.
A bigger concern is that some of the MIB module extracts on the
IEEE web site do not pass a basic syntax check.  The 2001 version
of the 802.1X MIB module is one such module;  for the corrections
needed, see the I-D draft-ietf-bridge-8021x-03.txt (URL below).
I would therefore recomment to replace the following paragraph

   The 2001 version of the ASN.1 MIB module for 802.1X
   (the IEEE8021-PAE-MIB) has been published in ASCII on
   http://www.ieee802.org/1/pages/MIBS.html, but should be updated with
   enough surrounding documentation to be clear, and to address
   deployment issues such as security considerations.

with something like this:

   The 2001 version of the SMIv2 MIB module for 802.1X
   (the IEEE8021-PAE-MIB) has been published in ASCII on
   http://www.ieee802.org/1/pages/MIBS.html, but has syntax errors
   and so is unsuitable for import into most network mangement
   systems.  It is recommended that this module be replaced with an
   updated version that corrects these errors.


Also in Section 2.2:

   [discuss] Did the 802.1 WG submit a document for 802.3ad, or is
   this a typo?

It's probably a typo.  The 802.3 WG did publish such a MIB module,
and it's accessible from their "machine readable extracts" page at

http://grouper.ieee.org/groups/802/3/publication/index.html

or directly via this URL:

http://grouper.ieee.org/groups/802/3/publication/ad/IEEE8023-LAG-MIB.txt

A web search turned up no evidence that this MIB module was ever
submitted for publication in an Informationl RFC, and a content
search of the RFC database confirmed that no such RFC was ever
published.


At the end of Section 2.2 it says:

   The 802.1 WG has, with some projects (e.g., 802.1X, 802.3ad)
   submitted a MIB module document to be published as an informational
   RFC.  Since the IEEE is publishing a corresponding document as a
   standard, and the RFC is only informational, it would probably be
   better to point interested parties to the appropriate 802.1 WG public
   website to prevent confusion over who is maintaining the document.
   As we transition existing Bridge WG documents to the 802.1 WG, and
   the 802.1 WG document obsoletes the last IETF version, the Bridge WG
   or the 802.1 WG should create a corresponding RFC that simply points
   to the openly available IEEE copy, so we don't have a problem with
   synchronization between the copies being published.

   [discuss] I haven't been able to locate the Informational RFC for
   802.1X MIB.

The reason you have not been able to find such an RFC is because the
project was abandoned and the draft was allowed to expire.  The last
version of the draft is archived here:

http://www.potaroo.net/ietf/old-ids/draft-ietf-bridge-8021x-03.txt

If I remember the history correctly, the IEEE had an update to this
MIB module in the works that had already incorporated the proposed
corrections, and it appeared that the new IEEE version would appear
before this document was published as an RFC.  So this whole
paragraph can probably be eliminated.  (On the other hand, I don't
see an updated version of the 8021x MIB on the IEEE web site, hence
the previous suggestion to prod the IEEE regarding to this matter.)


Section 3.1:  I've already presented my objections to the first
paragraph and won't repeate them here.  I agree with the second two
paragraphs, and I think that it would be most approriate for the
IETF to write a short I-D regarding the issues that were left open.
(The fact that there were such issues is a good reason to ensure
that the IEEE has the authority to modify the MIB modules.)


Sections 3.2-3.3:  I don't agree with the "no-update" strategy.  As
I said above, the IEEE 802.1 WG should have the same authority to
modify the bridge MIB modules as an IETF WG would have, but should
also be bound by the same revision rules.  I suggested above a
possible strategy for doing updates.

Section 3.4: when it is necessay to add one or two objects to a
MIB module, it is clearly simpler (and better for the users) to
revise the module rather than put them in another module.  Again,
the solution is to give the IEEE 802.1 WG the same authority to
modify these MIB modules that an IETF WG would have.  Note that
an IETF WG does not have to go back to IANA to add objects to an
existing module ... the OIDs for new objects are subordinate to
nodes that have already been allocated.  The whole problem is
cleanly solved if the IETF just transfers authority for the OID
subtrees used by the bridge modules to the IEEE, as suggested above
by Juergen Schoenwalder.  This would also remove the motivation to
replace the existing bridge modules with new ones that are
registered under the IEEE OID tree.  That would be VERY BAD
for interoperability and should be strongly resisted.


Some editorial comments are being sent privately to the author.

Mike Heard