[Gen-art] Gen-ART review of draft-ietf-bfd-mib-20

["Black, David" <[e-mail]>]

And the -20 version is also ready.  Thanks, --David

> -----Original Message-----
> From: Black, David
> Sent: Thursday, May 08, 2014 7:27 PM
> To: [e-mail]; [e-mail]; [e-mail]; General Area
> Review Team ([e-mail])
> Cc: [e-mail]; [e-mail]; Black, David
> Subject: Gen-ART review of draft-ietf-bfd-mib-19
> 
> Additional text has been added to the -19 version to address this remaining
> topic.  The -19 version is Ready.
> 
> Thanks,
> --David
> 
> 
> > -----Original Message-----
> > From: Black, David
> > Sent: Monday, April 28, 2014 10:20 AM
> > To: [e-mail]; [e-mail]; [e-mail]; General Area
> > Review Team ([e-mail])
> > Cc: [e-mail]; [e-mail]; Black, David
> > Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18
> >
> > The -18 version of this draft responds to all of the comments in the
> > Gen-ART review of -17, including the request for coordination w/the
> > OPS area, although I wasn't exactly expecting that to occur on the
> > main IETF list.
> >
> > The -18 version is ready with one small nit - The following text has
> > been added to the introduction:
> >
> >    This memo does not define a compliance requirement for a system that
> >    only implements BFD version 0. This is a reflection of a considered
> >    and deliberate decision by the BFD WG.
> >
> > An explanation of the rationale for that decision would help - I suggest
> > adding the following text and a suitable reference to the end of the text
> > above:
> >
> >    because the BFD version 0 protocol may deadlock and hence SHOULD NOT
> >    be used, as explained further in [RFCxxxx].
> >
> > Thanks,
> > --David
> >
> > > -----Original Message-----
> > > From: Black, David
> > > Sent: Wednesday, April 16, 2014 7:31 PM
> > > To: [e-mail]; [e-mail]; [e-mail]; General Area
> > > Review Team ([e-mail])
> > > Cc: [e-mail]; [e-mail]; Black, David
> > > Subject: Gen-ART review of draft-ietf-bfd-mib-17
> > >
> > > I am the assigned Gen-ART reviewer for this draft. For background on
> > > Gen-ART, please see the FAQ at
> > >
> > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> > >
> > > Please resolve these comments along with any other Last Call comments
> > > you may receive.
> > >
> > > Document: draft-ietf-bfd-mib-17
> > > Reviewer: David L. Black
> > > Review Date: April 16, 2014
> > > IETF LC End Date: April 28, 2014
> > >
> > > Summary: This draft is on the right track, but has open issues
> > > 		described in the review.
> > >
> > > This draft is a MIB module for the BFD protocol, which is an important
> low-
> > > level routing protocol.  The draft is reasonable for a MIB draft; one
> needs
> > > to go read the protocol documents to understand how the protocol works,
> and
> > > significant portions of the text are derived from the usual MIB
> > "boilerplate"
> > > as one would expect.  The "Brief Description of MIB Objects" is indeed
> > > brief, but reasonable.  The shepherd writeup indicates that there are
> > > multiple implementations.
> > >
> > > Major issues:
> > >
> > > This MIB contains many writable objects, so the authors should
> > > take note of the IESG statement on writable MIB modules:
> > >
> > > 	http://www.ietf.org/iesg/statement/writable-mib-module.html
> > >
> > > I did not see this mentioned in the shepherd writeup.  If the OPS Area
> > > has not been consulted, I strongly suggest doing so during IETF Last
> > > Call, e.g., starting with Benoit Claise (AD).
> > >
> > > Minor issues:
> > >
> > > The security considerations section includes considerations for
> > > unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus,
> > > but omits the corresponding considerations for bfdAdminStatus and
> > > bfdSessNotificationsEnable.  Both of the latter objects are global,
> > > so significant damage can be inflicted via these objects with a
> > > small number of unauthorized modifications, so they need to be
> > > included in the first list of sensitive objects.
> > >
> > > I suggest that the authors recheck the entire MIB to ensure that
> > > every object or table that should be included in the security
> > > considerations section is appropriately included.
> > >
> > > Also, as a General Variable, would bfdSessNotificationsEnable be better
> > > named bfdNotificationsEnable, as it's not in the BFD Session Table?
> > >
> > > I did not see a compliance requirement for a system that only
> > > implements BFD protocol version 0.  That absence should at least be
> > > mentioned somewhere.  For example, if this reflects a considered and
> > > deliberate decision by the WG, that should be mentioned in the
> > > introduction.
> > >
> > > Nits/editorial comments:
> > >
> > > In the security considerations for authentication-related objects:
> > >
> > > OLD
> > >    In order for these sensitive information
> > >    from being improperly accessed, implementers MAY wish to disallow
> > >    access to these objects.
> > > NEW
> > >    In order to prevent this sensitive information
> > >    from being improperly accessed, implementers MAY disallow
> > >    access to these objects.
> > >
> > > idnits 2.13.01 found a truly minor nit that should be corrected when
> > > the draft is next revised:
> > >
> > >   == Outdated reference: A later version (-05) exists of
> > >      draft-ietf-bfd-tc-mib-04
> > >
> > > it also generated a warning that probably does not reflect an actual
> > problem:
> > >
> > >   -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
> > >      have content which was first submitted before 10 November 2008.  If
> you
> > >      have contacted all the original authors and they are all willing to
> > grant
> > >      the BCP78 rights to the IETF Trust, then this is fine, and you can
> > ignore
> > >      this comment.  If not, you may need to add the pre-RFC5378
> disclaimer.
> > >      (See the Legal Provisions document at
> > >      http://trustee.ietf.org/license-info for more information.)
> > >
> > > Thanks,
> > > --David
> > > ----------------------------------------------------
> > > David L. Black, Distinguished Engineer
> > > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > > [phone]             FAX: [phone]
> > > [e-mail]        Mobile: [phone]
> > > ----------------------------------------------------