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

From: "Black, David" <[email-masked]>
Date: Mon, 28 Apr 2014 10:20:23 -0400

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: [email-masked]; [email-masked]; [email-masked]; General Area
> Review Team ([email-masked])
> Cc: [email-masked]; [email-masked]; 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
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 28 Apr 2014 17:46:28 +0000

Hi David,

> From: Black, David [mailto:[email-masked]]
> Sent: Monday, April 28, 2014 10:20 AM
> To: [email-masked]; Zafar Ali (zali); Nobo Akiya (nobo); General
> Area Review Team ([email-masked])
> 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:
> 

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

> > To: [email-masked]; [email-masked]; [email-masked]; General
> > Area Review Team ([email-masked])
> > 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"
> > This MIB contains many writable objects, so the authors should take
> > note of the IESG statement on writable MIB modules:
> >
> > 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?
> >
> > David L. Black, Distinguished Engineer EMC Corporation, 176 South St.,
> > Hopkinton, MA  01748

---

From: "Black, David" <[email-masked]>
Date: Tue, 29 Apr 2014 02:00:05 -0400

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

> From: Nobo Akiya (nobo) [mailto:[email-masked]]
> Sent: Monday, April 28, 2014 1:46 PM
> To: Black, David; [email-masked]; Zafar Ali (zali); General Area
> Cc: [email-masked]; [email-masked]
> 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
> >

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 Apr 2014 10:58:24 -0400

> BFD version 0 (justifying a "SHOULD NOT use" recommendation) is undocumented.

And also un-RFCed.

It was a "work in progress" that never fully saw the light of full
deployment.  Vendors very quickly moved to version 1 which fixed a critical
issue in the state machine.  If any version 0 survives, it's historical and
likely to be a source of operational agony rather than a useful feature.

-- Jeff

---

From: "Black, David" <[email-masked]>
Date: Tue, 29 Apr 2014 11:37:39 -0400

Jeff - could you work w/Nobo to get the word "historical" included in
the MIB draft as a characterization of BFD version 0 ?  For example,
the following text could be added to the introduction:

   because the BFD version 0 protocol is primarily of historical interest
   by comparison to the widespread deployment of the BFD version 1 protocol.

Thanks,
--David

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2014 10:58 AM
> To: Black, David
> Cc: Nobo Akiya (nobo); [email-masked]; Zafar Ali (zali); General Area
> Review Team ([email-masked]); [email-masked]; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-bfd-mib-18
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 29 Apr 2014 19:06:46 +0000

Hi David,

BFD-MIB-19 with suggested text has just been published.

URL:            http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-19.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-bfd-mib/
Htmlized:       http://tools.ietf.org/html/draft-ietf-bfd-mib-19
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-mib-19

Thanks again!

-Nobo

> Sent: Tuesday, April 29, 2014 11:38 AM
> To: Jeffrey Haas
> Cc: Nobo Akiya (nobo); [email-masked]; Zafar Ali (zali); General
> Area Review Team ([email-masked]); [email-masked]; [email-masked]; Black,
> David
> Jeff - could you work w/Nobo to get the word "historical" included in the
> MIB draft as a characterization of BFD version 0 ?  For example, the following
> text could be added to the introduction:
> 
> > Cc: Nobo Akiya (nobo); [email-masked]; Zafar Ali (zali);
> > General Area Review Team ([email-masked]); [email-masked];
> > [email-masked]
> > > 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.
> >
> > And also un-RFCed.
> >
> > deployment.  Vendors very quickly moved to version 1 which fixed a
> > critical issue in the state machine.  If any version 0 survives, it's
> > historical and likely to be a source of operational agony rather than a
> useful feature.
> >
> > -- Jeff