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: tnadeau@xxxxxxxxxxxxxxx; zali@xxxxxxxxx; nobo@xxxxxxxxx; 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. > > 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: 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 > > ----------------------------------------------------