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(_dot_)com; zali(_at_)cisco(_dot_)com; 
nobo(_at_)cisco(_dot_)com; General Area
Review Team (gen-art(_at_)ietf(_dot_)org)
Cc: rtg-bfd(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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(_dot_)com; zali(_at_)cisco(_dot_)com; 
nobo(_at_)cisco(_dot_)com; General Area
Review Team (gen-art(_at_)ietf(_dot_)org)
Cc: rtg-bfd(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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(_dot_)black(_at_)emc(_dot_)com        Mobile: +1 (978) 394-7754
----------------------------------------------------