And the -20 version is also ready. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Thursday, May 08, 2014 7:27 PM > To: tnadeau at lucidvision.com; zali at cisco.com; nobo at cisco.com; General Area > Review Team (gen-art at ietf.org) > Cc: rtg-bfd at ietf.org; ietf at ietf.org; 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: tnadeau at lucidvision.com; zali at cisco.com; nobo at cisco.com; General Area > > Review Team (gen-art at ietf.org) > > Cc: rtg-bfd at ietf.org; ietf at ietf.org; 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 at lucidvision.com; zali at cisco.com; nobo at cisco.com; General Area > > > Review Team (gen-art at ietf.org) > > > Cc: rtg-bfd at ietf.org; ietf at ietf.org; 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 at emc.com        Mobile: +1 (978) 394-7754 > > > ----------------------------------------------------