Hi Nobo, > > 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). > > I remember seeing the statement from IESG, which I agree is a good direction > for new charter items. [This] BFD MIB, on the other hand, is almost 10 years > old, with several implementations already around. I highly suspect the WG will > not want to see *change of direction* at this point. With that said, let me > take this up with the AD and the Shepherd. I have no problem with "running code" as a good reason to continue with writable objects in this MIB; taking this topic up with your AD and Shepherd should suffice. > > 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. > > I've gone through them. There are set of objects which really should not be > modified once a session is functioning. I've added this in the security > considerations section. Good - thank you for doing that. Everything else is fine with me, and I appreciate the prompt response. Thanks, --David > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@xxxxxxxxx] > Sent: Thursday, April 17, 2014 5:18 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-17 > > Hi David, > > Thank you for thorough review of this document. > Please see replies in-line. > > > -----Original Message----- > > From: Black, David [mailto:david.black@xxxxxxx] > > Sent: Wednesday, April 16, 2014 7:31 PM > > 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: 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). > > I remember seeing the statement from IESG, which I agree is a good direction > for new charter items. [This] BFD MIB, on the other hand, is almost 10 years > old, with several implementations already around. I highly suspect the WG will > not want to see *change of direction* at this point. With that said, let me > take this up with the AD and the Shepherd. > > > > > 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. > > Good point. I will add bfdAdminStatus and bfdOperStatus in the security > considerations section. > > > > > 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. > > I've gone through them. There are set of objects which really should not be > modified once a session is functioning. I've added this in the security > considerations section. > > o Some management objects define the BFD session whilst other > management objects define the parameter of the BFD session. It is > particularly important to control the support for SET access to > those management objects that define the BFD session, as changes > to them can be disruptive. Implementation SHOULD NOT allow > changes to following management objects when bfdSessState is > up(4): > > * bfdSessVersionNumber > * bfdSessType > * bfdSessDestinationUdpPort > * bfdSessMultipointFlag > * bfdSessInterface > * bfdSessSrcAddrType > * bfdSessSrcAddr > * bfdSessDstAddrType > * bfdSessDstAddr > > > > > Also, as a General Variable, would bfdSessNotificationsEnable be better > > named bfdNotificationsEnable, as it's not in the BFD Session Table? > > That's true. Renamed as suggested. > > > > > 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. > > Good point. If I remember correctly, BFD version 0 had a problem in the state > machine that can cause the two ends to fall into a deadlock. It would be, > therefore, very bad for anybody to have BFD version 0 deployed out there, and > asking for any MIB compliance requirement for such. Consensus on absence of > compliance requirement for BFD version 0 was never polled in the WG, but I can > say that there shouldn't be any desire for that. > > I will add a short statement on lack of BFD version 0 compliance requirement > in the introduction section, as you suggested. > > > > > 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. > > Thanks for the text. Updated in local copy. > > > > > 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 > > Agree, non-issue. > > > > > 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.) > > Agree, non-issue. > > Thanks again! > > -Nobo > > > > > 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 > > ---------------------------------------------------- >