RE: Gen-ART review of draft-ietf-bfd-mib-18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

> -----Original Message-----
> From: Black, David [mailto:david.black@xxxxxxx]
> Sent: Monday, April 28, 2014 10:20 AM
> To: tnadeau@xxxxxxxxxxxxxxx; Zafar Ali (zali); Nobo Akiya (nobo); General
> Area Review Team (gen-art@xxxxxxxx)
> Cc: rtg-bfd@xxxxxxxx; ietf@xxxxxxxx; 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.

Thanks, they were very good comments.

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

Unfortunately the problem with BFD version 0 is not documented in any RFCs, and MIB is probably not the right place to start this documentation either. If this should be documented in a RFC, possibly a new info document or raise errata on RFC5880 ... I'm not sure what would be a reasonable/recommended path here. In any case, my vote for the MIB document(s) is to keep the current text to proceed. Would that be ok with you?

-Nobo

> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Black, David
> > Sent: Wednesday, April 16, 2014 7:31 PM
> > To: tnadeau@xxxxxxxxxxxxxxx; zali@xxxxxxxxx; nobo@xxxxxxxxx; General
> > Area Review Team (gen-art@xxxxxxxx)
> > Cc: rtg-bfd@xxxxxxxx; ietf@xxxxxxxx; 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
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > david.black@xxxxxxx        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]