Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol
draft-ietf-bridge-rstpmib-09

IANA Last Call Comments:
Upon approval of this document the IANA will register a mib-2 number in the following registry:
http://www.iana.org/assignments/smi-numbers
We understand this to be the only IANA Action.

[Ballot comment]
Long Gen-ART comment from Harald, preceded by response from author. Non blocking but probably needs revision.

-----

Hi,

The references issue went through a long discussion in the Bridge WG,
with input from members of the IEEE 802.1 WG. The document represents
WG consensus for how to handle a difficult situation.

I agree the documentation can be confusing and am willing to modify it
for clarity.
I suggest that the document be changed by moving the 802.1D-2004
reference into "Informative References", and modifying the sentence
"Following are the references for the above objects in 802.1D-2004
[802.1D-2004]."
Suggested text:
"Following are the references for the above objects in 802.1D-2004
[802.1D-2004]. The 802.1t and 802.1w references are normative; the
802.1D-2004 references are only informative."

Would that be satisfactory?

David Harrington
dbharrington@comcast.net



>> -----Original Message-----
>> From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no]
>> Sent: Monday, August 08, 2005 7:07 AM
>> To: gen-art@alvestrand.no; les_bell@3com.com;
>> vivian_ngai@acm.org; Dan Romascanu; David Harrington
>> Cc: Wijnen, Bert (Bert)
>> Subject: Gen-ART review of draft-ietf-bridge-rstpmib-08 (Last
>> Call review)
>>
>> Background for those who may be unaware of GenART:
>>
>> GenART is the Area Review Team for the General Area of the IETF.
>> We advise the General Area Director (i.e. the IETF/IESG chair) by
>> providing more in depth reviews than he could do himself of

documents

>> that come up for final decision in IESG telechat.  I was selected
>> as the GenART member to review this document.  Below is my review,
>> which was written specifically with an eye to the GenART process,

but

>> since I believe that it will be useful to have these comments more
>> widely distributed, others outside the GenART group are included.
>>
>> This review was done as part of IETF Last Call.
>>
>> Review criteria for WG submissions: "Is this document a reasonable
>> contribution to the area of Internet engineering which it covers? If
>> not, what changes would make it so?"
>>
>> Summary: This document seems ready to go technically, but has
>> nits that
>> should be fixed before publication - in particular, it may need
>> clarification of its references to other documents.
>>
>> Details:
>>
>> This is a relatively small MIB, and it focuses on management, not
>> monitoring; it is basically a set of "switches" to flip the value of


>> various per-port parameters that are used in RSTP and "lamps"
>> that allow
>> you to monitor these parameters' states.
>>
>> Where I get confused is in the technology it builds on.
>>
>> It claims to refer to IEEE 802.1D-1998 as amended by P802.1t
>> and P802.1w,
>> adopted in 2001 according to the reference list, but also
>> claims to refer
>> to IEEE 802.1D-2004. It extends the RFC 1493 MIB, but also
>> refers to the
>> 1493bis MIB, which is in the RFC Editor's queue.
>>
>> All of these documents (2 standards, 2 amendments, 1 RFC and
>> 1 draft) are
>> in the "normative references" section.
>>
>> It's possible that IEEE 802.1D-2004 failed to incorporate the
>> amendments,
>> but this seems unlikely, since section 3 gives mapppings of
>> the variables
>> to 802.1D-2004 section numbers; it's also possible that
>> people are so used
>> to referring to P802.1t and P802.1w that those references are
>> valuable and
>> should be retained. But it's confusing to me, and may be to others.
>>
>> Suggested fix:
>>
>> Move IEEE 802.1D-1998, P802.1t, P802.1w and RFC 1493 to the
>> "Informative
>> references" section.
>> Change section 3 to read:
>>
>>    This document defines managed object for the Rapid Spanning Tree
>>    Protocol defined by the IEEE 802.1D-2004 standard.
>>
>>    Following are the references for the above objects in 802.1D-2004
>>    [802.1D-2004].
>>
>>    RSTP-MIB Name                      IEEE 802.1D-2004 Reference
>>
>>    dot1dStp
>>      dot1dStpVersion                  17.13.4  ForceVersion
>>      dot1dStpTxHoldCount              17.13.12 TxHoldCount
>>      dot1dStpExtPortTable
>>        dot1dStpPortProtocolMigration  17.19.13 mcheck
>>        dot1dStpPortAdminEdgePort      17.13.1  adminEdgePort
>>        dot1dStpPortOperEdgePort        17.19.17 operEdgePort
>>        dot1dStpPortAdminPointToPoint  6.4.3    adminPointToPointMAC
>>        dot1dStpPortOperPointToPoint    6.4.3    operPointToPointMAC
>>        dot1dStpPortAdminPathCost      17.13.11 Path Cost
>>
>>    This extension was initially defined in P802.1t[] and P802.1w[].
>>    For reference, here are the section numbers in those documents:
>>
>>    RSTP-MIB Name                      IEEE 802.1 Reference
>>
>>    dot1dStp
>>      dot1dStpVersion                  (w) 17.16.1  ForceVersion
>>      dot1dStpTxHoldCount              (w) 17.16.6  TxHoldCount
>>      dot1dStpExtPortTable
>>        dot1dStpPortProtocolMigration  (w) 17.18.10 mcheck
>>        dot1dStpPortAdminEdgePort      (t) 18.3.3  adminEdgePort
>>        dot1dStpPortOperEdgePort        (t) 18.3.4  operEdgePort
>>        dot1dStpPortAdminPointToPoint  (w) 6.4.3   
>> adminPointToPointMAC
>>        dot1dStpPortOperPointToPoint    (w) 6.4.3   
>> operPointToPointMAC
>>        dot1dStpPortAdminPathCost      (D) 8.5.5.3  Path Cost
>>
>> Modify the document to consistently refer to IEEE 802.1D-2004
>> and 1493bis
>> as the documents it builds on. RFC 1493 and the older 802.1D
>> version may
>> need to be mentioned as background material.
>>
>> I think section 4 would be clearer if the sentence
>>
>>    The objects in the RSTP-MIB supplement those defined in the

Bridge

>>    MIB [RFC1493bis].
>>
>> started the section, rather than following the description of the
>> relationship between 1493 and 1493bis.
>>
>> Apart from this, I see no issues.
>> No nits found!

[Ballot discuss]
IETF Last Call expires on Aug 19th (one day after IESG telechat)
so I (Bert) will hold a DISCUSS to ensure we evaluate all IETF
LC comments that may come in up to and including the 19th.

[Ballot discuss]
IETF Last Call expires on Aug 19th (one day after IESG telechat)
so I (Bert) will hold a DISCUSS to ensure we evaluate all IETF
LC comments that may come in up to and including the 19th.

[Note]: 'IETF Last Call expires on Aug 19th (one day after IESG telechat)
so I (Bert) will hold a DISCUSS to ensure we evaluate all IETF
LC comments that may come in up to and including the 19th.' added by Bert Wijnen

AD review posted to WG mailing list.
Could do IETF Last Call and consider this as initial last call
comments. Possibly better to a quick rev first.
Checking with WG chairs.

-----Original Message-----
From: bridge-mib-bounces@ietf.org [mailto:bridge-mib-bounces@ietf.org]On
Behalf Of Wijnen, Bert (Bert)
Sent: Friday, June 10, 2005 13:56
To: 'dbharrington@comcast.net'; 'Dan Romascanu (E-mail)';
vivian_ngai@acm.org; Les_Bell@3Com.com
Cc: Bridge-Mib (E-mail)
Subject: [Bridge-mib] AD review: draft-ietf-bridge-rstpmib-06.txt


Serious issues:

- SMICng tells me:

  C:\bwijnen\smicng\work>smicng rstp.inc
  E: f(rstp.mi2), (32,11) Leading sub-Id "mib-2" is not known in current module
  W: f(rstp.mi2), (14,5) "dot1dBridge" imported but not used

  Seems those can be easily fixed.

- I wonder how we control that assignments under dot1dStp will not cause
  conflicts. This MIB module starts to asiign at { dot1dStp 16 } which is the
  next available number according to RFC1493. But how will we keep track?

- I see not text that indicates the persistency behaviour of the read-write
  objects.

NITs and little things:

- I see:
    dot1dStpVersion OBJECT-TYPE
      SYNTAX      INTEGER {
                    stpCompatible(0),
                    rstp(2)
                }
  We normally do not use the zero value in enumerations.
  And why is there not an enum for value 1?
  These are things that people wonder when reading I guess.
  Maybe add some explanation?

- For objects with SYNTAX TruthValue I see (in DESCRIPTION clauses)
  things like TRUE(1) and FALSE(2). WOuld probably be better to
  use lower case.

- dot1dStpPortAdminPointToPoint OBJECT-TYPE
    SYNTAX      INTEGER {
                    forceTrue(0),
                    forceFalse(1),
                    auto(2)
                }
    MAX-ACCESS  read-write
  Enumerations should not start with 0.
  I guess it is because of an underlying protocol reason.
  Might be good to explain that if it is indeed the case.
  I guess the persitency here is mandated by the entry it augemtns
  in the base table. Might be good to state so in the Table or
  Enrty DESCRIPTION clause.

Not sure if you want to do a new rev before I do IETF Last Call
or if you rather consider this as initial IETF Last Call comments.
I can live with that, so that I can start IETF Last Call today so
it will be finished a week before I get back from
vacation, during which week you can address all comments
and spin a new rev.

Whenever you do do a new rev, pls keep this in mind:

$ idnits draft-ietf-bridge-rstpmib-06.txt
idnits 1.72 (17 May 2005)

draft-ietf-bridge-rstpmib-06.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3978/3979 boilerplate...
  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement  --
    however, there's a paragraph with a matching beginning. Boilerplate error?
  * The document seems to lack an RFC 3978 Section 5.4 Copyright Line -- however, there's a
    paragraph with a matching beginning. Boilerplate error?
  * The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78.
    (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim
    RFC 3978 boilerplate.  After 6 May 2005, submission of drafts without verbatim RFC 3978
    boilerplate is not accepted.)

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

    Nothing found here (but these checks does not cover all of 1id-guidelines.txt yet).

  Miscellaneous warnings:

    None.

    Run idnits with the --verbose option for more detailed information.

That is, there is new boilerplate.
RFC3668 was replaced/obsoleted by RFC3978.
latest xml2rfc generates proper boilerplate need to specify
 
 

Let me know if you need a copy of the boilerplate.

Further, checking citations and refrences I find:

!! Missing citation for Normative reference:
  P013 L034: [802.1D-2004]    IEEE Project 802 Local and Metropolitan  Area

!! Missing citation for Normative reference:
  P013 L021: [RFC2674]    Bell, E., Smith, A., Langille, P., Rijhsinghani, A. and

!! Missing Reference for citation: [USM]
  P012 L013:    of the User-based Security Model [USM] and the View-based Access

!! Missing Reference for citation: [VACM]
  P012 L014:    Control Model [VACM] is recommended.

Bert