Subject: [Gen-art] Gen-ART review of draft-ietf-bfd-mib-17

From: "Black, David" <[email-masked]>
Date: Wed, 16 Apr 2014 19:30:56 -0400

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: "Black, David" <[email-masked]>
Date: Thu, 17 Apr 2014 17:31:23 -0400

Hi Nobo,

> > This MIB contains many writable objects, so the authors should take note of
> > the IESG statement on writable MIB modules:
> >
> > 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:[email-masked]]
> Sent: Thursday, April 17, 2014 5:18 PM
> To: Black, David; [email-masked]; Zafar Ali (zali); General Area
> Review Team ([email-masked])
> Cc: [email-masked]; [email-masked]
> 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:[email-masked]]
> > Sent: Wednesday, April 16, 2014 7:31 PM
> > To: [email-masked]; Zafar Ali (zali); Nobo Akiya (nobo); 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
> >
> to
> > go read the protocol documents to understand how the protocol works, and
> 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:
> >
> > 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:
> >
> > 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
> 
> >
> 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:
> >
> 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:
> >
> Agree, non-issue.
> Agree, non-issue.
> Thanks again!
> -Nobo

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Apr 2014 22:55:18 +0100

Hi David,

Thanks for the review.

> Call, e.g., starting with Benoit Claise (AD).

The OPS Directorate and the MIB Doctors will have been alerted to this document
by the last call and we can expect their comments.

But this question was discussed between the AD and the authors, and the AD was
unlikely to agree to sponsor the document if he felt it went against the IESG
statement. Our discussion resulted in some reduction of writeable objects.

I think there are several points to consider:
1. This document had already been completed and publication requested (i.e.
shepherd write-up written) at the time of the IESG statement. It would be
unreasonable to make the statement retrospective.
2. There are already various implementations in equipment (not just management
stations) of proprietary modules approximating to this document and these
support write-access.
3. This is a low-level component protocol of the sort that is used on dumber
devices and that is an area where write-access is more common.

Cheers,
Adrian

---

From: "Black, David" <[email-masked]>
Date: Thu, 17 Apr 2014 18:06:20 -0400

Hi Adrian,

As clarified in my response to Nobo, I raised the concern about writable
MIB modules primarily as a process check (I was expecting to find something
on this topic in the shepherd writeup, and didn't).  In particular, this
concern was not intended as a strong reason not to publish, and I have no
disagreements with any of the points in your message below.

With you on top of this and the OPS folks sure to notice, I have no doubt
that this will get suitably addressed, although it might be simpler to
ensure that the OPS Area is ok now rather than waiting for IESG Evaluation.

Thanks,
--David (in part, wearing his OPS Directorate member "hat").

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Thursday, April 17, 2014 5:55 PM
> To: Black, David; [email-masked]; [email-masked]; [email-masked];
> 'General Area Review Team'

---

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

Hi David,

> level routing protocol.  The draft is reasonable for a MIB draft; one needs to
> as one would expect.  The "Brief Description of MIB Objects" is indeed brief,

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.

> unauthorized modifications, so they need to be included in the first list of

Good point. I will add bfdAdminStatus and bfdOperStatus in the security considerations section.

> or table that should be included in the security considerations section is

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.

      *  bfdSessVersionNumber
      *  bfdSessType

> 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.

Agree, non-issue.

Agree, non-issue.

Thanks again!

-Nobo

---

From: "Sam K. Aldrin" <[email-masked]>
Date: Thu, 17 Apr 2014 15:11:15 -0700

Hi Adrian,

One comment inline.

> stations) of proprietary modules approximating to this document and these

%sam - If this MIB allows write access, do you/WG anticipate, any extension to the MIB should also provide write-access as well? For example: http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments this base MIB to support MPLS. It adds more confusion than solving the issue as base MIB supports write-access, but augmented/ MIB extension doesn't. 

As the BFD MIB authors were not supportive of write-access objects in the MIBs, why to have them in the first place? 

cheers
-sam

---

From: "Sam K. Aldrin" <[email-masked]>
Date: Thu, 17 Apr 2014 15:40:15 -0700

Hi Jeff,

Comments inline.

On Apr 17, 2014, at 3:18 PM, Jeffrey Haas wrote:

> Sam,
> 
> On Thu, Apr 17, 2014 at 03:11:15PM -0700, Sam K. Aldrin wrote:
> As noted in earlier mailing list chatter, there is some support for write
> access in existing implementations.  Given the lack of significant detail
> when pressed for the name of such an implementation, I'm suspecting smaller
> vendor or internal implementation.  That's still sufficient to leave write
> available.
> 
> Given that one of the original contexts of asking if we could remove write
> was whether IETF was being asked to provide such a thing for MPLS-TP with
> related impact on your extension MIB and the answer was "no", that shouldn't
> be the main criteria.  
No. The context of my question is not related to MPLS-TP as such, but write-access support in general. 
I should have added 'clarification' in my earlier email.
> 
> My suspicion is that if we were to ship the base MIB with writeable objects,
> we may be forced to consider similar things for the extension MIB(s).
Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE and BFD-MIB respectively,  with write-access. Had to do write-access because of the reason you've mentioned above, which is base MIB. It would be painful to publish/support write-access MIB's when there is no clear interest. Hence my clarification question. 

-sam

> -- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 18 Apr 2014 01:04:47 +0000

Hi Sam,

> >> %sam - If this MIB allows write access, do you/WG anticipate, any
> extension to the MIB should also provide write-access as well? For example:
> http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments this
> base MIB to support MPLS. It adds more confusion than solving the issue as
> base MIB supports write-access, but augmented/ MIB extension doesn't.
> >>
> >> As the BFD MIB authors were not supportive of write-access objects in
> the MIBs, why to have them in the first place?
> >
> > As noted in earlier mailing list chatter, there is some support for
> > write access in existing implementations.  Given the lack of
> > significant detail when pressed for the name of such an
> > implementation, I'm suspecting smaller vendor or internal
> > implementation.  That's still sufficient to leave write available.
> >
> > Given that one of the original contexts of asking if we could remove
> > write was whether IETF was being asked to provide such a thing for
> > MPLS-TP with related impact on your extension MIB and the answer was
> > "no", that shouldn't be the main criteria.
> > My suspicion is that if we were to ship the base MIB with writeable
> > objects, we may be forced to consider similar things for the extension
> MIB(s).
> Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE and
> BFD-MIB respectively,  with write-access. Had to do write-access because of
> the reason you've mentioned above, which is base MIB. It would be painful
> to publish/support write-access MIB's when there is no clear interest. Hence
> my clarification question.

This mentions three vendors wanting to implement MIB as writable.

http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01382.html

And one more vendor voicing for writable.

http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01397.html

I agree that defining & wording writable MIB is much more painful than all read-only MIB. But above thread indicates the desire by multiple vendors to implement writable BFD MIB. Therefore it does seem that there are interests, and going forward with write-access will benefit the community. And with *ReadOnlyCompliance defined, BFD MIB can also accommodate those implementing them as just read-only.

-Nobo

---

From: "Sam K. Aldrin" <[email-masked]>
Date: Thu, 17 Apr 2014 18:24:22 -0700

Hi Nobo,
[sorry for the top post]

Yes, this is an old MIB and was in existence for a long time. 
My only concern is with the new extension MIB's. If the base MIB (this MIB) has write access, future extension MIB's may be forced to support write-access. And that is the painful part, where community at large has not shown interest in developing write-access MIB's at IETF, lest implementation. 

I want to re-iterate again, I am not objecting or proposing an alternative option. Just wanted to get clarification, so that, we don't have to burn cycles and do the exercise again, when we have to review these new extension MIB's.

-sam

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 18 Apr 2014 01:41:40 +0000

Hi Jeff,

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Thursday, April 17, 2014 6:15 PM
> To: Nobo Akiya (nobo)
> Cc: Black, David; [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-17
> 
> On Thu, Apr 17, 2014 at 09:18:28PM +0000, Nobo Akiya (nobo) wrote:
> > 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.
> 
> With respect to v0 vs. v1 from a MIB perspective, the only user-visible detail
> was the additional state in the state machine.  That means that the MIB in its
> current form should be able to accommodate bfd v0.
> 
> This does suggest, however, that the TC mib could use a comment in the
> DESCRIPTION toward the point that failing(5) is only valid for BFD v0.

Agree, and it's already there :)

[snip]
    IANAbfdSessStateTC ::= TEXTUAL-CONVENTION
    STATUS         current
    DESCRIPTION
        "BFD session state. State failing(5) is only applicable if
         corresponding session is running in BFD version 0."
[snip]

-Nobo

> 
> A conformance clause indicating that those so foolish as to deploy BFD v0
> would better be served by the determinism of a five-year-old child flipping
> a coin is probably out of scope for the draft.  But if someone has sufficiently
> proscriptive text to add to say "don't do bfd v0" that is acceptable to the
> reviewers, I'm fine with that.
> 
> -- Jeff

---

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

Hi Sam,

> From: Sam K. Aldrin [mailto:[email-masked]]
> Sent: Thursday, April 17, 2014 9:24 PM
> To: Nobo Akiya (nobo)
> Cc: Jeffrey Haas; [email-masked]; 'Black, David'; [email-masked]; rtg-
> [email-masked]; Zafar Ali (zali); 'General Area Review Team'
> My only concern is with the new extension MIB's. If the base MIB (this MIB)
> has write access, future extension MIB's may be forced to support write-
> access. And that is the painful part, where community at large has not
> shown interest in developing write-access MIB's at IETF, lest
> implementation.
> 
> I want to re-iterate again, I am not objecting or proposing an alternative
> option. Just wanted to get clarification, so that, we don't have to burn cycles
> and do the exercise again, when we have to review these new extension
> MIB's.

That's a good point, it would be good to have this clarified for future work.

IMO:

For new charters, IESG encourages NETCONF/YANG. This means S-BFD (if gets included in the charter) should look into NETCONF/YANG (i.e. not extension to the BFD base MIB).

For currently chartered BFD tasks, the BFD WG should continue with writable MIB. Large part of that is the BFD base & MPLS MIBs which [painful] writable effort is mostly done already.

-Nobo

> >> http://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ augments
> >> this base MIB to support MPLS. It adds more confusion than solving
> >> the issue as base MIB supports write-access, but augmented/ MIB
> extension doesn't.
> >>>>
> >> No. The context of my question is not related to MPLS-TP as such, but
> >> write- access support in general.
> >> Both, bfd-mpls and mpls-TP MIB's are extensions to base MIBs, MPLS-TE
> >> and BFD-MIB respectively,  with write-access. Had to do write-access
> >> because of the reason you've mentioned above, which is base MIB. It
> >> would be painful to publish/support write-access MIB's when there is
> >> no clear interest. Hence my clarification question.
> >
> > I agree that defining & wording writable MIB is much more painful than all
> read-only MIB. But above thread indicates the desire by multiple vendors to
> implement writable BFD MIB. Therefore it does seem that there are
> interests, and going forward with write-access will benefit the community.
> And with *ReadOnlyCompliance defined, BFD MIB can also accommodate
> those implementing them as just read-only.
> >
> > -Nobo
> >
> >>
> >> -sam
> >>
> >>>
> >>> -- Jeff
> >

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 17 Apr 2014 19:19:00 -0700

Thanks, Nobo. Much appreciated.

-sam

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Apr 2014 11:38:11 +0200

Hi Adrian,
> devices and that is an area where write-access is more common.
Thanks for the explanation. That makes sense to me.
This would be a useful addition to the writeup.

Regards, Benoit
> .

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Apr 2014 11:41:09 +0200

> For currently chartered BFD tasks, the BFD WG should continue with writable MIB. Large part of that is the BFD base & MPLS MIBs which [painful] writable effort is mostly done already.
This is in essence what 
https://www.ietf.org/iesg/statement/writable-mib-module.html says.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Apr 2014 14:06:44 +0200

On 18/04/2014 13:51, Thomas Nadeau wrote:
> On Apr 18, 2014:5:41 AM, at 5:41 AM, Benoit Claise <[email-masked]> wrote:
>
>> This is in essence what https://www.ietf.org/iesg/statement/writable-mib-module.html says.
>>
>> Regards, Benoit.
> 	Yes, this is why we left the writable stuff in - and why I recently spent about 4 hours doing Adrian's edits around support of such things.  Lets please put the discussion around read-write to bed for these two modules as they clearly were well under way and complete by the time the statement came out.
No disagreement.

Regards, B.
> 	--Tom

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 17 Apr 2014 18:15:11 -0400

> 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 v…

With respect to v0 vs. v1 from a MIB perspective, the only user-visible
detail was the additional state in the state machine.  That means that the
MIB in its current form should be able to accommodate bfd v0.

A conformance clause indicating that those so foolish as to deploy BFD v0
would better be served by the determinism of a five-year-old child flipping
a coin is probably out of scope for the draft.  But if someone has
sufficiently proscriptive text to add to say "don't do bfd v0" that is
acceptable to the reviewers, I'm fine with that.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 17 Apr 2014 18:18:50 -0400

Sam,

-- Jeff

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 18 Apr 2014 07:51:11 -0400

--Tom