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