Hi Nobo, With respect to the MIB, this concern is a nit, so I'm ok with going ahead without making this change ... ... However ... Your WG chairs and AD should be concerned that this significant flaw in BFD version 0 (justifying a "SHOULD NOT use" recommendation) is undocumented. Thanks, --David > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@xxxxxxxxx] > Sent: Monday, April 28, 2014 1:46 PM > To: Black, David; tnadeau@xxxxxxxxxxxxxxx; Zafar Ali (zali); General Area > Review Team (gen-art@xxxxxxxx) > Cc: rtg-bfd@xxxxxxxx; ietf@xxxxxxxx > Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18 > > 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 > > > ---------------------------------------------------- >