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

"Susan Hares" <shares@ndzh.com> Thu, 19 February 2015 00:28 UTC

Return-Path: <shares@ndzh.com>
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 7144D1A1B0D; Wed, 18 Feb 2015 16:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.055
X-Spam-Level:
X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=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 DThxxg1D13Fw; Wed, 18 Feb 2015 16:28:07 -0800 (PST)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D40D1A1AB5; Wed, 18 Feb 2015 16:28:07 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92;
From: Susan Hares <shares@ndzh.com>
To: 'Alissa Cooper' <alissa@cooperw.in>
References: <20150218203713.23448.83978.idtracker@ietfa.amsl.com> <022301d04bc5$1ca2b490$55e81db0$@ndzh.com> <1A9C702F-353D-429B-B806-5810F3C40806@cooperw.in>
In-Reply-To: <1A9C702F-353D-429B-B806-5810F3C40806@cooperw.in>
Date: Wed, 18 Feb 2015 19:28:03 -0500
Message-ID: <02c001d04bda$ed0eaca0$c72c05e0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQJVefqstoO5why0GAzXAZ7/XyJMhwD+ZS6CAgLsCOeb1LRMAA==
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/0D9pLJMXAEI8eBYfe-4VsupRrkE>
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: Thu, 19 Feb 2015 00:28:09 -0000

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.  

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?

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