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

"Black, David" <david.black@emc.com> Thu, 17 April 2014 21:31 UTC

Return-Path: <david.black@emc.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0441A0167; Thu, 17 Apr 2014 14:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.273
X-Spam-Level:
X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQaQqrcGVipN; Thu, 17 Apr 2014 14:31:49 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9F1A0133; Thu, 17 Apr 2014 14:31:48 -0700 (PDT)
Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3HLVfcP030891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2014 17:31:41 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s3HLVfcP030891
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1397770302; bh=g4RSLBFR0A8YAd4iJhfH78ibJFY=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=VSrAbX62azadSl/bgkEfACJ7xVeub5vI5M3Ugi92nd2h0sePVXA1gcelbhYer755Y kGc+z2mIUaO89oz5n3fqp6XiiX3FVyfT+efO8QP61R4dQMYSTccSSTLINc3pZHDJCE 2TSVbGebcEpHqbGjy7lr6NENVl/WPQ/WEKGzM75U=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s3HLVfcP030891
Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd54.lss.emc.com (RSA Interceptor); Thu, 17 Apr 2014 17:31:25 -0400
Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3HLVPUI006105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 17:31:25 -0400
Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Thu, 17 Apr 2014 17:31:25 -0400
From: "Black, David" <david.black@emc.com>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>, "tnadeau@lucidvision.com" <tnadeau@lucidvision.com>, "Zafar Ali (zali)" <zali@cisco.com>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>
Date: Thu, 17 Apr 2014 17:31:23 -0400
Subject: RE: Gen-ART review of draft-ietf-bfd-mib-17
Thread-Topic: Gen-ART review of draft-ietf-bfd-mib-17
Thread-Index: Ac9Zy+Zk0qHspTLsTUq2+7kL82/PpAAiJosQAAum6hA=
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C2EC413@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE712076C2EC24D@MX15A.corp.emc.com> <CECE764681BE964CBE1DFF78F3CDD3941E10B9F3@xmb-aln-x01.cisco.com>
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3941E10B9F3@xmb-aln-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/rNWfsW-CbXB5mgggKGYxgbzEb-Y
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 21:31:53 -0000

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@cisco.com]
> Sent: Thursday, April 17, 2014 5:18 PM
> To: Black, David; tnadeau@lucidvision.com; Zafar Ali (zali); General Area
> Review Team (gen-art@ietf.org)
> Cc: rtg-bfd@ietf.org; ietf@ietf.org
> 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@emc.com]
> > Sent: Wednesday, April 16, 2014 7:31 PM
> > To: tnadeau@lucidvision.com; Zafar Ali (zali); Nobo Akiya (nobo); General
> > Area Review Team (gen-art@ietf.org)
> > Cc: rtg-bfd@ietf.org; ietf@ietf.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).
> 
> 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@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
>