RE: AD review: draft-ietf-bridge-rstpmib-06.txt

Hi Bert,

My responses to your comments are inline.

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]] 
> Sent: Friday, June 10, 2005 7:56 AM
> To: '[email protected]'; 'Dan Romascanu (E-mail)'; 
> [email protected]; [email protected]
> Cc: Bridge-Mib (E-mail)
> Subject: 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. 

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

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 read-write
>   objects.

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?

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

Done.

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

Done.

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

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

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

> Further, checking citations and references 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

Removed the references

> 
> !! 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.
> 
Removed the citations. Modified the text to refer to generic
capabilities rather than specific models.


> Bert
> 
> 
> 
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) 
> > Sent: Wednesday, May 18, 2005 14:07
> > To: [email protected]
> > 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 protected]]
> > > 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 protected]
> > > 
> > > 
> > > 
> > 
>