Re: [Idr] Alissa Cooper's No Objection on draft-ietf-idr-as-migration-03: (with COMMENT)

Alissa Cooper <alissa@cooperw.in> Fri, 20 February 2015 01:54 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF8B1A1B40 for <idr@ietfa.amsl.com>; Thu, 19 Feb 2015 17:54:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 eYVqWSCHPvd1 for <idr@ietfa.amsl.com>; Thu, 19 Feb 2015 17:54:34 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D88B1A1B23 for <idr@ietf.org>; Thu, 19 Feb 2015 17:54:34 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 023F120D0C for <idr@ietf.org>; Thu, 19 Feb 2015 20:54:32 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 19 Feb 2015 20:54:33 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=3DI90FaM9lsqCmTIbGgqNIGyC58=; b=3C7ObTWY2EVMeaEWfcVB3 AtMcP3Arf4re9lkSu/5Pmvl4wMnPnVaM2uYO0HCzT+IwHr0J328po64IVuQcMthp cPq7Bvuuabg9hHCJ61yOKexlrZ/EsLYB3cZdyWSL9diaT/DhGpZesn/3NriQqvsO S5g0OtN1r6DJmQ8bXLqWRw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=3DI90FaM9lsqCmTIbGgqNIG yC58=; b=B8BqjB6o9M+46gAkgGAQXp+O9zVUhSw9slByw6KGVX9wrFboICeMRhO qXO6xJlLvQvTKqfqjBzEFKSOFVhwHiKwmqXglABSATNhRvwo49iKvaZVUVRVQcZM tDhN/na1gMB59W7ZGTreN/FAtMEnCvEHeFndTs2cjJKuc53SEPog=
X-Sasl-enc: 2Fw90yIeGj/2QJynh4/L1CWz5Z+ql5Pxb062/0mjM2L0 1424397273
Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id 93857C00297; Thu, 19 Feb 2015 20:54:31 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <02c001d04bda$ed0eaca0$c72c05e0$@ndzh.com>
Date: Thu, 19 Feb 2015 17:54:29 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <90956FE2-34D9-4F8F-AD30-C873D505AE30@cooperw.in>
References: <20150218203713.23448.83978.idtracker@ietfa.amsl.com> <022301d04bc5$1ca2b490$55e81db0$@ndzh.com> <1A9C702F-353D-429B-B806-5810F3C40806@cooperw.in> <02c001d04bda$ed0eaca0$c72c05e0$@ndzh.com>
To: Susan Hares <shares@ndzh.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/AWCvZs2O84JF9G_GP2mH15QTcpU>
Cc: morrowc@ops-netman.net, idr@ietf.org, IESG <iesg@ietf.org>, idr-chairs@ietf.org, draft-ietf-idr-as-migration.all@ietf.org
Subject: Re: [Idr] Alissa Cooper's No Objection on draft-ietf-idr-as-migration-03: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2015 01:54:37 -0000

On Feb 18, 2015, at 4:28 PM, Susan Hares <shares@ndzh.com> wrote:

> Alissa:
> 
> OK - I can work with Wes to restate the text in a better way in section 9.
> Alia had some comments about the technical nature to beef up that section.  

Thanks.

> 
> On, section 1  was it this set of sentences that caused you to be concerned?
> 
> 
> In addition, it is common practice in the industry
>   for ISPs to bill customers based on utilization.  ISPs bill customers
>   based on the 95th percentile of the greater of the traffic sent or
>   received, over the course of a 1-month period, on the customer's
>   access circuit.  Given that the BGP Path Selection algorithm selects
>   routes with the shortest AS_PATH attribute, it is critical that the
>   ISP does not increase AS_PATH length during or after ASN migration
>   toward downstream transit customers or settlement-free peers, who are
>   likely sending or receiving traffic from those transit customers.
>   This would not only result in sudden changes in traffic patterns in
>   the network, but also substantially decrease utilization driven
>   revenue at the ISP.
> 
> If so, can you unpack more details on what concerned you?

I think Randy’s comment sort of summed up my feeling on this. Of course there are business realities, but the RFC series doesn’t exist to document them, to the benefit of Internet engineering (IMO).

In any event, I said I was able to hold my nose about this bit in Sec 1 and I meant it, so it’s up to your discretion as to whether you want to make changes here.

Alissa

> 
> Sue 
> 
> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alissa Cooper
> Sent: Wednesday, February 18, 2015 5:50 PM
> To: Susan Hares
> Cc: morrowc@ops-netman.net; idr@ietf.org; IESG;
> draft-ietf-idr-as-migration.all@ietf.org; idr-chairs@ietf.org
> Subject: Re: [Idr] Alissa Cooper's No Objection on
> draft-ietf-idr-as-migration-03: (with COMMENT)
> 
> On Feb 18, 2015, at 1:51 PM, Susan Hares <shares@ndzh.com> wrote:
> 
>> Alissa: 
>> 
>> Could you unpack your concerns a bit more on section 1 and this section?
> Why is this not just a pragmatic comment on a reality of business that can
> happen?  This specification is documenting what exists in real networks with
> real costs. 
>> 
>> What causes you to hold your nose?  
> 
> Sure. If anything that causes any entity to lose (or gain) revenue can be
> considered a security issue, we would likely end up doing a lot of strange
> things in protocol design in the name of "security." Furthermore, one
> entity's loss can often be another's gain, where neither entity would be
> considered an attacker in the sense of perpetrating an attack a la RFC 4949.
> So I think it makes a lot more sense to focus security considerations on
> technical threats and mitigations and not consider any particular party's
> potential loss of revenue in and of itself as a security threat. 
> 
> Alissa
> 
>> 
>> Sue 
>> 
>> --------
>> 
>> The text: below: 
>> 
>> "This could result in a loss of revenue if the ISP is billing based on
> measured utilization
>>  of traffic sent to/from entities attached to its network."
>> 
>> Considering loss of revenue in and of itself to be a security issue is a
> slippery slope that we should probably not start to descend. I held my nose
> for the revenue-related text in Section 1, but here in Section 9 it seems
> particularly ill-advised.
>> ========
>> Why is this not just a comment on a reality of business that can happen?
> What causes you to hold your nose? 
>> 
>> 
>> These  
>> 
>> -----Original Message-----
>> From: Alissa Cooper [mailto:alissa@cooperw.in] 
>> Sent: Wednesday, February 18, 2015 3:37 PM
>> To: The IESG
>> Cc: morrowc@ops-netman.net; idr@ietf.org; idr-chairs@ietf.org;
> draft-ietf-idr-as-migration.all@ietf.org
>> Subject: Alissa Cooper's No Objection on draft-ietf-idr-as-migration-03:
> (with COMMENT)
>> 
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-idr-as-migration-03: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>> 
>> 
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Section 9:
>> "This could result in a
>>  loss of revenue if the ISP is billing based on measured utilization
>>  of traffic sent to/from entities attached to its network."
>> 
>> Considering loss of revenue in and of itself to be a security issue is a
> slippery slope that we should probably not start to descend. I held my nose
> for the revenue-related text in Section 1, but here in Section 9 it seems
> particularly ill-advised.
>> 
>> 
>> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>