ietf
[Top] [All Lists]

RE: Gen-ART review of draft-ietf-bfd-mib-18

2014-04-29 01:01:09
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(_at_)cisco(_dot_)com]
Sent: Monday, April 28, 2014 1:46 PM
To: Black, David; tnadeau(_at_)lucidvision(_dot_)com; Zafar Ali (zali); 
General Area
Review Team (gen-art(_at_)ietf(_dot_)org)
Cc: rtg-bfd(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: Gen-ART review of draft-ietf-bfd-mib-18

Hi David,

-----Original Message-----
From: Black, David [mailto:david(_dot_)black(_at_)emc(_dot_)com]
Sent: Monday, April 28, 2014 10:20 AM
To: tnadeau(_at_)lucidvision(_dot_)com; Zafar Ali (zali); Nobo Akiya 
(nobo); 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.

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



<Prev in Thread] Current Thread [Next in Thread>