Re: [secdir] secdir review of draft-ietf-rtgwg-backoff-algo-07

Benjamin Kaduk <kaduk@mit.edu> Fri, 16 February 2018 18:26 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6F1129515; Fri, 16 Feb 2018 10:26:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 Q6YIIe_1w3yY; Fri, 16 Feb 2018 10:26:28 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B6512D778; Fri, 16 Feb 2018 10:26:27 -0800 (PST)
X-AuditID: 1209190f-4b9ff70000000258-48-5a872252cc9f
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 00.27.00600.252278A5; Fri, 16 Feb 2018 13:26:26 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w1GIQPsl030298; Fri, 16 Feb 2018 13:26:25 -0500
Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1GIQKw6019781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Feb 2018 13:26:23 -0500
Date: Fri, 16 Feb 2018 12:26:21 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: bruno.decraene@orange.com
Cc: "draft-ietf-rtgwg-backoff-algo.all@ietf.org" <draft-ietf-rtgwg-backoff-algo.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>
Message-ID: <20180216182620.GA12363@mit.edu>
References: <20180214211017.GI12363@mit.edu> <9677_1518711435_5A85B28A_9677_280_1_53C29892C857584299CBF5D05346208A4799B57B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <EDE93099-A028-4A97-9ECB-49983E2B7A9D@cisco.com> <20180216000410.GP12363@mit.edu> <23454_1518784454_5A86CFC6_23454_358_1_53C29892C857584299CBF5D05346208A4799CED8@OPEXCLILM21.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <23454_1518784454_5A86CFC6_23454_358_1_53C29892C857584299CBF5D05346208A4799CED8@OPEXCLILM21.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixCmqrBuk1B5lsPuwvsXkt/OYLX7smMNs cX37DTaLGX8mMlt8WPiQxYHVY8rvjaweS5b8ZPJoeXaSLYA5issmJTUnsyy1SN8ugSuj78RP xoLpAhUn1zxlbmDs4+li5OSQEDCR6Pv0hr2LkYtDSGAxk8SEY00sEM5GRokfL89BZc4ySdz9 PI0dpIVFQFVi5fl2NhCbTUBFoqH7MjOILSIgK/HnaCMjSAOzwB1Gib2n3zCBJIQF7CT23rjB CGLzCuhIrHn+DWrqHyaJJdf/sEAkBCVOznwCZjMLqEv8mXcJaCoHkC0tsfwfB0RYXqJ562xm kF5OgQ5GibMrl4ItEBVQltjbd4h9AqPgLCSjZiEZNQth1CwkoxYwsqxilE3JrdLNTczMKU5N 1i1OTszLSy3SNdHLzSzRS00p3cQIjgJJ/h2Mcxq8DzEKcDAq8fA+eNwWJcSaWFZcmXuIUZKD SUmUd9FDoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3ucg5bwpiZVVqUX5MClpDhYlcV53E+0o IYH0xJLU7NTUgtQimKwMB4eSBG+OYnuUkGBRanpqRVpmTglCmomDE2Q4D9BwdpAa3uKCxNzi zHSI/ClGXY4bL163MQux5OXnpUqJ884FKRIAKcoozYObA0peEtn7a14xigO9JczbBFLFA0x8 cJNeAS1hAlrCq9QKsqQkESEl1cDoL/Jz3r8pUb93pt9Y87BZZ7LUE2uZ1GM3Fb/0VVfcqotg E+qMnJi3W3Hl7mkehrINNYtN1UseLJ4tNPtwwqKtRQtLdc/EZees+SPsJytyRMHyoNNXm52Z KdyMufd62XI3TJbtbIg5ZrU5w4XtovbR7BMdKibTHZiXL1vs6rp8FVPwLi325OVKLMUZiYZa zEXFiQA8pirbOQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/x9QCq2kZTmcP0_ZFeZrv_rs5Mmw>
Subject: Re: [secdir] secdir review of draft-ietf-rtgwg-backoff-algo-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Feb 2018 18:26:31 -0000

[inline, trimming a bunch of agreed-upon stuff]

On Fri, Feb 16, 2018 at 12:34:13PM +0000, bruno.decraene@orange.com wrote:
> Hi Benjamin,
> 
> > From: Benjamin Kaduk [mailto:kaduk@mit.edu]
>  > Sent: Friday, February 16, 2018 1:04 AM
> > 
>  > [also inline]
> 
> Please see inline [Bruno2]
>  
>  > On Thu, Feb 15, 2018 at 07:50:34PM +0000, Acee Lindem (acee) wrote:
>  > > Hi Bruno, Benjamin,
>  > >
>  > > Thanks to Benjamin for review and Bruno for the detailed response. See my responses preceded
>  > by [Acee].
>  > >
>  > >
>  > > On 2/15/18, 11:17 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.com> wrote:
>  > >
>  > >
>  > >      > In section 3, we talk of "computation of the routing table, by the
>  > >      > IGP", which gets me confused about whether "the IGP" represents a
>  > >      > network protocol for conveying (e.g.) link state information, an
>  > >      > algorithm for SPF computation, or a router that performs SPF
>  > >      > computations.
>  > >
>  > >     [Bruno] IGP is usually a protocol. In this sentence, it is meant as the IGP process of the router.
>  > >     Again, I'm open to reformulation. "Acee, any opinion on this?"
>  > >
>  > > [Acee] I don't think we need to change this. IGP is a well-known acronym.
>  > >              https://www.rfc-editor.org/materials/abbrev.expansion.txt
>  > 
>  > Perhaps my question was not well phrased.  I propose
>  > 
>  > OLD: computation of the routing table, by the IGP
>  > 
>  > NEW: computation of the routing table, by the IGP participant
>  > 
>  > (or something similar), since the IGP just serves to distribute the
>  > LSDB (conceptually), and the computation of the routing table is
>  > done by each router internally (i.e., not directly using the IGP in
>  > question).  Or is the previous sentence not true?
>  
> [Bruno2] What about:
> NEW:  Computation of the routing table, by the IGP implementation,
> 
> ("IGP participant" does not sound like an usual term to me)

That works for me.  Thanks again!

-Ben