Subject: [Bridge-mib] AD review: draft-ietf-bridge-rstpmib-06.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 10 Jun 2005 13:55:48 +0200

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
  
  <rfc ipr="full3978"
       docName="<your-doc-name>"
       category="std" >

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

> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: Wednesday, May 18, 2005 14:07
> To: [email-masked]
> Cc: 'Dan Romascanu (E-mail)'
> Subject: RE: RSTP-MIB
> 
> 
> My backlog is still pretty big.
> I need to do a quick AD-review/check first and then we need to do
> IETF Last Call. Let me try to do so in the next week.
> 
> Bert
> 
> > -----Original Message-----
> > From: David B Harrington [mailto:[email-masked]]
> > Sent: Tuesday, May 17, 2005 18:35
> > To: 'Wijnen, Bert (Bert)'
> > Cc: 'Dan Romascanu (E-mail)'
> > Subject: RSTP-MIB
> > 
> > 
> > Hi Bert,
> > 
> > I submitted draft-ietf-bridge-rstpmib.txt for advancement in the
> > beginning of April. When do you expect that will make it 
> onto the IESG
> > agenda?
> > 
> > Hopefully, I will submit draft-ietf-bridge-ext-v2.txt later 
> this week
> > as well.
> > 
> > David Harrington
> > [email-masked]
> > 
> > 
> > 
> 

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 15 Jun 2005 10:50:53 -0400

Hi Bert,

My responses to your comments are inline.

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Friday, June 10, 2005 7:56 AM
> To: [email-masked]'; 'Dan Romascanu (E-mail)'; 
> [email-masked]; [email-masked]
> Cc: Bridge-Mib (E-mail)
> Subject: AD review: draft-ietf-bridge-rstpmib-06.txt
> 
> Serious issues:
> 
> - SMICng tells me:
> 

Whoops. Fixed.

>   next available number according to RFC1493. But how will we 

Would you like them registered with IANA, including a note that all
subsequent dot1dStp values are reserved?
As we transition to IEEE updates, will they be allowed to extend
dot1dStp or do they need to use a different ieee8021 subtree
registration? Would that be problematic?

> - I see not text that indicates the persistency behaviour of 

The IEEE standard does not discuss the persistency of the management
variables. As long as the IEEE standard remains silent on this point,
I think the corresponding IETF standard should also remain silent. 

The IEEE standard should be updated to discuss persistency of each
management variable. The coresponding MIB objects should be updated to
correspond, following SMI rules, as part of the IEEE standard update.

Is there a way to clarify the persistence requirement for each object
in the IETF bridge mibs once the IEEE updates their compliance
requirements that would not require obsoleting and redefining each MIB
object? 

WG - any comments on how to approach this?

>   Maybe add some explanation?

Done.

>   things like TRUE(1) and FALSE(2). WOuld probably be better to

Done.

>   Might be good to explain that if it is indeed the case.
Done.

>   Enrty DESCRIPTION clause.
The IEEE standard does not discuss the persistency of the management
variables. As long as the IEEE standard remains silent on this point,
I think the corresponding IETF standard should also remain silent.

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

> Further, checking citations and references I find:
> 

Removed the references

>   P012 L014:    Control Model [VACM] is recommended.
Removed the citations. Modified the text to refer to generic
capabilities rather than specific models.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 15 Jun 2005 12:50:10 -0700

Hi -

> From: "David B Harrington" <[email-masked]>
...
> Sent: Wednesday, June 15, 2005 7:50 AM
> Subject: [Bridge-mib] RE: AD review: draft-ietf-bridge-rstpmib-06.txt
...
> WG - any comments on how to approach this?
...

Rather than being silent, if the IEEE is unable to provide clarification of
what the persistency expectations are, we should include text to the
effect that "management applications MUST NOT assume that these
MIB objects are backed by non-volatile memory of some kind, and
furthermore MUST NOT assume that these MIB objects will not
persist across a re-boot or loss of power."

Anything less is asking for non-interoperability.

Randy