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

["Wijnen, Bert (Bert)" <[e-mail]>]

Inline, I received the new draft that you did send to list (rev 8)
and did check it. looks good

Further comments/answers inline

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]On
> Behalf Of David B Harrington
> Sent: Wednesday, June 15, 2005 16:51
> To: 'Wijnen, Bert (Bert)'; 'Dan Romascanu (E-mail)'; 'David Levi'
> Cc: 'David Kessens'; 'Bridge-Mib (E-mail)'
> Subject: [Bridge-mib] 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:[e-mail]] 
> > Sent: Friday, June 10, 2005 7:56 AM
> > To: '[e-mail]'; 'Dan Romascanu (E-mail)'; 
> > [e-mail]; [e-mail]
> > 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.
> 
thanks

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

Well, that is what we did for RMON, i.e. registrations under: rmon
I think it migh tbe usefull to document them some place and
keep a registry.  

> 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 think that we still need to decide on what to do with the OID trees
when we transfer to IEEE. If they do their documents, and make them
publicly available and if we can check the MIB before it gets 
published, then maybe we can keep the OIDs as they currently are and
let IEEE do extensions. But it is clear that in that case we (IETF)
would want to have sign-off authority before such OID branches
get assigned by IANA. If we do that, then that maybe one more
reason to write a doc similar to RFC3737 for an IANA conrolled
and administered bridgemib OID registry. Not sure if that would be
acceptable to IEEE 802. 

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

So I understand that clarifying text was added that now in fact states
that they MUST be retained across re-init, except for:

  dot1dStpPortProtocolMigration

Was that an oversight?


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

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

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

> >   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.
> 
I see you added MUST language. That works for me

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

No nits found for rev 8. Thanks

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

Reference check is now OK

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

Thanks
> 
> > Bert
> > 

Bert

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