From sob@harvard.edu Tue Aug 2 07:55:55 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410E621F874B for ; Tue, 2 Aug 2011 07:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mixshE8RD56V for ; Tue, 2 Aug 2011 07:55:54 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id 4740D21F874E for ; Tue, 2 Aug 2011 07:55:54 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id C7987DC4344; Tue, 2 Aug 2011 10:56:02 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> Date: Tue, 2 Aug 2011 10:56:02 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 14:55:55 -0000 this starts a WGLC on draft-weil-shared-transition-space-request-03.txt comments to the list by Aug 16 please Scott --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Reserved IPv4 Prefix for Shared Transition Space Author(s) : Jason Weil Victor Kuarsingh Chris Donley Telstra Corp Marla Azinger Filename : draft-weil-shared-transition-space-request-03.txt Pages : 12 Date : 2011-08-02 This document requests a reserved IANA IPv4 address allocation as Shared Transition Space to support the deployment of IPv4 address sharing technologies post IPv4 exhaustion A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt From stan.barber2@cox.com Tue Aug 2 09:49:47 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE7A21F85B9 for ; Tue, 2 Aug 2011 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RprnHaZc542V for ; Tue, 2 Aug 2011 09:49:47 -0700 (PDT) Received: from post4.cox.com (post4.cox.com [24.248.72.37]) by ietfa.amsl.com (Postfix) with ESMTP id E072321F85B2 for ; Tue, 2 Aug 2011 09:49:46 -0700 (PDT) Received: from ([192.168.72.254]) by post4.cox.com with ESMTP with TLS id 5503597.374818034; Tue, 02 Aug 2011 12:49:52 -0400 Received: from CATL0MS112.corp.cox.com ([169.254.1.36]) by CATL0MS402.corp.cox.com ([10.62.236.89]) with mapi; Tue, 2 Aug 2011 12:49:51 -0400 From: To: Date: Tue, 2 Aug 2011 12:49:51 -0400 Thread-Topic: draft-weil-shared-transition-space-request-03.txt Thread-Index: AcxRNDKbjKbDSHe+QHismkyUk8+4Wg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D4759D49578EC2458DD252B993155A2E095BC5F42FCATL0MS112cor_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 02 Aug 2011 10:04:28 -0700 Subject: [OPSAWG] draft-weil-shared-transition-space-request-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 16:55:57 -0000 --_000_D4759D49578EC2458DD252B993155A2E095BC5F42FCATL0MS112cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in support of this draft moving forward. --_000_D4759D49578EC2458DD252B993155A2E095BC5F42FCATL0MS112cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am in support of this draft moving forward.
 
 --_000_D4759D49578EC2458DD252B993155A2E095BC5F42FCATL0MS112cor_-- From jeff.finkelstein@cox.com Tue Aug 2 12:08:41 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601E91F0C47 for ; Tue, 2 Aug 2011 12:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4+8kBggqhb0 for ; Tue, 2 Aug 2011 12:08:40 -0700 (PDT) Received: from post3.cox.com (post3.cox.com [24.248.72.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8F65F1F0C39 for ; Tue, 2 Aug 2011 12:08:40 -0700 (PDT) Received: from ([192.168.72.254]) by post3.cox.com with ESMTP with TLS id 5503596.122594363; Tue, 02 Aug 2011 15:08:48 -0400 Received: from CATL0MS102.corp.cox.com ([169.254.1.114]) by CATL0MS401.corp.cox.com ([10.62.236.87]) with mapi; Tue, 2 Aug 2011 15:08:47 -0400 From: To: Date: Tue, 2 Aug 2011 15:08:45 -0400 Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxRR5r3Lr5oTXj6TpyFJtZAuDRplg== Message-ID: In-Reply-To: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:08:41 -0000 Cox Communications supports this draft and requests that the WG's and AD's allow it to proceed. On 8/2/11 10:56 AM, "Scott O. Bradner" wrote: > >this starts a WGLC on draft-weil-shared-transition-space-request-03.txt > >comments to the list by Aug 16 please > >Scott > >--- >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : IANA Reserved IPv4 Prefix for Shared Transition Space > Author(s) : Jason Weil > Victor Kuarsingh > Chris Donley > Telstra Corp > Marla Azinger > Filename : draft-weil-shared-transition-space-request-03.txt > Pages : 12 > Date : 2011-08-02 > > This document requests a reserved IANA IPv4 address allocation as > Shared Transition Space to support the deployment of IPv4 address > sharing technologies post IPv4 exhaustion > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-req >uest-03.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-requ >est-03.txt >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From brian.e.carpenter@gmail.com Tue Aug 2 15:13:03 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F07121F8563 for ; Tue, 2 Aug 2011 15:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.601 X-Spam-Level: X-Spam-Status: No, score=-103.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR03F5vvevxV for ; Tue, 2 Aug 2011 15:13:02 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D50021F8562 for ; Tue, 2 Aug 2011 15:13:02 -0700 (PDT) Received: by qwc23 with SMTP id 23so208019qwc.31 for ; Tue, 02 Aug 2011 15:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pH2dRxR6iUJbjxPPFStcZ6pb3Zm2AJEPQcQpSAwCUhQ=; b=ZX4KCI/ZUPknqMxbCiyRNIsUfq4TC8nqXwq1V+1mmlb+nUryBFX6dQ8Usx9vc6kolZ VKcXwqG3YOBbvxNhfBlRCdUBqSjkOX63X4Vrhj74B85XZAHzScvfu0VxsBHfzMh7BPIU EFJsu0grizzU3qZ2a1LVtrgsiC3/G4Gb+g8D8= Received: by 10.224.30.210 with SMTP id v18mr2551671qac.91.1312323192385; Tue, 02 Aug 2011 15:13:12 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id d12sm154364qcd.38.2011.08.02.15.13.10 (version=SSLv3 cipher=OTHER); Tue, 02 Aug 2011 15:13:11 -0700 (PDT) Message-ID: <4E387674.5000000@gmail.com> Date: Wed, 03 Aug 2011 10:13:08 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: opsawg@ietf.org References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> In-Reply-To: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:13:03 -0000 I have concluded that it is inappropriate for the IETF to endorse this hack. That isn't intended to be derogatory - there are many aspects of running code that depend on hacks. But the fact is that this is a hack, for reasons that have been discussed many times and that I won't repeat here. I know that some aspects of RFC 6269 are contested, but it does give the arguments. I've also reviewed draft-bdgks-arin-shared-transition-space in reaching this conclusion. I am not happy that ARIN is going the way it apparently is, but that is my own problem. However, I don't support draft-bdgks's call for "consensus between the IETF and RIR communities" on this issue. It isn't necessary. At the very minimum, if draft-weil is to proceed, it should describe the phase-out plan for the proposed prefix (i.e. the phase-out plan for CGN deployment). One approach to that is documented in RFC 6264. It is strange that draft-weil doesn't reference RFC 6319 and RFC 6269. Regards Brian Carpenter On 2011-08-03 02:56, Scott O. Bradner wrote: > this starts a WGLC on draft-weil-shared-transition-space-request-03.txt > > comments to the list by Aug 16 please > > Scott > > --- > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : IANA Reserved IPv4 Prefix for Shared Transition Space > Author(s) : Jason Weil > Victor Kuarsingh > Chris Donley > Telstra Corp > Marla Azinger > Filename : draft-weil-shared-transition-space-request-03.txt > Pages : 12 > Date : 2011-08-02 > > This document requests a reserved IANA IPv4 address allocation as > Shared Transition Space to support the deployment of IPv4 address > sharing technologies post IPv4 exhaustion > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From bschlies@cisco.com Tue Aug 2 17:12:13 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6554821F84ED for ; Tue, 2 Aug 2011 17:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.623 X-Spam-Level: X-Spam-Status: No, score=-3.623 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI3Cz5m9vYZu for ; Tue, 2 Aug 2011 17:12:11 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFF121F84E8 for ; Tue, 2 Aug 2011 17:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=2731; q=dns/txt; s=iport; t=1312330342; x=1313539942; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=ND1qqA9tB5FnLBl3QIQZ8oRw5Oi1GEQdZX2q/zc9aN0=; b=VWiGuU+Z/eH+zDv550Ypd9PWFt6I8wIThFon6z1ijOOPp0HDP22/IT/b A1xKN0v5jXGh2NBQfh8+TDm+iy/HCo1310QGwSaRyf4RgrdMOU7xoIDbY +kXSsIrb78UMI8IDisO429Ml0h7mft/2+yd0LNVG4Xxe5++QqMT5gJ4U0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEaROE6tJV2a/2dsb2JhbABBp1p3gUABAQEBAgESAScCAS8KCA0BCGc2AQEEARIih0qgAQGeUIZCBIdaiyGFEIRbhxc X-IronPort-AV: E=Sophos;i="4.67,307,1309737600"; d="scan'208";a="9016240" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 03 Aug 2011 00:12:16 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p730CGMq004875; Wed, 3 Aug 2011 00:12:16 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Aug 2011 19:12:16 -0500 Received: from 10.21.122.15 ([10.21.122.15]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Wed, 3 Aug 2011 00:12:16 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 02 Aug 2011 19:15:04 -0500 From: Benson Schliesser To: Brian E Carpenter , Message-ID: Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxRcmRuasbZ727lgE2OydQZlkaBPw== In-Reply-To: <4E387674.5000000@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Aug 2011 00:12:16.0568 (UTC) FILETIME=[00A29B80:01CC5172] Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:12:13 -0000 Hi, Brian. On 8/2/11 5:13 PM, "Brian E Carpenter" wrote: > I have concluded that it is inappropriate for the IETF to endorse > this hack. We're asking for an IPv4 prefix reservation, not an endorsement. But assuming that they're perceived to be one-and-the-same to some people, I'll continue. > That isn't intended to be derogatory - there are many aspects > of running code that depend on hacks. But the fact is that this is a hack, > for reasons that have been discussed many times and that I won't > repeat here. I know that some aspects of RFC 6269 are contested, but > it does give the arguments. To be clear: I think you're objecting to the use of CGN. I don't think you're objecting to the use of IPv4 and/or the reservation of IPv4 prefixes. On the basic motivation for your objection, I won't argue. I don't really like NAT, especially the CGN variety, and would rather have native IPv6. (I think I can almost hear a chorus of "amen" from the IETF devout...) But in reality, the IETF doesn't "endorse" a technology - the market does by choosing what to deploy. And CGN is already deployed, is currently being deployed, and/or is part of deployment plans at just about every ISP that I've spoken with. Most of them are focused on NAT444 for various reasons. They all need Shared Transition Space, and unless we make this reservation they will be forced to explore the "alternatives" described in draft-bdgks-arin... Shutting off IPv4 connectivity is not currently an option. > At the very minimum, if draft-weil is to proceed, it should describe the > phase-out plan for the proposed prefix (i.e. the phase-out plan for CGN > deployment). One approach to that is documented in RFC 6264. This was previously discussed amongst the authors of draft-weil and draft-bdgks, and it's not obvious per that discussion that a phase-out plan is useful. During the period of time that IPv4 connectivity is necessary, the Shared Transition Space reservation is likely to be needed. After an effective IPv6 transition, when the Shared Transition Space is no longer needed, it won't matter if it's returned to the pool because IPv4 address demand will decrease. Thus it doesn't make sense to worry about a phase-out plan. (BTW, reclamation of unused IPv4 GUA post-transition would gain more inventory, but also isn't worth the hassle.) In other words, I'm assuming that we won't encounter (or won't know) a growing IPv4 Internet with no NAT444 in use. The edge-case possibility, of 100% IPv6 clients combined with increasing IPv4 demand, seems unlikely. If you think I'm overlooking some other possibility, please clarify. Cheers, -Benson From brian.e.carpenter@gmail.com Tue Aug 2 18:39:25 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF76421F86EC for ; Tue, 2 Aug 2011 18:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.601 X-Spam-Level: X-Spam-Status: No, score=-103.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCRVotBAyZhi for ; Tue, 2 Aug 2011 18:39:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06C9821F86EA for ; Tue, 2 Aug 2011 18:39:24 -0700 (PDT) Received: by vxi40 with SMTP id 40so327866vxi.31 for ; Tue, 02 Aug 2011 18:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5vftKH0+oBpRGR92NYAOL1D71g30VAN7YlN+HcVkzps=; b=hB4+7HbWDLKewgqrvSwIcG8emA/1Yn3Oueb92X9x4rnxzztxzwi1AcVXZEG6T6qISK 4R4K+ga2bfI3tPDsRbEGYkFyGQUTa3uSfPS1934V3E0ydAjxhBF3N2PONQYOrbeUZul0 sQqYIkR0mI0dusJ8jW4uUVFWyXqznJi5+sQ/I= Received: by 10.52.174.77 with SMTP id bq13mr3844508vdc.266.1312335575205; Tue, 02 Aug 2011 18:39:35 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id jv3sm166859vdb.47.2011.08.02.18.39.32 (version=SSLv3 cipher=OTHER); Tue, 02 Aug 2011 18:39:34 -0700 (PDT) Message-ID: <4E38A6D0.7040101@gmail.com> Date: Wed, 03 Aug 2011 13:39:28 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Benson Schliesser References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 01:39:25 -0000 Benson, On 2011-08-03 12:15, Benson Schliesser wrote: > Hi, Brian. > > On 8/2/11 5:13 PM, "Brian E Carpenter" wrote: > >> I have concluded that it is inappropriate for the IETF to endorse >> this hack. > > We're asking for an IPv4 prefix reservation, not an endorsement. But > assuming that they're perceived to be one-and-the-same to some people, I'll > continue. > >> That isn't intended to be derogatory - there are many aspects >> of running code that depend on hacks. But the fact is that this is a hack, >> for reasons that have been discussed many times and that I won't >> repeat here. I know that some aspects of RFC 6269 are contested, but >> it does give the arguments. > > To be clear: I think you're objecting to the use of CGN. I don't think > you're objecting to the use of IPv4 and/or the reservation of IPv4 prefixes. Emotionally, I object to CGN, but realistically, I know it is part of the real world. That's why I'm a co-author of RFC 6264. I do object to using a significant amount of global IPv4 space for this purpose. Whoever it was that decided to make the Internet depend on NAT44 should have thought about this problem years ago and kept some of the RFC 1918 space for NAT444 usage. Failing that, I would have gone for 1.0.0.0/8 for this purpose, since it's already compromised by bogons. But that ship has sailed. So I don't think there *is* a solution for this problem that doesn't consume some global space that should have been used in a normal way. Why would the IETF want to be party to that? It's an operational issue. > On the basic motivation for your objection, I won't argue. I don't really > like NAT, especially the CGN variety, and would rather have native IPv6. (I > think I can almost hear a chorus of "amen" from the IETF devout...) > > But in reality, the IETF doesn't "endorse" a technology - the market does by > choosing what to deploy. And CGN is already deployed, is currently being > deployed, and/or is part of deployment plans at just about every ISP that > I've spoken with. Most of them are focused on NAT444 for various reasons. > They all need Shared Transition Space, and unless we make this reservation > they will be forced to explore the "alternatives" described in > draft-bdgks-arin... Shutting off IPv4 connectivity is not currently an > option. Of course not, and although there are certainly alternative approaches (see below) it's too late to avoid CGNs. > >> At the very minimum, if draft-weil is to proceed, it should describe the >> phase-out plan for the proposed prefix (i.e. the phase-out plan for CGN >> deployment). One approach to that is documented in RFC 6264. > > This was previously discussed amongst the authors of draft-weil and > draft-bdgks, and it's not obvious per that discussion that a phase-out plan > is useful. It's only by describing a phase-out plan that you can make a convincing case that this a stop-gap, in which case people might just hold their noses instead of trying to stop it. > > During the period of time that IPv4 connectivity is necessary, the Shared > Transition Space reservation is likely to be needed. After an effective IPv6 > transition, when the Shared Transition Space is no longer needed, it won't > matter if it's returned to the pool because IPv4 address demand will > decrease. Thus it doesn't make sense to worry about a phase-out plan. (BTW, > reclamation of unused IPv4 GUA post-transition would gain more inventory, > but also isn't worth the hassle.) Sure - it's not the reservation of the prefix that phases out, it's the need to use it. > > In other words, I'm assuming that we won't encounter (or won't know) a > growing IPv4 Internet with no NAT444 in use. The edge-case possibility, of > 100% IPv6 clients combined with increasing IPv4 demand, seems unlikely. If > you think I'm overlooking some other possibility, please clarify. There is a class of solutions in which there is no need for NAT44 in the CPE, and a single layer of NAT44 is provided at the ISP end of a 4-over-6 tunnel. Indeed, that is DS-Lite and it's part of process of removing NAT444 from the picture. Again, see RFC 6264. An ISP that follows that path will be able to phase out whatever IPv4 prefix(es) it uses for NAT444 "Transition Space". Regards Brian From C.Grundemann@cablelabs.com Wed Aug 3 08:45:45 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2583621F8BB8 for ; Wed, 3 Aug 2011 08:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5+V+0CIChII for ; Wed, 3 Aug 2011 08:45:44 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9C05121F8AC9 for ; Wed, 3 Aug 2011 08:45:43 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p73FjqmC027703; Wed, 3 Aug 2011 09:45:53 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 3 Aug 2011 09:45:52 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 3 Aug 2011 09:45:52 -0600 From: Chris Grundemann To: Brian E Carpenter , Benson Schliesser Date: Wed, 3 Aug 2011 09:45:51 -0600 Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxRfja1lWFy+6rTTuCNGqLN28N/9QAdHZfw Message-ID: <3C0068AB22D70B4DA32B9A2A965968C773EDF4EA07@srvxchg> References: <4E38A6D0.7040101@gmail.com> In-Reply-To: <4E38A6D0.7040101@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:45:45 -0000 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Brian E Carpenter > Sent: Tuesday, August 02, 2011 7:39 PM > It's only by describing a phase-out plan that you can make a convincing c= ase > that this a stop-gap, in which case people might just hold their noses in= stead > of trying to stop it. > Sure - it's not the reservation of the prefix that phases out, it's the n= eed to > use it. [CLG] I believe that your comments are invaluable to revising the next vers= ion of draft-bdgks and I hope that you will continue to participate in this= discussion as we do that. However, draft-weil is not meant to address the = use-cases or BCPs surrounding shared transition space, it merely requests t= he reservation. The references to a phase out plan, to RFCs 6264, 6269, 631= 9 and any others belong in draft-bdgks if they are to be included (and you = make a convincing argument that they should be). I certainly agree that the= se items need to be discussed further but I do not think they warrant holdi= ng up draft-weil and the reservation of a /10 for shared transition space (= which the ARIN community has so graciously agreed to donate to the world). Cheers, ~Chris PS - Kudos on RFC 6264, it's a great doc. From C.Donley@cablelabs.com Wed Aug 3 11:25:46 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AF121F8584 for ; Wed, 3 Aug 2011 11:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.777 X-Spam-Level: X-Spam-Status: No, score=0.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMSBseVk0RZo for ; Wed, 3 Aug 2011 11:25:45 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5F23F21F8571 for ; Wed, 3 Aug 2011 11:25:45 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p73IPsvT018634; Wed, 3 Aug 2011 12:25:54 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 3 Aug 2011 12:25:54 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 3 Aug 2011 12:25:54 -0600 From: Chris Donley To: Brian E Carpenter , Benson Schliesser Date: Wed, 3 Aug 2011 12:25:50 -0600 Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxSCsdGCDh6uQoTTz6NUBOKYJqs+g== Message-ID: In-Reply-To: <4E38A6D0.7040101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:25:46 -0000 Brian, I share your goal of moving to IPv6 as fast as possible, but we need to do something in the short term to give subscribers continued IPv4 access through the transition, and NAT444 will be the best choice for some providers in the near future (particularly since it doesn't require a router replacement like DS-Lite). Having reserved shared transition space will reduce the total number of addresses used behind the CGN (compared with direct assignments), reduce squatting, and improve operational characteristics vs. different ranges for each operator or RFC1918 space. On 8/2/11 7:39 PM, "Brian E Carpenter" wrote: >Benson, > >On 2011-08-03 12:15, Benson Schliesser wrote: >> Hi, Brian. >>=20 >> On 8/2/11 5:13 PM, "Brian E Carpenter" >>wrote: >>=20 >>> I have concluded that it is inappropriate for the IETF to endorse >>> this hack.=20 >>=20 >> We're asking for an IPv4 prefix reservation, not an endorsement. But >> assuming that they're perceived to be one-and-the-same to some people, >>I'll >> continue. >>=20 >>> That isn't intended to be derogatory - there are many aspects >>> of running code that depend on hacks. But the fact is that this is a >>>hack, >>> for reasons that have been discussed many times and that I won't >>> repeat here. I know that some aspects of RFC 6269 are contested, but >>> it does give the arguments. >>=20 >> To be clear: I think you're objecting to the use of CGN. I don't think >> you're objecting to the use of IPv4 and/or the reservation of IPv4 >>prefixes. > >Emotionally, I object to CGN, but realistically, I know it is part of the >real world. That's why I'm a co-author of RFC 6264. > >I do object to using a significant amount of global IPv4 space for this >purpose. >Whoever it was that decided to make the Internet depend on NAT44 should >have >thought about this problem years ago and kept some of the RFC 1918 space >for NAT444 usage. But here we are, and we don't have RFC1918 space reserved for NAT444. We are only=20 asking for a /10 for Shared Transition Space - we calculate the aggregate demand to be close to 10x what we are requesting. Given the current situation, I believe this is the most responsible way to supply addresses for NAT444 (or other transition technologies) - it doesn't squat and it reduces the amount of global unicast address space required vs. direct assignment. This should reduce the number of users who need to sit behind the CGN while we transition to IPv6. > >Failing that, I would have gone for 1.0.0.0/8 for this purpose, since it's >already compromised by bogons. But that ship has sailed. So I don't think >there >*is* a solution for this problem that doesn't consume some global space >that >should have been used in a normal way. Why would the IETF want to be party >to that? It's an operational issue. Per RFC 2860, the IETF needs to be involved with allocations for specific technical purposes. Since 1/8 is not an option, I believe shared transition space is the best option remaining (FWIW, people in the ARIN region have been talking about possibly using reclaimed Interop space for shared=20 transition space; it's not likely to be pristine GUA space). > >> On the basic motivation for your objection, I won't argue. I don't >>really >> like NAT, especially the CGN variety, and would rather have native >>IPv6. (I >> think I can almost hear a chorus of "amen" from the IETF devout...) >>=20 >> But in reality, the IETF doesn't "endorse" a technology - the market >>does by >> choosing what to deploy. And CGN is already deployed, is currently being >> deployed, and/or is part of deployment plans at just about every ISP >>that >> I've spoken with. Most of them are focused on NAT444 for various >>reasons. >> They all need Shared Transition Space, and unless we make this >>reservation >> they will be forced to explore the "alternatives" described in >> draft-bdgks-arin... Shutting off IPv4 connectivity is not currently an >> option. > >Of course not, and although there are certainly alternative approaches >(see below) it's too late to avoid CGNs. Through testing, we've identified that IPv6 performs better than both NAT444 and DS-Lite. After IPv4 exhaustion, I think the market will move expeditiously towards IPv6, especially when more consumer electronics start adding IPv6 support. > >>=20 >>> At the very minimum, if draft-weil is to proceed, it should describe >>>the >>> phase-out plan for the proposed prefix (i.e. the phase-out plan for CGN >>> deployment). One approach to that is documented in RFC 6264. >>=20 >> This was previously discussed amongst the authors of draft-weil and >> draft-bdgks, and it's not obvious per that discussion that a phase-out >>plan >> is useful. > >It's only by describing a phase-out plan that you can make a convincing >case that this a stop-gap, in which case people might just hold their >noses >instead of trying to stop it. The problem is that we don't really know exactly when consumers will adopt IPv6. As you say, the IETF is more involved with defining technologies than addressing operational issues - this is an operational issue, and is likely to vary provider-by-provider based on their mix of subscribers and different customer hardware replacement cycles. A number of the operators I have spoken with are doing their best to avoid NAT444, but may be forced to deploy it eventually to continue offering IPv4 service to those who need it. > >>=20 >> During the period of time that IPv4 connectivity is necessary, the >>Shared >> Transition Space reservation is likely to be needed. After an effective >>IPv6 >> transition, when the Shared Transition Space is no longer needed, it >>won't >> matter if it's returned to the pool because IPv4 address demand will >> decrease. Thus it doesn't make sense to worry about a phase-out plan. >>(BTW, >> reclamation of unused IPv4 GUA post-transition would gain more >>inventory, >> but also isn't worth the hassle.) > >Sure - it's not the reservation of the prefix that phases out, it's the >need to use it. >>=20 >> In other words, I'm assuming that we won't encounter (or won't know) a >> growing IPv4 Internet with no NAT444 in use. The edge-case possibility, >>of >> 100% IPv6 clients combined with increasing IPv4 demand, seems unlikely. >>If >> you think I'm overlooking some other possibility, please clarify. > >There is a class of solutions in which there is no need for NAT44 in the >CPE, >and a single layer of NAT44 is provided at the ISP end of a 4-over-6 >tunnel. >Indeed, that is DS-Lite and it's part of process of removing NAT444 from >the picture. Again, see RFC 6264. An ISP that follows that path will be >able to >phase out whatever IPv4 prefix(es) it uses for NAT444 "Transition Space". Sure, but it's not at all clear that DS-Lite will offer a better experience to the subscriber than NAT444. If it does make a noticeable difference, I expect that the market will move towards it (particularly given RFC 6264). I'm not sure we need to mandate such a transition plan here - ISPs are concerned about offering customers a good experience, and will do the best they can with the technology available. In the short term, however, NAT444/NAT44/or something similar will probably be necessary for many providers, and I believe that shared transition space offers the best path forward until we get to native IPv6. Chris >Regards > Brian >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From sagriffith@gci.com Tue Aug 2 10:29:57 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5F011E8098 for ; Tue, 2 Aug 2011 10:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-0uc2W92WzN for ; Tue, 2 Aug 2011 10:29:56 -0700 (PDT) Received: from mailgw2.gci.com (mailgw2.gci.com [209.165.141.87]) by ietfa.amsl.com (Postfix) with ESMTP id 7EADC11E807B for ; Tue, 2 Aug 2011 10:29:55 -0700 (PDT) Received: from dtn1cas01.gci.com (10.100.4.60) by mailgw2.gci.com (172.19.0.32) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 2 Aug 2011 09:29:57 -0800 Received: from fnb1mbx01.gci.com ([10.100.230.59]) by dtn1cas01.gci.com ([10.100.4.60]) with mapi; Tue, 2 Aug 2011 09:29:57 -0800 From: Scott A Griffith To: "opsawg@ietf.org" Date: Tue, 2 Aug 2011 09:29:56 -0800 Thread-Topic: draft-weil Thread-Index: AcxROcwM0dQ6CfAaTCeJM/JLzo/D/Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA5D74141C725sagriffithgcicom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= X-Mailman-Approved-At: Thu, 04 Aug 2011 08:01:29 -0700 Cc: Leif Sawyer Subject: [OPSAWG] draft-weil X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:47:53 -0000 --_000_CA5D74141C725sagriffithgcicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable GCI supports the draft-wiel proposal for a /10 shared transition space. Thanks Scott Griffith GCI Product Manager 9078686717 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-requ= est-03.txt --_000_CA5D74141C725sagriffithgcicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
GCI supports the draft-w= iel proposal for a /10 shared transition space.

Th= anks

Scott Griffith
GCI Product Manager<= /div>
9078686717


A URL for this Internet-Draft i= s:
http://ww= w.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.tx= t

--_000_CA5D74141C725sagriffithgcicom_-- From owen@delong.com Thu Aug 4 13:30:25 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4604D11E8082 for ; Thu, 4 Aug 2011 13:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaNei33ElRt8 for ; Thu, 4 Aug 2011 13:30:24 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 67F5411E8077 for ; Thu, 4 Aug 2011 13:30:24 -0700 (PDT) Received: from delong-dhcp202.delong.com (delong-dhcp2 [192.159.10.202]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p74KThIF010420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 4 Aug 2011 13:29:43 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p74KThIF010420 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1312489783; bh=OvM5ie+fgRDoS3hgkym/Sb8nFTQ=; h=From:Content-Type:Subject:Date:Message-Id:To:Mime-Version; b=VXxjX/uBIeDxCpKcY+3CCOST7ZBHM4Dz/zUF8+TVW5+8YS9McPH3593cJXzBpd2Xu frk/x8kWh2lYxXMNzlVm+WT4AdVfiu7B/+b5n5Q9LVTIScRd2rExNpjEXRZXMl6z8J Lz67lvWNo7etKHJvfMwVV82RzsuVr6XtKwgKy9V8= From: Owen DeLong Content-Type: multipart/signed; boundary="Apple-Mail=_0649121A-BD3B-4DDF-9A13-6BFABFA58240"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 4 Aug 2011 13:29:43 -0700 Message-Id: <6FA61480-6493-4659-A6C8-80C5A1CCDEA1@delong.com> To: opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Thu, 04 Aug 2011 13:29:43 -0700 (PDT) Subject: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:30:20 -0000 --Apple-Mail=_0649121A-BD3B-4DDF-9A13-6BFABFA58240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am strongly in support of this draft. It is badly needed by the = operational community. Owen --Apple-Mail=_0649121A-BD3B-4DDF-9A13-6BFABFA58240 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY 0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1 V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8 UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL /euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDQyMDI5NDNaMCMGCSqGSIb3DQEJBDEWBBQ9sOfvFRUS f+UUW+AFZhdQ/3S+yjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU MA0GCSqGSIb3DQEBAQUABIIBAMPCQjaEXhLFT+mJGi1zOWEMud+DZV/mUduCHTBHlpDFvfPwuawF v1X58Lc4SHrjHpKflpIR2/fBEqbiYpoajkXi4xIFrRuk5kPhNKNpsNXn/pI2WzX3J7iZyKDwyz5m k4xx7CxKbDbB4nVqpD62PNS4PFvTarpsuuD+NForJu8FfFlkLTeak0+EPC+H3FDS7x3eh4G36mxb fk3hB5NufTELFFH+gw5qlQIZAd3vRdwvCHW6AZWkBRLccKJMeNUw8cJhPI2XxBOPwiESVFW3FYE4 ZjnBHjyvrza2XT6Atz0bx/oJes7bLEPi2DJHUGeAsfQPx7T7BPd8CFM9IJ+SBuAAAAAAAAA= --Apple-Mail=_0649121A-BD3B-4DDF-9A13-6BFABFA58240-- From sumanth@cablelabs.com Thu Aug 4 15:01:40 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDAD21F8A4F for ; Thu, 4 Aug 2011 15:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyIcmWbnMrm3 for ; Thu, 4 Aug 2011 15:01:39 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id AE4C821F8A36 for ; Thu, 4 Aug 2011 15:01:39 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p74M1sD6013739 for ; Thu, 4 Aug 2011 16:01:54 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 4 Aug 2011 16:01:54 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 4 Aug 2011 16:01:54 -0600 From: Sumanth Channabasappa To: "opsawg@ietf.org" Date: Thu, 4 Aug 2011 16:01:51 -0600 Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxS7cJ0p8wA5d5UTqSgCWvkYGCAKAABEc2Q Message-ID: <76AC5FEF83F1E64491446437EA81A61F8190804F43@srvxchg> References: <6FA61480-6493-4659-A6C8-80C5A1CCDEA1@delong.com> In-Reply-To: <6FA61480-6493-4659-A6C8-80C5A1CCDEA1@delong.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:01:40 -0000 +1=20 -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Owen DeLong Sent: Thursday, August 04, 2011 2:30 PM To: opsawg@ietf.org Subject: [OPSAWG] WGLC on shared transition space I am strongly in support of this draft. It is badly needed by the operation= al community. Owen From v.sarawat@CableLabs.com Thu Aug 4 15:21:53 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7C21F8ABB for ; Thu, 4 Aug 2011 15:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2J2zaRmeyGu for ; Thu, 4 Aug 2011 15:21:53 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4549621F8AB0 for ; Thu, 4 Aug 2011 15:21:53 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p74MM55t016398; Thu, 4 Aug 2011 16:22:05 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 4 Aug 2011 16:22:05 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 4 Aug 2011 16:22:06 -0600 From: Vikas Sarawat To: "Scott O. Bradner" , "opsawg@ietf.org" Date: Thu, 4 Aug 2011 16:22:31 -0600 Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxS9PEbDWMexBkmRN6DScTeEhwuqA== Message-ID: In-Reply-To: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:21:54 -0000 I support this draft. On 8/2/11 8:56 AM, "Scott O. Bradner" wrote: > >this starts a WGLC on draft-weil-shared-transition-space-request-03.txt > >comments to the list by Aug 16 please > >Scott > >--- >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : IANA Reserved IPv4 Prefix for Shared Transition Space > Author(s) : Jason Weil > Victor Kuarsingh > Chris Donley > Telstra Corp > Marla Azinger > Filename : draft-weil-shared-transition-space-request-03.txt > Pages : 12 > Date : 2011-08-02 > > This document requests a reserved IANA IPv4 address allocation as > Shared Transition Space to support the deployment of IPv4 address > sharing technologies post IPv4 exhaustion > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-req >uest-03.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-requ >est-03.txt >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From matthew@matthew.at Thu Aug 4 16:03:41 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B69521F86BC for ; Thu, 4 Aug 2011 16:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Dvwy7EXxMoA for ; Thu, 4 Aug 2011 16:03:40 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B4A21F86BD for ; Thu, 4 Aug 2011 16:03:40 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id B23AF14808B; Thu, 4 Aug 2011 16:03:55 -0700 (PDT) Message-ID: <4E3B255A.6040200@matthew.at> Date: Thu, 04 Aug 2011 16:03:54 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Brian E Carpenter References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> In-Reply-To: <4E387674.5000000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: matthew@matthew.at List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:03:41 -0000 On 8/2/2011 3:13 PM, Brian E Carpenter wrote: > I have concluded that it is inappropriate for the IETF to endorse > this hack. I agree. The "middle" network for NAT444 can be numbered by the ISP with RFC1918 space in all cases except those where the specific block from RFC1918 space conflicts with customer internal use, a situation which can be arranged to be rare and which is easily both detected and fixed if encountered. If it is desired to never encounter that situation, globally unique space already allocated to the ISP may be used (and reused multiple times if necessary) instead of RFC1918 space. If two or more ISPs wish to agree to reuse portions of one another's space for this purpose, there's nothing stopping that from happening either. Setting aside a block for this purpose has the following drawbacks: 1. Reduces the number of rapidly diminishing globally unique IPv4 addresses 2. Provides a shared block that is known to never conflict with RFC1918 space, and thus will be used for numerous other applications outside of the applicability statement (such as it is) in Section 4 of the draft. For example, corporate network operators will undoubtedly use this space to facilitate VPNs between two different companies that have overlapping RFC1918 space, and may even choose to place intranet servers in this space during merger and acquisition activities. This will then conflict with its use as the middle layer of NAT444 should the company be moved to a NAT444 environment without its knowledge. Note that this use case is SPECIFICALLY called out in section 2.1.2 of draft-bdgks-arin-shared-transition-space-00, with no mention of how it breaks the actual intended purpose of the space. Also note that this use case is outside of the scope of the ARIN proposal. 3. Provides a shared block that is known to not conflict with RFC1918 space that does not "use up" an ISPs globally unique addresses, thus providing an opportunity to continue deploying IPv4 services to customers rather than transitioning to IPv6, thus making this NOT an IPv6 transition mechanism. Note that this use case is SPECIFICALLY called out in section 2.1.3 of draft-bdgks-arin-shared-transition-space-00, with no mention that it counters the goal of facilitating IPv4 to IPv6 transition. Also note that this use case is outside the scope of the ARIN proposal. Additional comments on draft-bdgks-arin-shared-transition-space-00: Section 2.1.3: The "care must be taken" is impossible. ANY multihomed customer will be negatively impacted by an overlap in address space exposed by their upstream provider. Section 2.2.2: The converse of "default behaviors... which may not be desirable" is not mentioned. For example, a node seeing such a shared address will assume that it has a globally unique address rather than (correctly) assuming that it is behind a NAT device. 6to4 and several peer-to-peer protocols would exhibit this incorrect behavior. This is addressed in 4.1.2, but not referenced here. Section 2.2.3: Should note that any case where the service provider controls a NATing CPE does in fact work, otherwise agree with analysis. Section 4.1.3: Conflicts directly with 2.1.2 and 2.1.3 in that those sections recommend misuse. Section 5.1.1: Correctly notes that the question has been asked, and answered in the negative, even in the recent past... I suppose we'll just get the same thing requested at more and more frequent intervals until either it finally passes or there's no /8 or /10 or whatever left to allocate. Matthew Kaufman From brian.e.carpenter@gmail.com Thu Aug 4 16:06:41 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FBF21F869D for ; Thu, 4 Aug 2011 16:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPRgM8-yg6Fi for ; Thu, 4 Aug 2011 16:06:41 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 276DD21F86C7 for ; Thu, 4 Aug 2011 16:06:40 -0700 (PDT) Received: by fxe6 with SMTP id 6so2800238fxe.31 for ; Thu, 04 Aug 2011 16:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2fUhFf8qwJiRFdjP0Sy2B8h+fSQJSmxOVEuLAFbU5QY=; b=u0BmVAUwso6m0XwoCutH9TWRfrITJl8WFxa5JsfJ7haGmvxH0JHZyFfOxu1qUOk1DZ 7p+2cZ+SdPo80+TFYEdW7eR7J0VoMufKAiFRnDtPiGqgVOFERv4dm5Oa1feWw+zWe4B+ d99AmZTVCG05AMenB8Iyen/TZc4BML+hUGhuI= Received: by 10.204.32.207 with SMTP id e15mr475607bkd.60.1312499216348; Thu, 04 Aug 2011 16:06:56 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id 6sm458821fas.26.2011.08.04.16.06.52 (version=SSLv3 cipher=OTHER); Thu, 04 Aug 2011 16:06:55 -0700 (PDT) Message-ID: <4E3B2607.5040009@gmail.com> Date: Fri, 05 Aug 2011 11:06:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott A Griffith References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , Leif Sawyer Subject: Re: [OPSAWG] draft-weil X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:06:42 -0000 Um, companies don't participate in the IETF. Regards Brian Carpenter On 2011-08-03 05:29, Scott A Griffith wrote: > GCI supports the draft-wiel proposal for a /10 shared transition space. > > Thanks > > Scott Griffith > GCI Product Manager > 9078686717 > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03.txt > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From brian.e.carpenter@gmail.com Thu Aug 4 16:20:01 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD62C11E8092 for ; Thu, 4 Aug 2011 16:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au81cSKZ3WYk for ; Thu, 4 Aug 2011 16:20:01 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13F5111E808D for ; Thu, 4 Aug 2011 16:20:00 -0700 (PDT) Received: by fxe6 with SMTP id 6so2809540fxe.31 for ; Thu, 04 Aug 2011 16:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HoXA1yEL/5DDGZpJZu6SfIGdp/GNV5DFKxv0YqpGHsk=; b=F5Dy0//S/yzIL6d5nO7KXs4x7dN5MY3Eam9v7gvfaq6akmLM8Pkvy5ITv08AYUe8gL tisqy4jR2iVdec8kkt8ZrgMGv3brHDnpwl0AN0S6nm58YK3XfzcUMRkSZ1cldVsjlzS/ XSsCbOTUSICsHuQyBsb08Ffw4JYm55LfR0+N8= Received: by 10.204.70.76 with SMTP id c12mr508932bkj.70.1312500016372; Thu, 04 Aug 2011 16:20:16 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id j19sm1555433faa.41.2011.08.04.16.20.12 (version=SSLv3 cipher=OTHER); Thu, 04 Aug 2011 16:20:15 -0700 (PDT) Message-ID: <4E3B2927.9080604@gmail.com> Date: Fri, 05 Aug 2011 11:20:07 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Chris Donley References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:20:01 -0000 Chris, To avoiding repeating myself on the issues where we disagree, I will just comment on one of your points, which is a new one: > Per RFC 2860, the IETF needs to be involved with allocations for specific > technical purposes. It's a matter of judgment whether that applies in this case or not. Having been the original drafter of the MoU that became RFC 2860, I must say this isn't a clear-cut case. RFC 1918 was already ancient history when the MoU was drafted, so I certainly never wondered about it. The actual clause refers to "(b) assignments of specialised address blocks (such as multicast or anycast blocks)," whereas this case is a block of global unicast space. It's certainly a point to be considered. My feeling is that this is an operational assignment, not a "specialised address block", but clearly YMMV. Regards Brian Carpenter From jeff.finkelstein@cox.com Thu Aug 4 16:47:11 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70F311E8092 for ; Thu, 4 Aug 2011 16:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaAsv9GaHWV4 for ; Thu, 4 Aug 2011 16:47:11 -0700 (PDT) Received: from post1.cox.com (post1.cox.com [24.248.74.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9C611E807C for ; Thu, 4 Aug 2011 16:47:11 -0700 (PDT) Received: from ([192.168.74.254]) by post1.cox.com with ESMTP with TLS id 5502276.357115376; Thu, 04 Aug 2011 19:47:25 -0400 Received: from CATL0MS102.corp.cox.com ([169.254.1.114]) by CATL0MS404.corp.cox.com ([10.62.236.93]) with mapi; Thu, 4 Aug 2011 19:47:24 -0400 From: To: Date: Thu, 4 Aug 2011 19:47:01 -0400 Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxS7cJ0p8wA5d5UTqSgCWvkYGCAKAABEc2QAAOxHjA= Message-ID: <3FA230A64AB0F8428A52DD16D1C2071E18CD5C626F@CATL0MS102.corp.cox.com> References: <6FA61480-6493-4659-A6C8-80C5A1CCDEA1@delong.com>, <76AC5FEF83F1E64491446437EA81A61F8190804F43@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F8190804F43@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:47:11 -0000 +2 ________________________________________ From: opsawg-bounces@ietf.org [opsawg-bounces@ietf.org] On Behalf Of Sumant= h Channabasappa [sumanth@cablelabs.com] Sent: Thursday, August 04, 2011 6:01 PM To: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on shared transition space +1 -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Owen DeLong Sent: Thursday, August 04, 2011 2:30 PM To: opsawg@ietf.org Subject: [OPSAWG] WGLC on shared transition space I am strongly in support of this draft. It is badly needed by the operation= al community. Owen _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From sob@harvard.edu Thu Aug 4 16:50:49 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79E111E8092 for ; Thu, 4 Aug 2011 16:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jC-g6+3KvjnA for ; Thu, 4 Aug 2011 16:50:49 -0700 (PDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by ietfa.amsl.com (Postfix) with ESMTP id C23F311E807C for ; Thu, 4 Aug 2011 16:50:48 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by golem.sobco.com (Postfix) with ESMTP id F3FBC707E627 for ; Thu, 4 Aug 2011 19:51:03 -0400 (EDT) From: "Scott O. Bradner" Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5--812785192 Date: Thu, 4 Aug 2011 19:51:03 -0400 In-Reply-To: <4E3B2927.9080604@gmail.com> To: opsawg@ietf.org References: <4E3B2927.9080604@gmail.com> Message-Id: <6BBD91FC-4F2F-45F8-AA08-392036FA7F25@harvard.edu> X-Mailer: Apple Mail (2.1084) Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:50:50 -0000 --Apple-Mail-5--812785192 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii see = http://www.iab.org/documents/correspondence-reports-documents/2011-2/respo= nse-to-arins-request-for-guidance-regarding-draft-policy-arin-2011-5/ fir the IAB's view Scott On Aug 4, 2011, at 7:20 PM, Brian E Carpenter wrote: > Chris, >=20 > To avoiding repeating myself on the issues where we disagree, I > will just comment on one of your points, which is a new one: >=20 >> Per RFC 2860, the IETF needs to be involved with allocations for = specific >> technical purposes. >=20 > It's a matter of judgment whether that applies in this case or > not. Having been the original drafter of the MoU that became RFC > 2860, I must say this isn't a clear-cut case. RFC 1918 was > already ancient history when the MoU was drafted, so I certainly > never wondered about it. The actual clause refers to > "(b) assignments of specialised > address blocks (such as multicast or anycast blocks)," > whereas this case is a block of global unicast space. >=20 > It's certainly a point to be considered. My feeling is that > this is an operational assignment, not a "specialised address > block", but clearly YMMV. >=20 > Regards > Brian Carpenter > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg Scott Bradner Harvard University Information Technology Security | Policy, Risk & Compliance +1 617 495 3864 29 Oxford St., Room 407 Cambridge, MA 02138 www.harvard.edu/huit --Apple-Mail-5--812785192 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.iab.org/documents/correspondence-reports-documents/2011-2/= response-to-arins-request-for-guidance-regarding-draft-policy-arin-2011-5/=
fir the IAB's = view

Scott

On Aug 4, = 2011, at 7:20 PM, Brian E Carpenter wrote:

Chris,

To avoiding repeating myself on the = issues where we disagree, I
will just comment on one of your points, = which is a new one:

Per RFC 2860, the = IETF needs to be involved with allocations for = specific
technical = purposes.

It's a matter of judgment whether that = applies in this case or
not. Having been the original drafter of the = MoU that became RFC
2860, I must say this isn't a clear-cut case. RFC = 1918 was
already ancient history when the MoU was drafted, so I = certainly
never wondered about it. The actual clause refers = to
"(b) assignments of specialised
  address blocks = (such as multicast or anycast blocks),"
whereas this case is a block = of global unicast space.

It's certainly a point to be considered. = My feeling is that
this is an operational assignment, not a = "specialised address
block", but clearly YMMV.

Regards
=   Brian = Carpenter
_______________________________________________
OPSAWG = mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg

Scott = Bradner

Harvard University Information = Technology
Security | Policy, Risk & = Compliance
+1 617 495 3864
29 Oxford St., Room = 407
Cambridge, MA 02138
<= div>



= --Apple-Mail-5--812785192-- From owen@delong.com Thu Aug 4 17:20:56 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C914D11E808D for ; Thu, 4 Aug 2011 17:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.442 X-Spam-Level: X-Spam-Status: No, score=-4.442 tagged_above=-999 required=5 tests=[AWL=-2.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgKrzJf1jiAr for ; Thu, 4 Aug 2011 17:20:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 12CA911E8093 for ; Thu, 4 Aug 2011 17:20:54 -0700 (PDT) Received: from delong-dhcp202.delong.com (delong-dhcp2 [192.159.10.202]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p750Iphd014979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 17:18:51 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p750Iphd014979 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1312503532; bh=pdm93yOv4yUe2axVtfmWPnD2Wp4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=S9aGj4+/gJb7P5BtDKbzVhaHwSVRlIxl2lHoPq55cEHfVZMQFgR1aYzbSACJA6eS8 uwQ4L+Ccoq3m4j91jrG04XapQFmJeebFim70/Lf7QqP1xa7sn2rAB7EvmCvwWX9CPF PAPmXqGpo3Eual6QtNQ7PS9xGSkxEegNzp/xz4Zc= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_28F772F1-E178-4DDB-AD4D-8808EAB2CE19"; protocol="application/pkcs7-signature"; micalg=sha1 From: Owen DeLong In-Reply-To: <4E3B255A.6040200@matthew.at> Date: Thu, 4 Aug 2011 17:18:51 -0700 Message-Id: <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> To: matthew@matthew.at X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Thu, 04 Aug 2011 17:18:52 -0700 (PDT) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:20:56 -0000 --Apple-Mail=_28F772F1-E178-4DDB-AD4D-8808EAB2CE19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 4, 2011, at 4:03 PM, Matthew Kaufman wrote: > On 8/2/2011 3:13 PM, Brian E Carpenter wrote: >> I have concluded that it is inappropriate for the IETF to endorse >> this hack. >=20 > I agree. >=20 > The "middle" network for NAT444 can be numbered by the ISP with = RFC1918 space in all cases except those where the specific block from = RFC1918 space conflicts with customer internal use, a situation which = can be arranged to be rare and which is easily both detected and fixed = if encountered. >=20 In the case of a residential ISP where they have millions of customers = distributed across random pieces of RFC-1918 space, how would you (feasibly) arrange for it to be rare, easily detected, and = (feasibly) fixed? This claim utterly ignores the operational realities of the existing = situation, which I and much of the rest of the operational community consider rather a fort=E9 of the IETF at this point, but we're hoping to = change that through participation. > If it is desired to never encounter that situation, globally unique = space already allocated to the ISP may be used (and reused multiple = times if necessary) instead of RFC1918 space. >=20 It is very much desired to avoid this situation. Sure, 100s or even = 1000s of ISPs can do that, resulting in 100s or 1000s of address blocks being allocated to this purpose instead of one. How does that benefit = the community? > If two or more ISPs wish to agree to reuse portions of one another's = space for this purpose, there's nothing stopping that from happening = either. >=20 Other than the operational realities of making ones business dependent = on the continued good will and unchanging nature of the needs of some other business with whom you also happen to be a competitor. Again, please step out of the ivory tower for a moment and look at the = operational reality for the variety of networks that are all asking for this. It really is in the best interests of the internet to make this = happen. > Setting aside a block for this purpose has the following drawbacks: > 1. Reduces the number of rapidly diminishing globally unique IPv4 = addresses >=20 No, it actually increases it because the requests that will result from = a denial will far exceed a /10. > 2. Provides a shared block that is known to never conflict with = RFC1918 space, and thus will be used for numerous other applications = outside of the applicability statement (such as it is) in Section 4 of = the draft. For example, corporate network operators will undoubtedly use = this space to facilitate VPNs between two different companies that have = overlapping RFC1918 space, and may even choose to place intranet servers = in this space during merger and acquisition activities. This will then = conflict with its use as the middle layer of NAT444 should the company = be moved to a NAT444 environment without its knowledge. If they use it that way, they do so knowing full well the difficulties = it may cause. There are lots of examples of the misuse of RFC-1918 space that have not caused any harm to those other than the ones = misusing the space, so, I don't see any reason for this to be different. >=20 > Note that this use case is SPECIFICALLY called out in section 2.1.2 of = draft-bdgks-arin-shared-transition-space-00, with no mention of how it = breaks the actual intended purpose of the space. >=20 That's because in 99% of actual cases it wouldn't actually be a = conflict. The things in this middle space wouldn't need to talk directly to the ISP NAT network and there would be no conflict as a result. > Also note that this use case is outside of the scope of the ARIN = proposal. >=20 Which is utterly irrelevant to the IETF discussion. > 3. Provides a shared block that is known to not conflict with RFC1918 = space that does not "use up" an ISPs globally unique addresses, thus = providing an opportunity to continue deploying IPv4 services to = customers rather than transitioning to IPv6, thus making this NOT an = IPv6 transition mechanism. >=20 I don't believe anyone is considering this an IPv6 transition mechanism. = I believe it is being treated as a survival technique to allow operators to focus on IPv6 transition instead of having to devote vast resources = to resolving NAT conflicts. We have to keep the IPv4 network running and we have to deal with NAT444 even if IPv6 is deployed for some time. = That's the reality we are faced with. However, I don't think anyone is regarding this as an opportunity to = avoid or postpone deploying IPv6. I think they are looking to survive = long enough to get IPv6 deployed and to keep operating the things that = have to keep working on IPv4 that are incapable of doing IPv6 on the = customer end of things at least to the extent possible. > Note that this use case is SPECIFICALLY called out in section 2.1.3 of = draft-bdgks-arin-shared-transition-space-00, with no mention that it = counters the goal of facilitating IPv4 to IPv6 transition. >=20 It does not counter the goal of facilitating IPv4 to IPv6 transition, it = merely makes that process a little less painful. > Also note that this use case is outside the scope of the ARIN = proposal. >=20 Which is still utterly irrelevant to the IETF discussion. >=20 > Additional comments on draft-bdgks-arin-shared-transition-space-00: >=20 Note that is not the draft that is the subject of this last call. I = think everyone agrees there remains work to be done on draft-bdgks, = which was hastily put together by the operations community in an effort to = convey additional information about the need for this draft to get an accelerated last call and adoption. > Section 2.1.3: The "care must be taken" is impossible. ANY multihomed = customer will be negatively impacted by an overlap in address space = exposed by their upstream provider. >=20 Yes. Thus, care must be taken to avoid an overlap that has impact. > Section 2.2.2: The converse of "default behaviors... which may not be = desirable" is not mentioned. For example, a node seeing such a shared = address will assume that it has a globally unique address rather than = (correctly) assuming that it is behind a NAT device. 6to4 and several = peer-to-peer protocols would exhibit this incorrect behavior. This is = addressed in 4.1.2, but not referenced here. >=20 They will ALSO exhibit this behavior if providers use and reuse their = own GUA space. The difference is that with this shared block, it will be = possible, maybe even feasible for software updates to incorporate it = into the shared address perspective. Without this draft, the random = assortment of address blocks used would make such a mitigation of this = issue impossible. Thus you have just made an excellent argument in favor of this draft. > Section 5.1.1: Correctly notes that the question has been asked, and = answered in the negative, even in the recent past... I suppose we'll = just get the same thing requested at more and more frequent intervals = until either it finally passes or there's no /8 or /10 or whatever left = to allocate. >=20 Since there is such a strong operational need, you are correct that the = request is unlikely to go away. Given that ARIN has agreed to hold = addresses in reserve in support of the ARIN policy (which did achieve = consensus) until such time as the IETF/IAB takes appropriate action to = make it available, I believe that your statement would be more = accurately: This will keep coming back until it either passes or until IPv4 is well = on its way to being decommissioned and it becomes moot. Owen --Apple-Mail=_28F772F1-E178-4DDB-AD4D-8808EAB2CE19 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY 0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1 V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8 UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL /euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDUwMDE4NTFaMCMGCSqGSIb3DQEJBDEWBBSNleoXSi2A ra6oB5xZfwstiBtOBzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU MA0GCSqGSIb3DQEBAQUABIIBAEZTh/iCj/SD4D6AGFEpvs7pQKI2AqRevgkfDgX9lyUuBNRfdDBw 1Iqts7LxlHeRnulWJJVrIxa28gCflreqaRGrUkE9wFM7ngjQDIOHtXi7wWqv9OWh2yUlMHjrDGey 1h9F26MVSGbwm+mlYCvQR5fd00GVeYmEyHAqQPbm+bIz6+GaG/zcJg2ycwJTfV9EC/uWWtmEht4p +KsvdOMkvACVDJu24BWrMQ8wfBA+MQPG8OCdzhp+V/UobXKE03UFnhlu2FL7PQ+XNxwFcrNQ1MMZ n9GOviGRNjj2V6ZFwcPt8b2y/B1PkfuFbsroHKkwJTVaAUg/cTzet6FjyyZ0nicAAAAAAAA= --Apple-Mail=_28F772F1-E178-4DDB-AD4D-8808EAB2CE19-- From bschlies@cisco.com Thu Aug 4 17:25:15 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF1C21F869D for ; Thu, 4 Aug 2011 17:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=-1.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7pihsSgyzm4 for ; Thu, 4 Aug 2011 17:25:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 99CBA21F86BD for ; Thu, 4 Aug 2011 17:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=3919; q=dns/txt; s=iport; t=1312503931; x=1313713531; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=HDBBYga2iYkGFpkmkWkBONp2sDlTOTqqlwL/eu4TkLQ=; b=MB/gOVYehpuf8wpjVaenhb8Pm8HYSyE++8fcfV92uvkZjvTi+zHcyChI YykE+cFq3R81Qd+Mz16D7vr9t8wjfPD2naj3yl0oxzv4K0Rrl0QDwJ4bQ PgKbzUdN5JaCpPBMvoaqA++6ZFSYLpQ08z4H+fNahPB6rO3rL6lHogCMo g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANo3O06tJV2c/2dsb2JhbABDgk2ce4c4bneBQAEBAQECARIBKjwSAQgEYzYBAQQOBQkZh0oEoioBnl2GQgSHWoshhRCEW4cX X-IronPort-AV: E=Sophos;i="4.67,320,1309737600"; d="scan'208,217";a="9844134" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 05 Aug 2011 00:25:24 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p750POks000952; Fri, 5 Aug 2011 00:25:24 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 19:25:23 -0500 Received: from 10.21.91.221 ([10.21.91.221]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Fri, 5 Aug 2011 00:25:24 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 04 Aug 2011 19:25:23 -0500 From: Benson Schliesser To: Brian E Carpenter Message-ID: Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxTBio2EkyPr8PC7keG7+sN9Q3nsQ== In-Reply-To: <4E3B2927.9080604@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395330723_19973621" X-OriginalArrivalTime: 05 Aug 2011 00:25:23.0889 (UTC) FILETIME=[2ABDC210:01CC5306] Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:25:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395330723_19973621 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, Brian. On 8/4/11 6:20 PM, "Brian E Carpenter" wrote: >> Per RFC 2860, the IETF needs to be involved with allocations for specific >> technical purposes. > > It's a matter of judgment whether that applies in this case or > not. Having been the original drafter of the MoU that became RFC > 2860, I must say this isn't a clear-cut case. RFC 1918 was > already ancient history when the MoU was drafted, so I certainly > never wondered about it. The actual clause refers to > "(b) assignments of specialised > address blocks (such as multicast or anycast blocks)," > whereas this case is a block of global unicast space. > > It's certainly a point to be considered. My feeling is that > this is an operational assignment, not a "specialised address > block", but clearly YMMV. For what it's worth, I personally agree with your conclusion above. However, the IAB offered a different opinion to the ARIN board. See http://www.iab.org/documents/correspondence-reports-documents/2011-2/respons e-to-arins-request-for-guidance-regarding-draft-policy-arin-2011-5/ for details. This is documented along with other details in http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-01. As a result, I think the ARIN board is reasonable in asking for consensus. Cheers, -Benson --B_3395330723_19973621 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [OPSAWG] WGLC on shared transition space Hi, Brian.

On 8/4/11 6:20 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:

>> Per RFC 2860, the IETF needs to be involved = with allocations for specific
>> technical purposes.
>
> It's a matter of judgment whether that applies in this case or
> not. Having been the original drafter of the MoU that became RFC
> 2860, I must say this isn't a clear-cut case. RFC 1918 was
> already ancient history when the MoU was drafted, so I certainly
> never wondered about it. The actual clause refers to
> "(b) assignments of specialised
>    address blocks (such as multicast or anycast blocks)= ,"
> whereas this case is a block of global unicast space.
>
> It's certainly a point to be considered. My feeling is that
> this is an operational assignment, not a "specialised address
> block", but clearly YMMV.

For what it's worth, I personally agree with your conclusion above.

However, the IAB offered a different opinion to the ARIN board. See http:= //www.iab.org/documents/correspondence-reports-documents/2011-2/response-to-= arins-request-for-guidance-regarding-draft-policy-arin-2011-5/ for detai= ls. This is documented along with other details in http://tools.ietf.or= g/html/draft-bdgks-arin-shared-transition-space-01.

As a result, I think the ARIN board is reasonable in asking for consensus.<= BR>
Cheers,
-Benson
 --B_3395330723_19973621-- From owen@delong.com Thu Aug 4 17:25:30 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DFB21F86EC for ; Thu, 4 Aug 2011 17:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.88 X-Spam-Level: X-Spam-Status: No, score=-3.88 tagged_above=-999 required=5 tests=[AWL=-1.281, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uG4cqajo232 for ; Thu, 4 Aug 2011 17:25:29 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E1FB321F869D for ; Thu, 4 Aug 2011 17:25:28 -0700 (PDT) Received: from delong-dhcp202.delong.com (delong-dhcp2 [192.159.10.202]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p750LoRA015058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 17:21:51 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p750LoRA015058 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1312503711; bh=/Qm8ggJVock4B7mAtUkEBIQoOxo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=ZpPH51ok32GGOr4NDhpnejEwsWsfsVysl+KZhQB6wbSiBma18/AzFwFBvNWkdb7/0 RxkHBVBBBiAIWCDXu0rJ31uXTbKyULXcd4slFkXxH54kaIikpvXb0ivBwcMKXZ5m/y OCtSBwAjElWYAIsnqDvnzrvMrPcHdgROT/8sTouY= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_292AC14D-CD0D-4C6D-90CB-5875B50523A8"; protocol="application/pkcs7-signature"; micalg=sha1 From: Owen DeLong In-Reply-To: <4E3B2927.9080604@gmail.com> Date: Thu, 4 Aug 2011 17:21:50 -0700 Message-Id: <8D0942F5-C411-42F4-8D7C-ACD14748D242@delong.com> References: <4E3B2927.9080604@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Thu, 04 Aug 2011 17:21:51 -0700 (PDT) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:25:30 -0000 --Apple-Mail=_292AC14D-CD0D-4C6D-90CB-5875B50523A8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Brian, If you can get the IAB to recant their statement otherwise to ARIN and give ARIN documentation that they agree with you and feel ARIN is within its charter to do so, then this problem is actually solved and ARIN can allocate the space without this last call succeeding. Absent that, the IAB has interpreted your document differently than you intend and their ruling stands as the "law of the land" for all practical purposes. Owen On Aug 4, 2011, at 4:20 PM, Brian E Carpenter wrote: > Chris, > > To avoiding repeating myself on the issues where we disagree, I > will just comment on one of your points, which is a new one: > >> Per RFC 2860, the IETF needs to be involved with allocations for specific >> technical purposes. > > It's a matter of judgment whether that applies in this case or > not. Having been the original drafter of the MoU that became RFC > 2860, I must say this isn't a clear-cut case. RFC 1918 was > already ancient history when the MoU was drafted, so I certainly > never wondered about it. The actual clause refers to > "(b) assignments of specialised > address blocks (such as multicast or anycast blocks)," > whereas this case is a block of global unicast space. > > It's certainly a point to be considered. My feeling is that > this is an operational assignment, not a "specialised address > block", but clearly YMMV. > > Regards > Brian Carpenter > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail=_292AC14D-CD0D-4C6D-90CB-5875B50523A8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY 0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1 V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8 UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL /euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDUwMDIxNTFaMCMGCSqGSIb3DQEJBDEWBBT7294STJrV RTeWQ4r1ckQgDq6wfTCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU MA0GCSqGSIb3DQEBAQUABIIBADp1C0sU18yAxPB69ZugOoEKbT+bPxvzQXAUU0109qDqTHKZfddi wes4uldZqCQvIBSNC5FS0iDJbkCPc35S3BOkSuSIOCAUgxqOU2yjfjuRVfY9Mfhgkqre28kJmp++ mt71nigMsaoUbuVNrmQdyTmcCex3//6zFIHrfYHCJ29A/4GD0j0iULU1KWVr+jKhruHzfJxOmeJr INqnKnJLM2MHqLtOZgqgvxFKCr0Tplc3kR53s4sWprH8xSNGF8TGeV5fEWVWgVuuASnykwkgiT9Y RZArzfiix2ad7lzzifxvd24MJ2TPpZ58Uyiz/zLPqQlq/MSwE1b5aZn1rMJLM98AAAAAAAA= --Apple-Mail=_292AC14D-CD0D-4C6D-90CB-5875B50523A8-- From matthew@matthew.at Thu Aug 4 18:12:33 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAE821F859E for ; Thu, 4 Aug 2011 18:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.273 X-Spam-Level: X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIWYCpOm9raS for ; Thu, 4 Aug 2011 18:12:32 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C1821F8596 for ; Thu, 4 Aug 2011 18:12:32 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id A99E614808B; Thu, 4 Aug 2011 18:12:46 -0700 (PDT) Message-ID: <4E3B438D.70109@matthew.at> Date: Thu, 04 Aug 2011 18:12:45 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Owen DeLong References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> In-Reply-To: <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: matthew@matthew.at List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 01:12:33 -0000 On 8/4/2011 5:18 PM, Owen DeLong wrote: > On Aug 4, 2011, at 4:03 PM, Matthew Kaufman wrote: > >> On 8/2/2011 3:13 PM, Brian E Carpenter wrote: >>> I have concluded that it is inappropriate for the IETF to endorse >>> this hack. >> I agree. >> >> The "middle" network for NAT444 can be numbered by the ISP with RFC1918 space in all cases except those where the specific block from RFC1918 space conflicts with customer internal use, a situation which can be arranged to be rare and which is easily both detected and fixed if encountered. >> > In the case of a residential ISP where they have millions of customers distributed across random pieces of RFC-1918 space, how > would you (feasibly) arrange for it to be rare, easily detected, and (feasibly) fixed? *Most* "residential" customers are actually in a very tiny portion of RFC1918 space. And the detection strategies range from the various information leakage-before-changeover approaches, like watching their DNS queries, to having customers run software (even from a web page) before you switch them, all the way to my personal favorite: "Dear Customer, your service is about to be seriously degraded by an additional layer of NAT. If you are using <10.99.88.0/24> for your internal network OR you experience a complete outage of your service after please call our support number." > This claim utterly ignores the operational realities of the existing situation, which I and much of the rest of the operational community > consider rather a forté of the IETF at this point, but we're hoping to change that through participation. > >> If it is desired to never encounter that situation, globally unique space already allocated to the ISP may be used (and reused multiple times if necessary) instead of RFC1918 space. >> > It is very much desired to avoid this situation. Sure, 100s or even 1000s of ISPs can do that, resulting in 100s or 1000s of address blocks > being allocated to this purpose instead of one. How does that benefit the community? > 100s and 1000s of address blocks are already allocated to suboptimal purposes... how is this any different? They're going to run out one way or another. And soon. >> If two or more ISPs wish to agree to reuse portions of one another's space for this purpose, there's nothing stopping that from happening either. >> > Other than the operational realities of making ones business dependent on the continued good will and unchanging nature of the needs of > some other business with whom you also happen to be a competitor. Well, post-runout one of you will probably buy the other, thanks the these same "operational realities". > Again, please step out of the ivory tower for a moment and look at the operational reality for the variety of networks that are all asking for > this. It really is in the best interests of the internet to make this happen. > It is "a little easier for ISPs"... I would say that this is in the "best interests" of almost anyone else. The end-users who'll find themselves behind another layer of NAT? Nope. The corporate IT departments that will misuse this instead of switching to IPv6? Nope. The ISPs that put content servers here instead of switching to v6 or even just optimizing the use of their existing space? Nope. I could go on, obviously. >> Setting aside a block for this purpose has the following drawbacks: >> 1. Reduces the number of rapidly diminishing globally unique IPv4 addresses >> > No, it actually increases it because the requests that will result from a denial will far exceed a /10. > Doesn't matter either way, really. >> 2. Provides a shared block that is known to never conflict with RFC1918 space, and thus will be used for numerous other applications outside of the applicability statement (such as it is) in Section 4 of the draft. For example, corporate network operators will undoubtedly use this space to facilitate VPNs between two different companies that have overlapping RFC1918 space, and may even choose to place intranet servers in this space during merger and acquisition activities. This will then conflict with its use as the middle layer of NAT444 should the company be moved to a NAT444 environment without its knowledge. > If they use it that way, they do so knowing full well the difficulties it may cause. There are lots of examples of the misuse of RFC-1918 > space that have not caused any harm to those other than the ones misusing the space, so, I don't see any reason for this to be different. The point is that this particular misuse of the space is such that if it happens, the situation between the customer and the ISP is *no different* than if RFC1918 had been used. You can't argue that RFC1918 won't work *and* that the above outcome is acceptable simultaneously. >> Note that this use case is SPECIFICALLY called out in section 2.1.2 of draft-bdgks-arin-shared-transition-space-00, with no mention of how it breaks the actual intended purpose of the space. >> > That's because in 99% of actual cases it wouldn't actually be a conflict. The things in this middle space wouldn't need to talk directly > to the ISP NAT network and there would be no conflict as a result. You pulled that 99% out of the same place you found the number that tells me that residential users are using "all" of RFC1918, when we both know that most of them are in 192.168.1.0/24. >> Also note that this use case is outside of the scope of the ARIN proposal. >> > Which is utterly irrelevant to the IETF discussion. Sure. We can take the required restriction to the other list... but the ARIN proposal *is* an appendix to one of the two drafts here, and *is* the source of the addresses. IF the ARIN proposal results in a block that, due to ARIN policy reasons, is unable to be used for this use case then this use case can no longer be a justification for the IETF agreeing to the idea. >> 3. Provides a shared block that is known to not conflict with RFC1918 space that does not "use up" an ISPs globally unique addresses, thus providing an opportunity to continue deploying IPv4 services to customers rather than transitioning to IPv6, thus making this NOT an IPv6 transition mechanism. >> > I don't believe anyone is considering this an IPv6 transition mechanism. Section 1 of the draft under consideration: "This document requests that an IPv4 /10 be reserved as Shared Transition Space solely to facilitate deployment of IPv6 transition/IPv4 coexistence technologies." > I believe it is being treated as a survival technique to allow operators > to focus on IPv6 transition instead of having to devote vast resources to resolving NAT conflicts. We have to keep the IPv4 network running > and we have to deal with NAT444 even if IPv6 is deployed for some time. That's the reality we are faced with. > > However, I don't think anyone is regarding this as an opportunity to avoid or postpone deploying IPv6. Don't believe you. Especially when the other draft specifically calls out the use case of extending IPv4 lifetime by putting content distribution servers in this space (a way for ISPs to postpone deploying IPv6) and extranet servers in this space (a way for corporations to postpone deploying IPv6). Take the use cases out as part of the justification for the request if you don't want the request read this way. > I think they are looking to survive long enough to get IPv6 deployed and to keep operating the things that have to keep working on IPv4 that are incapable of doing IPv6 on the customer end of things at least to the extent possible. So the emergency they created is my problem... why? >> Note that this use case is SPECIFICALLY called out in section 2.1.3 of draft-bdgks-arin-shared-transition-space-00, with no mention that it counters the goal of facilitating IPv4 to IPv6 transition. >> > It does not counter the goal of facilitating IPv4 to IPv6 transition, it merely makes that process a little less painful. > Disagree. It allows transition to be postponed. >> Also note that this use case is outside the scope of the ARIN proposal. >> > Which is still utterly irrelevant to the IETF discussion. See above for the reasoning. (Can't rely on that block being available if it is restricted.) >> Additional comments on draft-bdgks-arin-shared-transition-space-00: >> > Note that is not the draft that is the subject of this last call. I think everyone agrees there remains work to be done on draft-bdgks, which > was hastily put together by the operations community in an effort to convey additional information about the need for this draft to get > an accelerated last call and adoption. Then I believe we're doing this in the wrong order. How can I possibly comment as to whether or not a block should be set aside if there's not yet been last call on a document describing how that block would be used? I have hypothesized above about what it might be used for, and pointed out that at least two of those are bad ideas. But it'd be even better to get the actual usage documented before we rush this through. I'm sure ARIN can hold the /10 if that's what it takes. >> Section 2.1.3: The "care must be taken" is impossible. ANY multihomed customer will be negatively impacted by an overlap in address space exposed by their upstream provider. >> > Yes. Thus, care must be taken to avoid an overlap that has impact. And this is different than just using RFC1918 instead of allocating a new /10 how? >> Section 2.2.2: The converse of "default behaviors... which may not be desirable" is not mentioned. For example, a node seeing such a shared address will assume that it has a globally unique address rather than (correctly) assuming that it is behind a NAT device. 6to4 and several peer-to-peer protocols would exhibit this incorrect behavior. This is addressed in 4.1.2, but not referenced here. >> > They will ALSO exhibit this behavior if providers use and reuse their own GUA space. The difference is that with this shared block, it will be possible, maybe even feasible for software updates to incorporate it into the shared address perspective. Without this draft, the random assortment of address blocks used would make such a mitigation of this issue impossible. > > Thus you have just made an excellent argument in favor of this draft. I've made an excellent argument in favor of accelerating, not postponing, the transition certainly. >> Section 5.1.1: Correctly notes that the question has been asked, and answered in the negative, even in the recent past... I suppose we'll just get the same thing requested at more and more frequent intervals until either it finally passes or there's no /8 or /10 or whatever left to allocate. >> > Since there is such a strong operational need, you are correct that the request is unlikely to go away. Given that ARIN has agreed to hold addresses in reserve in support of the ARIN policy (which did achieve consensus) until such time as the IETF/IAB takes appropriate action to make it available, I believe that your statement would be more accurately: > > This will keep coming back until it either passes or until IPv4 is well on its way to being decommissioned and it becomes moot. Well, last I checked it wasn't appropriate to just keep trying to push the same thing through that has been repeatedly rejected, and with good associated reasons. If the IETF allows this, it will open the door to hundreds of other resubmits of equally bad ideas that have been previously rejected. Matthew Kaufman From brian.e.carpenter@gmail.com Thu Aug 4 18:32:49 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DBF21F84F7 for ; Thu, 4 Aug 2011 18:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WZ-TU4jXtNR for ; Thu, 4 Aug 2011 18:32:49 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E67721F84FC for ; Thu, 4 Aug 2011 18:32:48 -0700 (PDT) Received: by fxe6 with SMTP id 6so2903566fxe.31 for ; Thu, 04 Aug 2011 18:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YqfzeUWNyez0896ULlRqK4jG0bvFvo4jn5m5iL5mcJA=; b=c6xPwz9FtMwVIY475st9omjGu3xMD0Z9f97YVkbbj7E3YcSVVBf3ygqjj1ldqbK93n ksm7KcgttjxiA83t+ZRzatGrtK3V2RBgfzdQoS53Eb9VuSbYhkn0byAjTa+4hK/WfARD Wx2CgI7eSwCLYsbcdhjf6WKEffH8xTgSPIz9w= Received: by 10.223.1.195 with SMTP id 3mr2094945fag.11.1312507983746; Thu, 04 Aug 2011 18:33:03 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id y15sm1610834fah.35.2011.08.04.18.33.00 (version=SSLv3 cipher=OTHER); Thu, 04 Aug 2011 18:33:03 -0700 (PDT) Message-ID: <4E3B4847.1090701@gmail.com> Date: Fri, 05 Aug 2011 13:32:55 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <4E3B2927.9080604@gmail.com> <8D0942F5-C411-42F4-8D7C-ACD14748D242@delong.com> In-Reply-To: <8D0942F5-C411-42F4-8D7C-ACD14748D242@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 01:32:49 -0000 Owen, On 2011-08-05 12:21, Owen DeLong wrote: > Brian, > > If you can get the IAB to recant their statement otherwise to ARIN Unfortunately the IAB web site appears to be bizarrely broken from where I sit, and the document is inaccessible (even via the Google cache). > and give ARIN documentation that they agree with you and feel ARIN > is within its charter to do so, then this problem is actually solved and > ARIN can allocate the space without this last call succeeding. > > Absent that, the IAB has interpreted your document differently than > you intend and their ruling stands as the "law of the land" for all practical > purposes. I have no intention of debating the IAB on this, if they've reached the opposite conclusion to me. As I said, YMMV, and it's today's IAB that oversees today's IANA. (However, I think the draft should refer to the IAB opinion, and somebody should fix the IAB web site.) This doesn't change my personal opinion, but once again - that's *my* problem. Brian > > Owen > > On Aug 4, 2011, at 4:20 PM, Brian E Carpenter wrote: > >> Chris, >> >> To avoiding repeating myself on the issues where we disagree, I >> will just comment on one of your points, which is a new one: >> >>> Per RFC 2860, the IETF needs to be involved with allocations for specific >>> technical purposes. >> It's a matter of judgment whether that applies in this case or >> not. Having been the original drafter of the MoU that became RFC >> 2860, I must say this isn't a clear-cut case. RFC 1918 was >> already ancient history when the MoU was drafted, so I certainly >> never wondered about it. The actual clause refers to >> "(b) assignments of specialised >> address blocks (such as multicast or anycast blocks)," >> whereas this case is a block of global unicast space. >> >> It's certainly a point to be considered. My feeling is that >> this is an operational assignment, not a "specialised address >> block", but clearly YMMV. >> >> Regards >> Brian Carpenter >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > From wherrin@gmail.com Thu Aug 4 20:24:35 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6732A22800D for ; Thu, 4 Aug 2011 20:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qXwrak6u2ec for ; Thu, 4 Aug 2011 20:24:34 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1117821F8520 for ; Thu, 4 Aug 2011 20:24:33 -0700 (PDT) Received: by fxe6 with SMTP id 6so2979709fxe.31 for ; Thu, 04 Aug 2011 20:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=2XwfH93c7POAty1CDWLfiHqfIUKIkyYS9N86pzXwrug=; b=r2pwYJN9Yq7OkR6C4hJFd808GXxzYQcr7OiX2mzqI0cLeK1ORO6uXbjXcyJOAGPAXd l23pLxYSL1pD4gO0pZ1pLdX4ecyvVfLA2dVVsV4wuYM3nAZF4g0sH+62eDMWXMeWlsen Xr6UiZEQTtvZnRMeOnPZ8NNX2FEeo1LTqGDpw= Received: by 10.204.153.208 with SMTP id l16mr510704bkw.342.1312514689334; Thu, 04 Aug 2011 20:24:49 -0700 (PDT) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.204.16.74 with HTTP; Thu, 4 Aug 2011 20:24:29 -0700 (PDT) From: William Herrin Date: Thu, 4 Aug 2011 23:24:29 -0400 X-Google-Sender-Auth: BQTqV2JNvTZOn-vch3yULFonldA Message-ID: To: opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 03:24:35 -0000 "Brian E Carpenter" wrote: > I don't think there *is* a solution for this problem that doesn't > consume some global space that should have been used in a > normal way. Why would the IETF want to be party > to that? It's an operational issue. Hi Brian, That's a very good question. Why is this monkey on the IETF's back? The IAB determined that allocating a shared address space was the IETF's responsibility: http://lists.arin.net/pipermail/arin-ppml/2011-June/022596.html "RFC 2860 section 4.3 [leaves] such blocks as the responsibility, and under the authority, of the IETF. [...] Setting aside special addresses should be done within the existing process, i.e. by the IETF." > At the very minimum, if draft-weil is to proceed, it should describe the > phase-out plan for the proposed prefix (i.e. the phase-out plan for CGN > deployment). One approach to that is documented in RFC 6264. draft-weil is stopgap in the sense that all present IPv4-centric work is stopgap pending the ubiquitous deployment of IPv6. There's no need to explicitly phase out this kind of component of IPv4 once IPv4's overall phase-out has begun. And no realistic possibility of doing it sooner. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Thu Aug 4 21:24:08 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BFA11E80B6 for ; Thu, 4 Aug 2011 21:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV0qT0pHhTgZ for ; Thu, 4 Aug 2011 21:24:07 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E370E11E8073 for ; Thu, 4 Aug 2011 21:24:05 -0700 (PDT) Received: by fxe6 with SMTP id 6so3019825fxe.31 for ; Thu, 04 Aug 2011 21:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=911Ixyp3lsQowkV4l3NiMToB7keVjkdPmB5ZdDZPX+U=; b=qhztM0Oy1GPBZjRvk2qBkd4isCFKJARc2wgr2eP5VBfvXjtYoKc3bBJ3x8HKs/iHl9 zVNpz1A55FLU1FycwqlJitsAlRG4Aw0gRL2/yhqoWxEOM897C+cVDkGKMcUrwJf6fg4f pJ4RGxPu7e/K4FhrCDiFtWusnGUSv8xAUZon0= Received: by 10.204.134.79 with SMTP id i15mr502459bkt.186.1312518261595; Thu, 04 Aug 2011 21:24:21 -0700 (PDT) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.204.16.74 with HTTP; Thu, 4 Aug 2011 21:24:01 -0700 (PDT) In-Reply-To: <4E3B255A.6040200@matthew.at> References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> From: William Herrin Date: Fri, 5 Aug 2011 00:24:01 -0400 X-Google-Sender-Auth: 42pDOlLl98I-xo4hDZkFlcpfND8 Message-ID: To: matthew@matthew.at Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 04:24:09 -0000 On Thu, Aug 4, 2011 at 7:03 PM, Matthew Kaufman wrote: > The "middle" network for NAT444 can be numbered by the ISP with RFC1918 > space in all cases except those where the specific block from RFC1918 spa= ce > conflicts with customer internal use, a situation which can be arranged t= o > be rare and which is easily both detected and fixed if encountered. Matthew, Consider: My ISP's local modem pool: 10.1.2.0/27 My IP address today: 10.1.2.3 My company's VPN concentrator: 203.0.113.1 My company's intranet server: 10.1.2.3 My company's file servers: 10.1.2.4-30 My routing table with the VPN active: 10.1.2.3/32 =3D PPP adapter 203.0.113.1/32 -> PPP adapter 0.0.0.0/0 -> VPN adapter Successful pings to intranet.mycompany.com (10.1.2.3): 100% Successful HTTP connections to intranet.mycompany.com (10.1.2.3): 0%. And tomorrow when I dial up again and get 10.1.2.14 as my address, one of the file servers mysteriously won't work. I won't go through the counter-examples for every position centered on the claim that it's "easy" for ISPs to use RFC1918 space for their CGNs. The CGNs need to use space which does not conflict with any of the ISPs' subscribers _OR_ any systems which any of their subscribers interact with while connected to that ISP. For better or for worse, RFC1918 space won't be satisfactory for CGN use. > 2. Provides a shared block that is known to never conflict with RFC1918 > space, and thus will be used for numerous other applications outside of t= he > applicability statement in Section 4 of the draft. I observe that everybody disables congestion control in TCP because they can get away with it and it advantages them. Oh wait, that's right: they don't. Folks are on notice from day 1 that use of the shared addresses outside the applicability scope *will* cause problems for only them and their users. Anyone foolish enough to do it anyway (and there are unlikely to be more than a handful) will undo their mistake when they suffer conflicts like the one I described above. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen@delong.com Fri Aug 5 01:55:33 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E4B21F8AF1 for ; Fri, 5 Aug 2011 01:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=-1.118, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1LGvNmD8oo5 for ; Fri, 5 Aug 2011 01:55:28 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BAC6321F8A97 for ; Fri, 5 Aug 2011 01:55:27 -0700 (PDT) Received: from delong-dhcp202.delong.com (delong-dhcp2 [192.159.10.202]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p758pIuF020289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Aug 2011 01:51:18 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p758pIuF020289 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1312534281; bh=VsCvLmmA0Q355gre+H0HKwALfFY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=4GFtLkL4eueucaFRg6QL9OA5jG+gJUbJOHFTGI1u5hUw+52oEsg9kYiwslEm76f+P pkZDwYwNOJj4QQ+9VlVEtV1juugrgmMRXojAY87flSlgn7Db6Us+aZTH82pHNjWecl wiO0g2eMPTQGe+6JTiP8P0A+KItF0Wd53SkFB9ck= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_FCC8C728-6FE0-403D-A66A-DD1D11245DF9"; protocol="application/pkcs7-signature"; micalg=sha1 From: Owen DeLong In-Reply-To: <4E3B438D.70109@matthew.at> Date: Fri, 5 Aug 2011 01:51:18 -0700 Message-Id: References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> To: matthew@matthew.at X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Fri, 05 Aug 2011 01:51:21 -0700 (PDT) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 08:55:33 -0000 --Apple-Mail=_FCC8C728-6FE0-403D-A66A-DD1D11245DF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 4, 2011, at 6:12 PM, Matthew Kaufman wrote: > On 8/4/2011 5:18 PM, Owen DeLong wrote: >> On Aug 4, 2011, at 4:03 PM, Matthew Kaufman wrote: >>=20 >>> On 8/2/2011 3:13 PM, Brian E Carpenter wrote: >>>> I have concluded that it is inappropriate for the IETF to endorse >>>> this hack. >>> I agree. >>>=20 >>> The "middle" network for NAT444 can be numbered by the ISP with = RFC1918 space in all cases except those where the specific block from = RFC1918 space conflicts with customer internal use, a situation which = can be arranged to be rare and which is easily both detected and fixed = if encountered. >>>=20 >> In the case of a residential ISP where they have millions of = customers distributed across random pieces of RFC-1918 space, how >> would you (feasibly) arrange for it to be rare, easily detected, and = (feasibly) fixed? >=20 > *Most* "residential" customers are actually in a very tiny portion of = RFC1918 space. And the detection strategies range from the various = information leakage-before-changeover approaches, like watching their = DNS queries, to having customers run software (even from a web page) = before you switch them, all the way to my personal favorite: "Dear = Customer, your service is about to be seriously degraded by an = additional layer of NAT. If you are using <10.99.88.0/24> for your = internal network OR you experience a complete outage of your service = after please call our support number." >=20 1. *Most* residential customers may be, but, *ENOUGH* residential = customers to pose a significant and costly problem are spread all over the map. There are some CPE routers out there that = default to having the customer choose 10/172/192.168 and then pick random numbers to fill in the rest of the blank and/or just = use that whole range and default to very sparse DHCP algorithms that might as well be random. The collision potential with any = range chosen by the ISP is high. 2. You are assuming that having them call the support number is somehow = a desirable outcome. When you are charging $20-50/month for a service, having 1% of your 10,000,000 customers call in a = month (100,000 phone calls) is damagingly expensive. >=20 >> This claim utterly ignores the operational realities of the existing = situation, which I and much of the rest of the operational community >> consider rather a fort=E9 of the IETF at this point, but we're hoping = to change that through participation. >>=20 >>> If it is desired to never encounter that situation, globally unique = space already allocated to the ISP may be used (and reused multiple = times if necessary) instead of RFC1918 space. >>>=20 >> It is very much desired to avoid this situation. Sure, 100s or even = 1000s of ISPs can do that, resulting in 100s or 1000s of address blocks >> being allocated to this purpose instead of one. How does that benefit = the community? >>=20 >=20 > 100s and 1000s of address blocks are already allocated to suboptimal = purposes... how is this any different? They're going to run out one way = or another. And soon. >=20 I can't think of a better way to indicate that at its worst, this = proposal is harmless. >>> If two or more ISPs wish to agree to reuse portions of one another's = space for this purpose, there's nothing stopping that from happening = either. >>>=20 >> Other than the operational realities of making ones business = dependent on the continued good will and unchanging nature of the needs = of >> some other business with whom you also happen to be a competitor. >=20 > Well, post-runout one of you will probably buy the other, thanks the = these same "operational realities". I don't think that is necessarily true. In fact, it's equally likely = that some other party will buy the other and decide that they want those addresses for a different purpose, vacate my space and tell me to get = off of theirs. >> Again, please step out of the ivory tower for a moment and look at = the operational reality for the variety of networks that are all asking = for >> this. It really is in the best interests of the internet to make this = happen. >>=20 >=20 > It is "a little easier for ISPs"... I would say that this is in the = "best interests" of almost anyone else. The end-users who'll find = themselves behind another layer of NAT? Nope. The corporate IT = departments that will misuse this instead of switching to IPv6? Nope. = The ISPs that put content servers here instead of switching to v6 or = even just optimizing the use of their existing space? Nope. > I could go on, obviously. >=20 This will reduce the number of end users who will find themselves behind = another layer of NAT, so, yes, it is in their interests. Even with the proposed and/or identified corporate misuses of this space = you described, it would not help them to avoid switching to IPv6, so, that argument is specious at best. In any case, I really don't think = it is the job or mission of the IETF to protect corporate IT from their own failure to read RFCs. ISPs that are likely to put content servers here are not likely to do it = instead of switching to IPv6, they are likely to do it in parallel to = switching to IPv6, so, again, that argument is still specious. As to optimizing the use of their existing space, this proposal allows = them to do just that (see my response to your first point). >>> Setting aside a block for this purpose has the following drawbacks: >>> 1. Reduces the number of rapidly diminishing globally unique IPv4 = addresses >>>=20 >> No, it actually increases it because the requests that will result = from a denial will far exceed a /10. >>=20 >=20 > Doesn't matter either way, really. >=20 Ah, but, actually it does. It won't change the end date, but, it may = (dramatically) reduce the number of users on whom NAT444 is inflicted. >>> 2. Provides a shared block that is known to never conflict with = RFC1918 space, and thus will be used for numerous other applications = outside of the applicability statement (such as it is) in Section 4 of = the draft. For example, corporate network operators will undoubtedly use = this space to facilitate VPNs between two different companies that have = overlapping RFC1918 space, and may even choose to place intranet servers = in this space during merger and acquisition activities. This will then = conflict with its use as the middle layer of NAT444 should the company = be moved to a NAT444 environment without its knowledge. >> If they use it that way, they do so knowing full well the = difficulties it may cause. There are lots of examples of the misuse of = RFC-1918 >> space that have not caused any harm to those other than the ones = misusing the space, so, I don't see any reason for this to be different. >=20 > The point is that this particular misuse of the space is such that if = it happens, the situation between the customer and the ISP is *no = different* than if RFC1918 had been used. You can't argue that RFC1918 = won't work *and* that the above outcome is acceptable simultaneously. >=20 While this is true, in the case of RFC-1918, it becomes a pissing = contest between the customer and the ISP with the ISP having no valid leg to stand on for why the customer should have to renumber their = internal network. In the case of this space, OTOH, there's documented RFC reasons why they shouldn't have used it this way. Additionally, as you pointed out, it's not likely to be the 10,000,000 = residential customers that misuse it this way, it's likely to be the = business customers who are: 1) A much smaller percentage of customers 2) Higher revenue than residential per circuit, generally 3) More reasonable in most cases than residential customers So, while it may be mathematically no different from a purity of the = solution standpoint, the economic realities of the two situations are radically and meaningfully different. >>> Note that this use case is SPECIFICALLY called out in section 2.1.2 = of draft-bdgks-arin-shared-transition-space-00, with no mention of how = it breaks the actual intended purpose of the space. >>>=20 >> That's because in 99% of actual cases it wouldn't actually be a = conflict. The things in this middle space wouldn't need to talk directly >> to the ISP NAT network and there would be no conflict as a result. >=20 > You pulled that 99% out of the same place you found the number that = tells me that residential users are using "all" of RFC1918, when we both = know that most of them are in 192.168.1.0/24. >=20 Actually, surveys conducted to date indicate that far less than 50% of = them are in 192.168.1. Perhaps most of your users are on Linksys, but, that does not mean that is the case nationwide, throughout the ARIN = service region, or, world wide. Other manufacturers have different defaults. No, I did not pull the idea that residential users are using = "all" of RFC1918 out of my imagination. There have been studies of the type you recommended above that have shown that it is not so convenient = as that. While I admit I didn't do an advanced analysis of the numbers, it = doesn't take a rocket scientist to realize that corporate VPN endpoints = (the things you said would be numbered in this space) are not at all = likely to use those numbers as source addresses to talk to the external = internet. >>> Also note that this use case is outside of the scope of the ARIN = proposal. >>>=20 >> Which is utterly irrelevant to the IETF discussion. >=20 > Sure. We can take the required restriction to the other list... but = the ARIN proposal *is* an appendix to one of the two drafts here, and = *is* the source of the addresses. IF the ARIN proposal results in a = block that, due to ARIN policy reasons, is unable to be used for this = use case then this use case can no longer be a justification for the = IETF agreeing to the idea. >=20 Or the ARIN policy can be modified to bring it in line with the IETF = document, OR, the address space, since ARIN is relinquishing it to IANA = for allocation according to this RFC and using the policy as the enabling = language to do so would not actually be subject to the ARIN policy once so relinquished, etc. There are many ways to deal with that discrepancy. >>> 3. Provides a shared block that is known to not conflict with = RFC1918 space that does not "use up" an ISPs globally unique addresses, = thus providing an opportunity to continue deploying IPv4 services to = customers rather than transitioning to IPv6, thus making this NOT an = IPv6 transition mechanism. >>>=20 >> I don't believe anyone is considering this an IPv6 transition = mechanism. >=20 > Section 1 of the draft under consideration: "This document requests = that an IPv4 /10 be reserved as Shared Transition Space solely to = facilitate deployment of IPv6 transition/IPv4 coexistence technologies." >=20 Yes=85 THIS space is not a transition mechanism. It is an ENABLER for = OTHER transition mechanisms. >> I believe it is being treated as a survival technique to allow = operators >> to focus on IPv6 transition instead of having to devote vast = resources to resolving NAT conflicts. We have to keep the IPv4 network = running >> and we have to deal with NAT444 even if IPv6 is deployed for some = time. That's the reality we are faced with. >>=20 >> However, I don't think anyone is regarding this as an opportunity to = avoid or postpone deploying IPv6. >=20 > Don't believe you. Especially when the other draft specifically calls = out the use case of extending IPv4 lifetime by putting content = distribution servers in this space (a way for ISPs to postpone deploying = IPv6) and extranet servers in this space (a way for corporations to = postpone deploying IPv6). >=20 Extending IPv4 lifetime IS NOT the same as postponing deployment of = IPv6. Even with IPv6 deployed, there are valid reasons to preserve certain IPv4 functions. You are mistaking keeping IPv4 alive for not implementing IPv6. It is a = logical fallacy to conflate the two. IPv4 does not have to die for IPv6 to get deployed. > Take the use cases out as part of the justification for the request if = you don't want the request read this way. >=20 The use cases talk about preserving IPv4. They do NOT talk about = delaying IPv6. >> I think they are looking to survive long enough to get IPv6 deployed = and to keep operating the things that have to keep working on IPv4 that = are incapable of doing IPv6 on the customer end of things at least to = the extent possible. >=20 > So the emergency they created is my problem... why? >=20 They did not create the emergency and it isn't your problem. You are not = harmed by the allocation of this space to this purpose. >>> Note that this use case is SPECIFICALLY called out in section 2.1.3 = of draft-bdgks-arin-shared-transition-space-00, with no mention that it = counters the goal of facilitating IPv4 to IPv6 transition. >>>=20 >> It does not counter the goal of facilitating IPv4 to IPv6 transition, = it merely makes that process a little less painful. >>=20 >=20 > Disagree. It allows transition to be postponed. >=20 It really doesn't. >>> Also note that this use case is outside the scope of the ARIN = proposal. >>>=20 >> Which is still utterly irrelevant to the IETF discussion. >=20 > See above for the reasoning. (Can't rely on that block being available = if it is restricted.) >=20 See above for rebuttal to the flawed reasoning. >>> Additional comments on draft-bdgks-arin-shared-transition-space-00: >>>=20 >> Note that is not the draft that is the subject of this last call. I = think everyone agrees there remains work to be done on draft-bdgks, = which >> was hastily put together by the operations community in an effort to = convey additional information about the need for this draft to get >> an accelerated last call and adoption. >=20 > Then I believe we're doing this in the wrong order. How can I possibly = comment as to whether or not a block should be set aside if there's not = yet been last call on a document describing how that block would be = used? >=20 > I have hypothesized above about what it might be used for, and pointed = out that at least two of those are bad ideas. But it'd be even better to = get the actual usage documented before we rush this through. I'm sure = ARIN can hold the /10 if that's what it takes. >=20 That document is largely informational in nature. This document actually = provides the limitations and restrictions on the use of the space and = it's purpose for issuance. >=20 >>> Section 2.1.3: The "care must be taken" is impossible. ANY = multihomed customer will be negatively impacted by an overlap in address = space exposed by their upstream provider. >>>=20 >> Yes. Thus, care must be taken to avoid an overlap that has impact. >=20 > And this is different than just using RFC1918 instead of allocating a = new /10 how? >=20 This particular aspect is not. However, of the millions of subscribers = on the average large residential provider network, as has been recently pointed out to me, very very few of them actually multi home. So, it = differs in the implementation details due to the difference in the type = and magnitude of the afflicted audience. >>> Section 2.2.2: The converse of "default behaviors... which may not = be desirable" is not mentioned. For example, a node seeing such a shared = address will assume that it has a globally unique address rather than = (correctly) assuming that it is behind a NAT device. 6to4 and several = peer-to-peer protocols would exhibit this incorrect behavior. This is = addressed in 4.1.2, but not referenced here. >>>=20 >> They will ALSO exhibit this behavior if providers use and reuse their = own GUA space. The difference is that with this shared block, it will be = possible, maybe even feasible for software updates to incorporate it = into the shared address perspective. Without this draft, the random = assortment of address blocks used would make such a mitigation of this = issue impossible. >>=20 >> Thus you have just made an excellent argument in favor of this draft. >=20 > I've made an excellent argument in favor of accelerating, not = postponing, the transition certainly. >=20 When you have a machine capable of going faster than the speed of light, = let me know. In the meantime, let's stick to reality. The transition isn't going to accelerate enough to make the difference required here. = As much as I would like to see that happen, it isn't realistic. Since meaningful acceleration is not realistic, we have to look at what = can actually be done to mitigate and address the realities we are faced with. >>> Section 5.1.1: Correctly notes that the question has been asked, and = answered in the negative, even in the recent past... I suppose we'll = just get the same thing requested at more and more frequent intervals = until either it finally passes or there's no /8 or /10 or whatever left = to allocate. >>>=20 >> Since there is such a strong operational need, you are correct that = the request is unlikely to go away. Given that ARIN has agreed to hold = addresses in reserve in support of the ARIN policy (which did achieve = consensus) until such time as the IETF/IAB takes appropriate action to = make it available, I believe that your statement would be more = accurately: >>=20 >> This will keep coming back until it either passes or until IPv4 is = well on its way to being decommissioned and it becomes moot. >=20 > Well, last I checked it wasn't appropriate to just keep trying to push = the same thing through that has been repeatedly rejected, and with good = associated reasons. If the IETF allows this, it will open the door to = hundreds of other resubmits of equally bad ideas that have been = previously rejected. >=20 I don't see how a body that is governed by the consensus of those that = show up can avoid it. The reality is that as this becomes more and more = critical to the operational community, the nature of who comes to the = IETF asking for this will continue to evolve until there is enough = operator focus on the IETF that there is no alternative. Owen --Apple-Mail=_FCC8C728-6FE0-403D-A66A-DD1D11245DF9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY 0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1 V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8 UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL /euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDUwODUxMThaMCMGCSqGSIb3DQEJBDEWBBSmU7enKPvA wJ5CVSJFt/3dwmhYtjCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU MA0GCSqGSIb3DQEBAQUABIIBACgwRLaq1l0RRKiVlEPYpufbwChAILvhMydQyl0XWvf2azO06zqI oF+63Z2jlLXYzyPMkHtTpSis1iGKdH5gnxGuORJQhgIFpSibqTG536ffXvL9Vh6a2toD4hrj484d F4dYXKbS2ScKaW7kZFom0OCLbhpRK4txgL9N9dKS3GdxGVHfmO9bs1P61OP6ycmwqZLctUbT7lZm XIUp9ufkz8OlaugRHQuAzKudKvZU7lcY0pfrSD3V/tp4UyrGosnXu/Y00bJoqCu9P/0p0TO+0XLl TEO5+Blb9+VEnc+MarJdLwOezo6mwnngIBUBPN6Mevg3wlPatyIOi8NPFVOyqnkAAAAAAAA= --Apple-Mail=_FCC8C728-6FE0-403D-A66A-DD1D11245DF9-- From matthew@matthew.at Fri Aug 5 10:21:37 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF9421F8C50 for ; Fri, 5 Aug 2011 10:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1CjGDoyeWyC for ; Fri, 5 Aug 2011 10:21:37 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id D262B21F8C4F for ; Fri, 5 Aug 2011 10:21:34 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id BF4A014808B; Fri, 5 Aug 2011 10:21:46 -0700 (PDT) Message-ID: <4E3C26A9.8060808@matthew.at> Date: Fri, 05 Aug 2011 10:21:45 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Owen DeLong References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: matthew@matthew.at List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 17:21:37 -0000 On 8/5/2011 1:51 AM, Owen DeLong wrote: > > 2. You are assuming that having them call the support number is somehow a desirable outcome. When you are charging $20-50/month > for a service, having 1% of your 10,000,000 customers call in a month (100,000 phone calls) is damagingly expensive. > So have them visit a web page beforehand that checks to see what their addressing situation is or something... in reality, I think any ISP that isn't budgeting for more support costs for users they move to NAT444 (which is the only problem, because NEW customers on NAT444 can be told very clearly that certain RFC1918 blocks are "off limits"... or even have that enforced by CPE software changes) is going to be in for a big expensive surprise. > Yes… THIS space is not a transition mechanism. It is an ENABLER for OTHER transition mechanisms. > And a DISABLER for the transition itself, in that it extends the lifetime of IPv4 by allowing ISPs to place content servers in the space instead of on IPv6 addresses, allowing corporate IT departments to put extranet servers in the space instead of on IPv6 addresses, etc. > > Extending IPv4 lifetime IS NOT the same as postponing deployment of IPv6. Disagree. If IPv6 deployment incentives were in fact independent of IPv4 runout, then IPv6 deployment would either be A) a lot farther along or B) not started for most people. And yes, strangely, everyone's IPv6 planning seems to have gotten a big boost with the threat of runout. Take away the threat, and it slows right back down. > IPv4 does not have to die for IPv6 to get deployed. > But it does have to get really close to dead. > The use cases talk about preserving IPv4. They do NOT talk about delaying IPv6. > Right. And the use cases should talk *exclusively* about enabling NAT444 so that dual-stack w/IPv6 + NAT444 is possible, *not* about several other ways this shared block can be (mis)used to extend the lifetime of IPv4 services. > That document is largely informational in nature. This document actually provides the limitations and restrictions on the use of the space and it's purpose for issuance. Then modify this document to restrict the use to exclusively NAT444. Otherwise the resulting RFC will create a mixed message, and those corporate IT departments will be able to point right at those sections when arguing with you about what your NAT did to them. Matthew Kaufman From C.Grundemann@cablelabs.com Fri Aug 5 10:35:24 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803FB21F8B34 for ; Fri, 5 Aug 2011 10:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmI13XcrsA7o for ; Fri, 5 Aug 2011 10:35:24 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 011AC21F8B30 for ; Fri, 5 Aug 2011 10:35:23 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p75HZaWr003054; Fri, 5 Aug 2011 11:35:36 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 5 Aug 2011 11:35:36 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 5 Aug 2011 11:35:37 -0600 From: Chris Grundemann To: "matthew@matthew.at" , Owen DeLong Date: Fri, 5 Aug 2011 11:35:35 -0600 Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxTlC/X+oSw52XFQkODHI7Hr9ZpyQAALUqA Message-ID: <3C0068AB22D70B4DA32B9A2A965968C773EDF4EF1A@srvxchg> References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> <4E3C26A9.8060808@matthew.at> In-Reply-To: <4E3C26A9.8060808@matthew.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 17:35:24 -0000 > Right. And the use cases should talk *exclusively* about enabling NAT444 = so > that dual-stack w/IPv6 + NAT444 is possible, *not* about several other wa= ys > this shared block can be (mis)used to extend the lifetime of > IPv4 services. <...>=20 > Then modify this document to restrict the use to exclusively NAT444. > Otherwise the resulting RFC will create a mixed message, and those > corporate IT departments will be able to point right at those sections wh= en > arguing with you about what your NAT did to them. I am not sure we are reading/discussing the same document, just to be sure = here is the bit I find relevant to your statement (from the ID in WGLC - ht= tp://www.ietf.org/id/draft-weil-shared-transition-space-request-03.txt): 4. Shared Transition Space This document proposes the assignment of a /10 as Shared Transition Space. Shared Transition Space is IPv4 address space reserved for Infrastructure provider use with the purpose of facilitating IPv6 transition and IPv4 coexistence deployment. The requested block SHOULD NOT be utilized for any purpose other than as "inside" addresses in a carrier NAT environment (e.g. between the CGN and customer CPE devices) or for other IPv4 to IPv6 transition infrastructure. Network equipment manufacturers MUST NOT use the assigned block in default or example device configurations. I find that quite clear on what an acceptable use of this space is. The det= ails of applicability of and justification are left out, for further debate= , but the intent of this space is well defined in the draft, imho. It IS fo= r use by service providers to facilitate transition to IPv6, it is NOT for = use by anyone else (corporate IT departments included) for any other purpos= e. Cheers, ~Chris From owen@delong.com Fri Aug 5 10:35:33 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3854021F8B30 for ; Fri, 5 Aug 2011 10:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.336 X-Spam-Level: X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNiJpbfBbydM for ; Fri, 5 Aug 2011 10:35:32 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D5E2F21F8B54 for ; Fri, 5 Aug 2011 10:35:31 -0700 (PDT) Received: from delong-dhcp202.delong.com (delong-dhcp2 [192.159.10.202]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p75HW8HK008493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Aug 2011 10:32:08 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p75HW8HK008493 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1312565529; bh=76SI137COlgN555mEuFsgYDjqig=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=U2SdnXP4JKdl1l32GwO1OvWgcwORFA+51e8Q9R6Ac0qTTd3rmSrcZ425j6MAhfTgA 2lRbl1KEiA2wyzelfibF6Q4xomvHBt6o2WqD+c4Wghb3aXmNwrWgUjxI502TOhjSuT T0CreH6seUpPFU1kL4rsKIVg7qHSihDEQfifjj0c= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_F08EC6F2-DF2A-4327-B376-D404BE89AF8C"; protocol="application/pkcs7-signature"; micalg=sha1 From: Owen DeLong In-Reply-To: <4E3C26A9.8060808@matthew.at> Date: Fri, 5 Aug 2011 10:32:08 -0700 Message-Id: <1ED98036-0EE7-42E1-8E5D-349E623D83C5@delong.com> References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> <4E3C26A9.8060808@matthew.at> To: matthew@matthew.at X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Fri, 05 Aug 2011 10:32:09 -0700 (PDT) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 17:35:33 -0000 --Apple-Mail=_F08EC6F2-DF2A-4327-B376-D404BE89AF8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 5, 2011, at 10:21 AM, Matthew Kaufman wrote: > On 8/5/2011 1:51 AM, Owen DeLong wrote: >>=20 >> 2. You are assuming that having them call the support number is = somehow a desirable outcome. When you are charging $20-50/month >> for a service, having 1% of your 10,000,000 customers call in a = month (100,000 phone calls) is damagingly expensive. >>=20 >=20 > So have them visit a web page beforehand that checks to see what their = addressing situation is or something... in reality, I think any ISP that = isn't budgeting for more support costs for users they move to NAT444 = (which is the only problem, because NEW customers on NAT444 can be told = very clearly that certain RFC1918 blocks are "off limits"... or even = have that enforced by CPE software changes) is going to be in for a big = expensive surprise. >=20 That really doesn't solve the problem. Budgeting for it would require = unwelcome price increases. If you raise your prices and your competitors don't, you don't increase revenue, you decrease your = customer base. The economic reality on the ground simply doesn't support your approach. >> Yes=85 THIS space is not a transition mechanism. It is an ENABLER for = OTHER transition mechanisms. >>=20 >=20 > And a DISABLER for the transition itself, in that it extends the = lifetime of IPv4 by allowing ISPs to place content servers in the space = instead of on IPv6 addresses, allowing corporate IT departments to put = extranet servers in the space instead of on IPv6 addresses, etc. >=20 Continuing to propagate this fiction does not make it true. There is no = way in which this space inhibits the transition. Extending the life of IPv4 does NOT in any way block or impair deployment of IPv6. One = might have been able to argue at one point that it would reduce the pressure to deploy IPv6, but, even that is not really true any more. You keep saying instead of and ignoring the more likely probability of = in addition to. >>=20 >> Extending IPv4 lifetime IS NOT the same as postponing deployment of = IPv6. >=20 > Disagree. If IPv6 deployment incentives were in fact independent of = IPv4 runout, then IPv6 deployment would either be A) a lot farther along = or B) not started for most people. And yes, strangely, everyone's IPv6 = planning seems to have gotten a big boost with the threat of runout. >=20 > Take away the threat, and it slows right back down. >=20 As you have stated, this will not really delay the runout of IPv4. It = will merely reduce the number of customers that have to be subjected to = NAT444 when runout occurs and make the NAT444 transition less painful = for the service providers that are forced to deploy it. >=20 >> IPv4 does not have to die for IPv6 to get deployed. >>=20 >=20 > But it does have to get really close to dead. >=20 And it's already that close. This proposal won't change that momentum at = this point. >> The use cases talk about preserving IPv4. They do NOT talk about = delaying IPv6. >>=20 >=20 > Right. And the use cases should talk *exclusively* about enabling = NAT444 so that dual-stack w/IPv6 + NAT444 is possible, *not* about = several other ways this shared block can be (mis)used to extend the = lifetime of IPv4 services. >=20 Then argue that in the debate around the other draft, but, regardless of = the final set of use cases, the space needs to be set aside for = NAT444+IPv6 whether or not those other use cases end up as part of the = consensus version of the other draft or not. >> That document is largely informational in nature. This document = actually provides the limitations and restrictions on the use of the = space and it's purpose for issuance. >=20 > Then modify this document to restrict the use to exclusively NAT444. = Otherwise the resulting RFC will create a mixed message, and those = corporate IT departments will be able to point right at those sections = when arguing with you about what your NAT did to them. >=20 I disagree. Owen --Apple-Mail=_F08EC6F2-DF2A-4327-B376-D404BE89AF8C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY 0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1 V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8 UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL /euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDUxNzMyMDlaMCMGCSqGSIb3DQEJBDEWBBSmfvvrKRS+ nTSZoDzYw9seixv7cDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU MA0GCSqGSIb3DQEBAQUABIIBALzV2VwjQumgIRN61X3s+aqgl0rFwwM8Q95ZpZGzo5zZPdPWViwJ pKy+8HOBudshD9jCvTGlkZcvDOnW1D+qXF8Ck2vIYLmX1i6c/nlwAGWpoeDT7VXT1+Ntus99GJ6+ QCN496LUD2rlZR2Zwbu+T3FNR80cnFIL153A2+j2uoEAuWWarpbQxbwfo5phqPQWpUqvCxmHG9hK FhRcRPJgfvfgw+kdoQ/YGd9IEi+D6TeWBRAZLhz9vPRBwBCN95O1uUI/6m7b6qXD6UJOzXxkBH5V YmnwZ/xnxORzEGS9HqD7P25l5YyZKpt4MLdk3hdhA//f/0DS7mJ4Oxq4sOoW4g8AAAAAAAA= --Apple-Mail=_F08EC6F2-DF2A-4327-B376-D404BE89AF8C-- From matthew@matthew.at Fri Aug 5 10:40:28 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9785621F8B98 for ; Fri, 5 Aug 2011 10:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2VTzxTMa5Mc for ; Fri, 5 Aug 2011 10:40:28 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C2421F8B7F for ; Fri, 5 Aug 2011 10:40:28 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 6AD6414808B; Fri, 5 Aug 2011 10:40:46 -0700 (PDT) Message-ID: <4E3C2B1C.5000409@matthew.at> Date: Fri, 05 Aug 2011 10:40:44 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Chris Grundemann References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> <4E3C26A9.8060808@matthew.at> <3C0068AB22D70B4DA32B9A2A965968C773EDF4EF1A@srvxchg> In-Reply-To: <3C0068AB22D70B4DA32B9A2A965968C773EDF4EF1A@srvxchg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: matthew@matthew.at List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 17:40:28 -0000 On 8/5/2011 10:35 AM, Chris Grundemann wrote: >> Right. And the use cases should talk *exclusively* about enabling NAT444 so >> that dual-stack w/IPv6 + NAT444 is possible, *not* about several other ways >> this shared block can be (mis)used to extend the lifetime of >> IPv4 services. > <...> >> Then modify this document to restrict the use to exclusively NAT444. >> Otherwise the resulting RFC will create a mixed message, and those >> corporate IT departments will be able to point right at those sections when >> arguing with you about what your NAT did to them. > I am not sure we are reading/discussing the same document, just to be sure here is the bit I find relevant to your statement (from the ID in WGLC - http://www.ietf.org/id/draft-weil-shared-transition-space-request-03.txt): > > 4. Shared Transition Space > > This document proposes the assignment of a /10 as Shared Transition > Space. Shared Transition Space is IPv4 address space reserved for > Infrastructure provider use with the purpose of facilitating IPv6 > transition and IPv4 coexistence deployment. The requested block > SHOULD NOT be utilized for any purpose other than as "inside" > addresses in a carrier NAT environment (e.g. between the CGN and > customer CPE devices) or for other IPv4 to IPv6 transition > infrastructure. Network equipment manufacturers MUST NOT use the > assigned block in default or example device configurations. > > I find that quite clear on what an acceptable use of this space is. The details of applicability of and justification are left out, for further debate, but the intent of this space is well defined in the draft, imho. It IS for use by service providers to facilitate transition to IPv6, it is NOT for use by anyone else (corporate IT departments included) for any other purpose. Change SHOULD NOT to MUST NOT. More clearly define "or for other IPv4 to IPv6 transition infrastructure" so that it is clear that it doesn't include things like CDN server IPv4 addresses or anything else that prolongs the utility of IPv4 by numbering things in this space. And if we're ever going to take the other draft (draft-bdgks-arin-shared-transition-space) or something like it to last call, it should go to last call *first* so that this draft can reference it. Otherwise we're going to reopen this same can of worms in short order. Matthew Kaufman From heather.schiller@verizon.com Fri Aug 5 13:24:02 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861F321F8B77 for ; Fri, 5 Aug 2011 13:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8Pm5lCfZMUp for ; Fri, 5 Aug 2011 13:24:01 -0700 (PDT) Received: from fldsmtpe04.verizon.com (fldsmtpe04.verizon.com [140.108.26.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9874421F8B6B for ; Fri, 5 Aug 2011 13:24:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe04.verizon.com with ESMTP; 05 Aug 2011 20:24:18 +0000 From: "Schiller, Heather A" X-IronPort-AV: E=Sophos;i="4.67,325,1309737600"; d="scan'208";a="109557300" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 05 Aug 2011 20:24:18 +0000 Received: from FHDP1LUMXC7V43.us.one.verizon.com ([169.254.3.159]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Fri, 5 Aug 2011 16:24:18 -0400 To: Chris Grundemann , "matthew@matthew.at" , Owen DeLong Date: Fri, 5 Aug 2011 16:24:16 -0400 Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxTlC/X+oSw52XFQkODHI7Hr9ZpyQAALUqAAAJ/NCA= Message-ID: References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> <4E3C26A9.8060808@matthew.at> <3C0068AB22D70B4DA32B9A2A965968C773EDF4EF1A@srvxchg> In-Reply-To: <3C0068AB22D70B4DA32B9A2A965968C773EDF4EF1A@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 20:24:02 -0000 I am opposed to reserving a /10 for shared transition. In particular I am = opposed to pulling a block for this purpose out of space already delegated = to a [any] region, regardless of whether the most active in a region suppor= t volunteering a block for the purpose. I think good stewardship of the sp= ace would be to allow it to be allocated naturally per regional policies. = As you deploy nat444 you will free up address space in your own network- bu= t taking away a /10 from the community can prevent other networks from grow= ing. There is nothing that prohibits folks who have deployed nat444 from s= haring with each other the range of IP's they have used, and feel can be sa= fely used in another nat444 deployment. =20 "The requested block should not be utilized for any other purpose" That's = a nice "should" which will quickly be forgotten. It doesn't matter what ge= ts put into an RFC, folks are going to use the space however they want on t= he inside of their network. Look at the extensive use of 1/8 and other net= blocks that have now been allocated. The only reason that multicast space = or class E space is not used on lan's for private addressing is that equipm= ent vendors hard coded it to be handled differently. I'm just pointing out= that you aren't going to stop people from using it any way they with. =20 I do agree with Owen's sentiments that facilitating NAT444 will make it eas= ier, and likely for folks to [further] delay v6 deployment. =20 --Heather -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Chris Grundemann Sent: Friday, August 05, 2011 1:36 PM To: matthew@matthew.at; Owen DeLong Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on shared transition space > Right. And the use cases should talk *exclusively* about enabling=20 > NAT444 so that dual-stack w/IPv6 + NAT444 is possible, *not* about=20 > several other ways this shared block can be (mis)used to extend the=20 > lifetime of > IPv4 services. <...>=20 > Then modify this document to restrict the use to exclusively NAT444. > Otherwise the resulting RFC will create a mixed message, and those=20 > corporate IT departments will be able to point right at those sections=20 > when arguing with you about what your NAT did to them. I am not sure we are reading/discussing the same document, just to be sure = here is the bit I find relevant to your statement (from the ID in WGLC - ht= tp://www.ietf.org/id/draft-weil-shared-transition-space-request-03.txt): 4. Shared Transition Space This document proposes the assignment of a /10 as Shared Transition Space. Shared Transition Space is IPv4 address space reserved for Infrastructure provider use with the purpose of facilitating IPv6 transition and IPv4 coexistence deployment. The requested block SHOULD NOT be utilized for any purpose other than as "inside" addresses in a carrier NAT environment (e.g. between the CGN and customer CPE devices) or for other IPv4 to IPv6 transition infrastructure. Network equipment manufacturers MUST NOT use the assigned block in default or example device configurations. I find that quite clear on what an acceptable use of this space is. The det= ails of applicability of and justification are left out, for further debate= , but the intent of this space is well defined in the draft, imho. It IS fo= r use by service providers to facilitate transition to IPv6, it is NOT for = use by anyone else (corporate IT departments included) for any other purpos= e. Cheers, ~Chris _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From owen@delong.com Fri Aug 5 13:55:29 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6C511E80C3 for ; Fri, 5 Aug 2011 13:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QItIqtoJ-Jmk for ; Fri, 5 Aug 2011 13:55:28 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A438D11E80C1 for ; Fri, 5 Aug 2011 13:55:27 -0700 (PDT) Received: from delong-dhcp202.delong.com (delong-dhcp2 [192.159.10.202]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p75KpdAx013665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Aug 2011 13:51:40 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p75KpdAx013665 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1312577500; bh=61FB0ToBRnVhVX307pKlvkb+1qU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=bSC7xdoEeUT+JT3kmCMZcLuKjqP+EJYMNeFL6+BgSe9HELqLnyBrDvnoSIZdf7FnQ 8FUi1hngSj4Mt/eg7VTUFNThqD/UWU39T9ecIwp1Fbo7+4Ht3dh99iqfZ/gbApmruC eHrSKWOeQnU42fMU++wcavFPEnr2nCwWvW7VOPl8= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_93F8B561-26C9-4F67-8F31-0EBE58426231"; protocol="application/pkcs7-signature"; micalg=sha1 From: Owen DeLong In-Reply-To: Date: Fri, 5 Aug 2011 13:51:39 -0700 Message-Id: <6B94B481-B901-48C6-9BB3-B1F3E346C9BE@delong.com> References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> <4E3C26A9.8060808@matthew.at> <3C0068AB22D70B4DA32B9A2A965968C773EDF4EF1A@srvxchg> To: "Schiller, Heather A" X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Fri, 05 Aug 2011 13:51:40 -0700 (PDT) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 20:55:29 -0000 --Apple-Mail=_93F8B561-26C9-4F67-8F31-0EBE58426231 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 5, 2011, at 1:24 PM, Schiller, Heather A wrote: >=20 > I am opposed to reserving a /10 for shared transition. In particular = I am opposed to pulling a block for this purpose out of space already = delegated to a [any] region, regardless of whether the most active in a = region support volunteering a block for the purpose. I think good = stewardship of the space would be to allow it to be allocated naturally = per regional policies. As you deploy nat444 you will free up address = space in your own network- but taking away a /10 from the community can = prevent other networks from growing. There is nothing that prohibits = folks who have deployed nat444 from sharing with each other the range of = IP's they have used, and feel can be safely used in another nat444 = deployment. =20 >=20 > "The requested block should not be utilized for any other purpose" = That's a nice "should" which will quickly be forgotten. It doesn't = matter what gets put into an RFC, folks are going to use the space = however they want on the inside of their network. Look at the extensive = use of 1/8 and other netblocks that have now been allocated. The only = reason that multicast space or class E space is not used on lan's for = private addressing is that equipment vendors hard coded it to be handled = differently. I'm just pointing out that you aren't going to stop people = from using it any way they with. =20 >=20 > I do agree with Owen's sentiments that facilitating NAT444 will make = it easier, and likely for folks to [further] delay v6 deployment. =20 >=20 Interesting=85 Do you agree with me, or, are you agreeing with what I = said. I do not believe that facilitating NAT444 will actually do so=85 That's Matthew Kaufman. The benefit to the community of this proposal is that it reduces the = number of users that have to be subjected to NAT444. It doesn't delay IPv4 exhaustion. It doesn't facilitate a delay in IPv6 deployment. It doesn't eat small children. Owen > --Heather >=20 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf Of Chris Grundemann > Sent: Friday, August 05, 2011 1:36 PM > To: matthew@matthew.at; Owen DeLong > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] WGLC on shared transition space >=20 >> Right. And the use cases should talk *exclusively* about enabling=20 >> NAT444 so that dual-stack w/IPv6 + NAT444 is possible, *not* about=20 >> several other ways this shared block can be (mis)used to extend the=20= >> lifetime of >> IPv4 services. > <...>=20 >> Then modify this document to restrict the use to exclusively NAT444. >> Otherwise the resulting RFC will create a mixed message, and those=20 >> corporate IT departments will be able to point right at those = sections=20 >> when arguing with you about what your NAT did to them. >=20 > I am not sure we are reading/discussing the same document, just to be = sure here is the bit I find relevant to your statement (from the ID in = WGLC - = http://www.ietf.org/id/draft-weil-shared-transition-space-request-03.txt):= >=20 > 4. Shared Transition Space >=20 > This document proposes the assignment of a /10 as Shared Transition > Space. Shared Transition Space is IPv4 address space reserved for > Infrastructure provider use with the purpose of facilitating IPv6 > transition and IPv4 coexistence deployment. The requested block > SHOULD NOT be utilized for any purpose other than as "inside" > addresses in a carrier NAT environment (e.g. between the CGN and > customer CPE devices) or for other IPv4 to IPv6 transition > infrastructure. Network equipment manufacturers MUST NOT use the > assigned block in default or example device configurations. >=20 > I find that quite clear on what an acceptable use of this space is. = The details of applicability of and justification are left out, for = further debate, but the intent of this space is well defined in the = draft, imho. It IS for use by service providers to facilitate transition = to IPv6, it is NOT for use by anyone else (corporate IT departments = included) for any other purpose. >=20 > Cheers, > ~Chris > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail=_93F8B561-26C9-4F67-8F31-0EBE58426231 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY 0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1 V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8 UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL /euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDUyMDUxNDBaMCMGCSqGSIb3DQEJBDEWBBSct2xUQGB6 HcIoOc2WdssVgwPNDzCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU MA0GCSqGSIb3DQEBAQUABIIBAIgUQLh+Yu9W0zqtAVP+Xvh4wx8v4rRPqX/lSOETeshvOB6Cvl6w HZZy1PbT1wSkfHLv73jb3lUOqLQ/Vft7ickWHGcc581GfZkfsOWEVg1RJVO/5s0dJoe4FLHiu2bW O6GBCMVKfw2cH/XVAXvHvatWZAc5fPYpKFjx/tfC+OcjO7gX4T1rkPx6O2b2TQ/yv0C8CLZJCkjA FMlgZ6R/j2cpBIyNmriapaOui9TRSv9Eqq+vwhF1A378CeeGXN8Tv5ZzArN21PdBJhQI1ZD3pbm3 J4jGj+txe8EgMRlJjlqPd/rDO5Rdg12ShR3stdihrep+a6i85gpILKLPNqcQnPYAAAAAAAA= --Apple-Mail=_93F8B561-26C9-4F67-8F31-0EBE58426231-- From brian.e.carpenter@gmail.com Fri Aug 5 14:16:06 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F03E21F87F9 for ; Fri, 5 Aug 2011 14:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qro-G6DOPLch for ; Fri, 5 Aug 2011 14:16:05 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC8621F87D9 for ; Fri, 5 Aug 2011 14:16:05 -0700 (PDT) Received: by fxe6 with SMTP id 6so3917592fxe.31 for ; Fri, 05 Aug 2011 14:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CbQQjMgkep6QPPFND6vYq7kj11VEwibj1LBb7guZ3aA=; b=cz8r5Mauqb9e3yhC3k2FOnphYCoLnz4entUdLMVZ5dHvPFBUTtgjyN00mHKcsfxHoK vf9JKnocoqz7XLj88U1uLp9wXi3V6ZchP4LbacO5d2QBqzfom/cvH6rpXVECsGW6p9zK pPUpUZhanuHs9IPyJ5u9t9Hiq11lGXIakAgq4= Received: by 10.223.21.141 with SMTP id j13mr3470357fab.79.1312578983436; Fri, 05 Aug 2011 14:16:23 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id l22sm518305fam.13.2011.08.05.14.16.19 (version=SSLv3 cipher=OTHER); Fri, 05 Aug 2011 14:16:22 -0700 (PDT) Message-ID: <4E3C5D9C.2070501@gmail.com> Date: Sat, 06 Aug 2011 09:16:12 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> <4E3C26A9.8060808@matthew.at> <3C0068AB22D70B4DA32B9A2A965968C773EDF4EF1A@srvxchg> <6B94B481-B901-48C6-9BB3-B1F3E346C9BE@delong.com> In-Reply-To: <6B94B481-B901-48C6-9BB3-B1F3E346C9BE@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 21:16:06 -0000 Owen, On 2011-08-06 08:51, Owen DeLong wrote: > The benefit to the community of this proposal is that it reduces the number of users that have to be subjected to NAT444. I don't quite understand that claim. It seems to me that the amount of NAT444 deployment is orthogonal to having a designated prefix available - see my next comments. > It doesn't delay IPv4 exhaustion. Agreed, because if there is no designated prefix, ISPs will find a bogon prefix to use instead. Or they will figure out a work-around using RFC 1918 space (despite the quite valid responses to Matthew showing why this is problematic). > It doesn't facilitate a delay in IPv6 deployment. Agreed. It is the availability of CGNs that will give some ISPs a way to ignore IPv6 for a while longer. Having a designated prefix is just an operational convenience. Brian From wherrin@gmail.com Fri Aug 5 14:34:25 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5D711E8087 for ; Fri, 5 Aug 2011 14:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJbVqwlIFnpS for ; Fri, 5 Aug 2011 14:34:24 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8F011E8082 for ; Fri, 5 Aug 2011 14:34:24 -0700 (PDT) Received: by fxe6 with SMTP id 6so3930741fxe.31 for ; Fri, 05 Aug 2011 14:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Ig5+PRPnhmvLejiInPl39apwqN+/hjt49rULJwNACVA=; b=wllI5+aoSoHbtAS4Oam9Fvm6V8dS1Jw0Hoso2F1THEvtExOFij8124iUWAiM4iQogl 5vahK6KaEfpL228CA6lbk6kho7C/WYitRieKS3MlWcjj6tGHUmJ0sZpOgzUoD6P1RRTu EcmD0jsIhwhUFEH/g3DbBmUIuOmFccEk+D7XQ= Received: by 10.204.134.79 with SMTP id i15mr782146bkt.186.1312580081548; Fri, 05 Aug 2011 14:34:41 -0700 (PDT) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.204.16.74 with HTTP; Fri, 5 Aug 2011 14:34:21 -0700 (PDT) In-Reply-To: <4E3C5D9C.2070501@gmail.com> References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> <4E3C26A9.8060808@matthew.at> <3C0068AB22D70B4DA32B9A2A965968C773EDF4EF1A@srvxchg> <6B94B481-B901-48C6-9BB3-B1F3E346C9BE@delong.com> <4E3C5D9C.2070501@gmail.com> From: William Herrin Date: Fri, 5 Aug 2011 17:34:21 -0400 X-Google-Sender-Auth: MdU--Y-Eu9DlyE3M0fJ8_yATD14 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 21:34:25 -0000 On Fri, Aug 5, 2011 at 5:16 PM, Brian E Carpenter wrote: > On 2011-08-06 08:51, Owen DeLong wrote: >> The benefit to the community of this proposal is >> that it reduces the number of users that have to >> be subjected to NAT444. > > I don't quite understand that claim. It seems to me that the amount of NA= T444 > deployment is orthogonal to having a designated prefix available Hi Brian, If each ISP has to carve out its own NAT444 space then we'll get worse efficiency, resulting in more addresses overall being consumed by NAT444 deployments. That leaves fewer IPv4 addresses available for classic use which means more users in total being subjected to NAT444. It's a weak line of reasoning but it's not wrong. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen@delong.com Fri Aug 5 15:55:51 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DAE11E807B for ; Fri, 5 Aug 2011 15:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEGLDiH+mL6o for ; Fri, 5 Aug 2011 15:55:50 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 303A711E8078 for ; Fri, 5 Aug 2011 15:55:50 -0700 (PDT) Received: from delong-dhcp202.delong.com (delong-dhcp2 [192.159.10.202]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p75MtV6q015678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Aug 2011 15:55:31 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p75MtV6q015678 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1312584931; bh=oV+dk/SsotAYXbxMnclIsAOOoFE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=aj7w1M4zvlEV0+O1XiGlSKNPn4q+2A74WpwiSkbbQ4EWNYr5LgGT6MRkwAdr9LLjP P3Qf744yUDk3JtawxyzkeW0waQ8Rar6LOtcMug7f6PzgF0QJUrnFyq1LprbynLArG0 MCA/Hoq5tAJq6qLlTQLqzc1zMVeRfgXpEH5EgzIg= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_38160140-D183-4FBF-9084-E551C599A9C0"; protocol="application/pkcs7-signature"; micalg=sha1 From: Owen DeLong In-Reply-To: <4E3C5D9C.2070501@gmail.com> Date: Fri, 5 Aug 2011 15:55:31 -0700 Message-Id: References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> <4E3C26A9.8060808@matthew.at> <3C0068AB22D70B4DA32B9A2A965968C773EDF4EF1A@srvxchg> <6B94B481-B901-48C6-9BB3-B1F3E346C9BE@delong.com> <4E3C5D9C.2070501@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Fri, 05 Aug 2011 15:55:31 -0700 (PDT) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 22:55:51 -0000 --Apple-Mail=_38160140-D183-4FBF-9084-E551C599A9C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 5, 2011, at 2:16 PM, Brian E Carpenter wrote: > Owen, >=20 > On 2011-08-06 08:51, Owen DeLong wrote: >=20 >> The benefit to the community of this proposal is that it reduces the = number of users that have to be subjected to NAT444. >=20 > I don't quite understand that claim. It seems to me that the amount of = NAT444 > deployment is orthogonal to having a designated prefix available - see = my > next comments. >=20 If providers get a shared /10 that they can use for this purpose, they = do not have to kick existing users off of their current space to recycle it for that = purpose. >> It doesn't delay IPv4 exhaustion. >=20 > Agreed, because if there is no designated prefix, ISPs will find a = bogon prefix > to use instead. Or they will figure out a work-around using RFC 1918 = space > (despite the quite valid responses to Matthew showing why this is = problematic). >=20 >> It doesn't facilitate a delay in IPv6 deployment. >=20 > Agreed. It is the availability of CGNs that will give some ISPs a way = to > ignore IPv6 for a while longer. Having a designated prefix is just an > operational convenience. >=20 It really won't. There was a time when I would have believed this = argument, but, at this point, there is enough momentum building behind IPv6 that they = will be unable to do so due to the number of things at the other end which will = require IPv6 to be reachable. Owen --Apple-Mail=_38160140-D183-4FBF-9084-E551C599A9C0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY 0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1 V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8 UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL /euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDUyMjU1MzFaMCMGCSqGSIb3DQEJBDEWBBRW2b1DJmkA n/qGUOioWnAOTOPrdDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU MA0GCSqGSIb3DQEBAQUABIIBAFCqLS5z5IbWvjqDfS6o4YYWpt1vXHTE6lEs0kW6OEPz/c2iXYrd Dj53s0F8OwAgq1kI2xe1e1XXsU7u7zNW13/wWIOryerjBAq6QoYxRyAEKbWRxkqwSU2CZ9JgfrO+ t9KPGvW06FFgFwQ+1DW3YzEkiWAA8u04SVfg6zsi++/hwHFO89pcjHjJcRqWIxNUrWWq4u239rHO ugfvCmTZCZoopAgSpnHQbqhZVAATti7hAdIg1CE4NFpXE+VcG0izMBlgRz9iie+vRPucyUxTP/+7 Yiya4M34Jrr18Cf8mAaYoneP8OeCCcMfOfph0j3gObZwEODdDRvJwgHxP/XWeQYAAAAAAAA= --Apple-Mail=_38160140-D183-4FBF-9084-E551C599A9C0-- From owen@delong.com Fri Aug 5 15:55:55 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55C111E80AD for ; Fri, 5 Aug 2011 15:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.06 X-Spam-Level: X-Spam-Status: No, score=-3.06 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW9J2LoQ6FEG for ; Fri, 5 Aug 2011 15:55:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A719511E80AC for ; Fri, 5 Aug 2011 15:55:54 -0700 (PDT) Received: from delong-dhcp202.delong.com (delong-dhcp2 [192.159.10.202]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p75MrtQY015648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Aug 2011 15:53:55 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p75MrtQY015648 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1312584836; bh=y0yRZXcS/hqP7zmqKrWNA61T0QU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=C+sZMuLb4BRy8ikYsK6T2CkGOz6d+dKh//+NTjBZSWysvb+tqHbbW72UAeDrWDR2G Y79LrB4oOoev3AQbeqdaGS1MG3PSbJnR6ZhmwSXVGOObpu4WcJK9olgF1+BJvdnkZS g6R7lKcVpU8yiZwe1SmRnyL2Vi9yk2OpqReB+Euw= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_531BF05C-41A7-4D23-BC1B-6CECF03852CC"; protocol="application/pkcs7-signature"; micalg=sha1 From: Owen DeLong In-Reply-To: <6B94B481-B901-48C6-9BB3-B1F3E346C9BE@delong.com> Date: Fri, 5 Aug 2011 15:53:54 -0700 Message-Id: <6523B461-7E8C-45CC-A674-9D546EAE673F@delong.com> References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <4E3B255A.6040200@matthew.at> <84EE4DD0-7EFE-4972-9AA3-A8C69B809D2A@delong.com> <4E3B438D.70109@matthew.at> <4E3C26A9.8060808@matthew.at> <3C0068AB22D70B4DA32B9A2A965968C773EDF4EF1A@srvxchg> <6B94B481-B901-48C6-9BB3-B1F3E346C9BE@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Fri, 05 Aug 2011 15:53:56 -0700 (PDT) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 22:55:55 -0000 --Apple-Mail=_531BF05C-41A7-4D23-BC1B-6CECF03852CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 5, 2011, at 1:51 PM, Owen DeLong wrote: >=20 > On Aug 5, 2011, at 1:24 PM, Schiller, Heather A wrote: >=20 >>=20 >> I am opposed to reserving a /10 for shared transition. In particular = I am opposed to pulling a block for this purpose out of space already = delegated to a [any] region, regardless of whether the most active in a = region support volunteering a block for the purpose. I think good = stewardship of the space would be to allow it to be allocated naturally = per regional policies. As you deploy nat444 you will free up address = space in your own network- but taking away a /10 from the community can = prevent other networks from growing. There is nothing that prohibits = folks who have deployed nat444 from sharing with each other the range of = IP's they have used, and feel can be safely used in another nat444 = deployment. =20 >>=20 >> "The requested block should not be utilized for any other purpose" = That's a nice "should" which will quickly be forgotten. It doesn't = matter what gets put into an RFC, folks are going to use the space = however they want on the inside of their network. Look at the extensive = use of 1/8 and other netblocks that have now been allocated. The only = reason that multicast space or class E space is not used on lan's for = private addressing is that equipment vendors hard coded it to be handled = differently. I'm just pointing out that you aren't going to stop people = from using it any way they with. =20 >>=20 >> I do agree with Owen's sentiments that facilitating NAT444 will make = it easier, and likely for folks to [further] delay v6 deployment. =20 >>=20 >=20 > Interesting=85 Do you agree with me, or, are you agreeing with what I = said. I do not believe that facilitating NAT444 will actually > do so=85 That's Matthew Kaufman. Oops=85 I made the same mistake=85 I meant are you agreeing with me or = agreeing with what you (Heather) said. >=20 > The benefit to the community of this proposal is that it reduces the = number of users that have to be subjected to NAT444. >=20 > It doesn't delay IPv4 exhaustion. > It doesn't facilitate a delay in IPv6 deployment. > It doesn't eat small children. >=20 > Owen >=20 >> --Heather >>=20 >> -----Original Message----- >> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf Of Chris Grundemann >> Sent: Friday, August 05, 2011 1:36 PM >> To: matthew@matthew.at; Owen DeLong >> Cc: opsawg@ietf.org >> Subject: Re: [OPSAWG] WGLC on shared transition space >>=20 >>> Right. And the use cases should talk *exclusively* about enabling=20 >>> NAT444 so that dual-stack w/IPv6 + NAT444 is possible, *not* about=20= >>> several other ways this shared block can be (mis)used to extend the=20= >>> lifetime of >>> IPv4 services. >> <...>=20 >>> Then modify this document to restrict the use to exclusively NAT444. >>> Otherwise the resulting RFC will create a mixed message, and those=20= >>> corporate IT departments will be able to point right at those = sections=20 >>> when arguing with you about what your NAT did to them. >>=20 >> I am not sure we are reading/discussing the same document, just to be = sure here is the bit I find relevant to your statement (from the ID in = WGLC - = http://www.ietf.org/id/draft-weil-shared-transition-space-request-03.txt):= >>=20 >> 4. Shared Transition Space >>=20 >> This document proposes the assignment of a /10 as Shared Transition >> Space. Shared Transition Space is IPv4 address space reserved for >> Infrastructure provider use with the purpose of facilitating IPv6 >> transition and IPv4 coexistence deployment. The requested block >> SHOULD NOT be utilized for any purpose other than as "inside" >> addresses in a carrier NAT environment (e.g. between the CGN and >> customer CPE devices) or for other IPv4 to IPv6 transition >> infrastructure. Network equipment manufacturers MUST NOT use the >> assigned block in default or example device configurations. >>=20 >> I find that quite clear on what an acceptable use of this space is. = The details of applicability of and justification are left out, for = further debate, but the intent of this space is well defined in the = draft, imho. It IS for use by service providers to facilitate transition = to IPv6, it is NOT for use by anyone else (corporate IT departments = included) for any other purpose. >>=20 >> Cheers, >> ~Chris >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail=_531BF05C-41A7-4D23-BC1B-6CECF03852CC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY 0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1 V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8 UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL /euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDUyMjUzNTVaMCMGCSqGSIb3DQEJBDEWBBSpSbvteOdu pX4naF69vqwL+ic8ojCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU MA0GCSqGSIb3DQEBAQUABIIBAMJasvtTt5Emkcv/wLewxKKF4G1AvIuqXdFShAE8QWEx1ZnKh3od 1MWdT0eqh6wgaDjKgd6SsIlj+pynNaZA5dfB/Sda0AMtIVqIDeSwBLQhdvxjDlrHNK0SK/4owzQ0 tKhikd5l9fSeYqi+mY0ujU10x7G9wMiuhE/uOHy0wiwp+yGbjquOQpBkyplJLWM3V55ZuiexK/s9 mBoDkURePC5ldOfBLgADiw5LXJnAvpcNC+tyxD5RZwy25yXZMr4Yl+cNzXRoPSvBXPoVWDrD6dfj kYsC8glMYoy4f91Uo/jxI3vO/KaJNU0LdsnFfCQsxSZLtF1bA2jMhzxoawEPRHEAAAAAAAA= --Apple-Mail=_531BF05C-41A7-4D23-BC1B-6CECF03852CC-- From C.Donley@cablelabs.com Fri Aug 5 16:11:12 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0904021F884F for ; Fri, 5 Aug 2011 16:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke2aD+F2rWPl for ; Fri, 5 Aug 2011 16:11:11 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6633521F8828 for ; Fri, 5 Aug 2011 16:11:11 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id p75NBP26009623; Fri, 5 Aug 2011 17:11:26 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 5 Aug 2011 17:11:26 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Fri, 5 Aug 2011 17:11:26 -0600 From: Chris Donley To: Brian E Carpenter , Owen DeLong Date: Fri, 5 Aug 2011 17:11:23 -0600 Thread-Topic: [OPSAWG] WGLC on shared transition space Thread-Index: AcxTxP99ZoNy8bNPTYOTLfWsmtqNPQ== Message-ID: In-Reply-To: <4E3C5D9C.2070501@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 23:11:12 -0000 Brian, On 8/5/11 3:16 PM, "Brian E Carpenter" wrote: >Owen, > >On 2011-08-06 08:51, Owen DeLong wrote: > >> The benefit to the community of this proposal is that it reduces the >>number of users that have to be subjected to NAT444. > >I don't quite understand that claim. It seems to me that the amount of >NAT444 >deployment is orthogonal to having a designated prefix available - see my >next comments. With current rates of growth, we've calculated that the excess demand for IPv4 addresses will reach ~20% across the industry at the high-water point (YMMV, depending on rates of growth within a specific ISP, tech savvy of the customer base, etc). With tightening address policies in the ARIN region, N. American ISPs would be able to get maybe 1-1.5% IPv4 addresses for CGNs, leaving a large gap. As you mention, bogon space is one option. The others are to move a larger pool of users (e.g. Up to 20% of existing users) behind the CGN and re-use their address space for both the existing and new users, and/or to use multi-level CGN (ouch!). In addition to the back side addresses for the CGN, there's also the question of the front side public addresses. They will likely come from currently-assigned GUA addresses. Shared transition space in the back-end could free up addresses from infrastructure components that don't need to talk to the Internet, thereby moving the addresses to customers who do, rather than subjecting still more users to CGN. > >> It doesn't delay IPv4 exhaustion. > >Agreed, because if there is no designated prefix, ISPs will find a bogon >prefix >to use instead. Or they will figure out a work-around using RFC 1918 space >(despite the quite valid responses to Matthew showing why this is >problematic). My fear is that the bogon prefix might be 'squat' space, and it might vary per provider. This would be a poor outcome for the entire community. See RFC 6319, Section 4.2.2. > >> It doesn't facilitate a delay in IPv6 deployment. > >Agreed. It is the availability of CGNs that will give some ISPs a way to >ignore IPv6 for a while longer. Having a designated prefix is just an >operational convenience. We've been testing CGN in our lab (twice now), and it does not offer the same experience with IPv4 that we're used to. When IPv6 is available in a market, it will offer a better experience, assuming that the customer has IPv6-capable gear and the Internet content is available over IPv6. At that point, I think there will be clear demand for IPv6 service, especially compared to IPv4-with-CGN. IPv6 has been part of DOCSIS specifications since 2006 - the biggest challenge we're facing now is getting IPv6-capable consumer electronics into subscriber homes. While Service Providers have a role to play in bringing IPv6 to subscribers, ultimately, it is the subscribers who will decide how long IPv4 must be supported. =20 Chris > > Brian >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From victor.kuarsingh@gmail.com Sat Aug 6 19:32:21 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BAA21F850C for ; Sat, 6 Aug 2011 19:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGn4yCM7CAkX for ; Sat, 6 Aug 2011 19:32:19 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7578B21F850B for ; Sat, 6 Aug 2011 19:32:16 -0700 (PDT) Received: by iye1 with SMTP id 1so6090120iye.27 for ; Sat, 06 Aug 2011 19:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=D1AD7lYIfh467N0RWzb3blzi5yCrmTmtfojMljwYG6Y=; b=mp8VFbtVXoyK473EAO9srhPLmqazsaEb9emIX0gOM4ypz7sUpsDzVscpP91fGrkyIQ 9fZdpbHblsukYSuRHJsHSDqhyczLJ+kp3vVJreLGDaOMOZkyHgJGp5oUVoxVooa4VvTR LDiahy3hTkqlftxHCCtyh9CwHpVZF3Z1Ipww4= Received: by 10.231.33.131 with SMTP id h3mr2432269ibd.26.1312684356676; Sat, 06 Aug 2011 19:32:36 -0700 (PDT) Received: from [192.168.1.2] ([74.198.164.118]) by mx.google.com with ESMTPS id a11sm3182829ibg.38.2011.08.06.19.32.29 (version=SSLv3 cipher=OTHER); Sat, 06 Aug 2011 19:32:34 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sat, 06 Aug 2011 22:32:22 -0400 From: Victor Kuarsingh To: Chris Donley , Brian E Carpenter Message-ID: Thread-Topic: [OPSAWG] WGLC on shared transition space In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 02:32:21 -0000 Chris/Brian First. Support the draft 100%. A couple of leading comments. In real world tests of CGN (NAT444) we have found problems with using RFC1918 in the NAT Zone (CPE <-> CGN) space forcing our resolve to require non-RFC1918 space for this usage. Assuming we had enough RFC1918 addresses for CGN (which we don't for a production rollout), it's too problematic to use. Global Unicast Space (non-RFC1918) has shown to work very well in our production tests. Use of CGN dose not change the resolve of an ISP to roll out IPv6. IPv6 will continue at it's set pace (quickly for some, more slowly for others). CGN can be used as an assist/glue technology in a dual stack service offering quite well. >> >>> The benefit to the community of this proposal is that it reduces the >>>number of users that have to be subjected to NAT444. >> >>I don't quite understand that claim. It seems to me that the amount of >>NAT444 >>deployment is orthogonal to having a designated prefix available - see my >>next comments. > >In addition to the back side addresses for the CGN, there's also the >question of the front side public addresses. They will likely come from >currently-assigned GUA addresses. Shared transition space in the back-end >could free up addresses from infrastructure components that don't need to >talk to the Internet, thereby moving the addresses to customers who do, >rather than subjecting still more users to CGN. This is a vary valid use of this space. ISPs who can use the "Shared Transition Space" in this type of circumstance can in fact help avoid CGN. > >> >>> It doesn't delay IPv4 exhaustion. We are not talking about delaying exhaustion. We are talking about managing it. >> >>Agreed, because if there is no designated prefix, ISPs will find a bogon >>Prefix This will happen without transition space. >> >My fear is that the bogon prefix might be 'squat' space, and it might vary >per provider. This would be a poor outcome for the entire community. See >RFC 6319, Section 4.2.2. This is a very big concern. Having ISPs choose different parts for the IPv4 space to use in the CGN (NAT444) zone would be very challenging. It will be harder to develop and enforce good network policy. Having a consistent block allows for cleaner industry wide management of this space. Regards, Victor Kuarsingh > From arturo.servin@gmail.com Thu Aug 4 12:08:03 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA0E11E80BC for ; Thu, 4 Aug 2011 12:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CtzOO4ySWZf for ; Thu, 4 Aug 2011 12:08:02 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9894F11E8082 for ; Thu, 4 Aug 2011 12:08:02 -0700 (PDT) Received: by qwc23 with SMTP id 23so1482680qwc.31 for ; Thu, 04 Aug 2011 12:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=XyzD0Wzizgg2x792kSr/WNLJtV2FT6Ko6xDSZaEH98k=; b=kSwR+jfLLZeNS8jA/ySV+2UZufbhowIOsuN3LF9hn1nHTHJO6L+9ZhZwxQfXhgFL2H eRfC97E8S55BJDAugpXX5teaMIgya1cxUNtic9WT97cKSwWjuSfw3dfZ4YL2GGy0EpoK AXxOn9DQ3Nj/zN7JH+NCYGH5+XV5hYvgc7auQ= Received: by 10.229.118.10 with SMTP id t10mr1019069qcq.41.1312484896254; Thu, 04 Aug 2011 12:08:16 -0700 (PDT) Received: from [192.168.16.3] (r186-51-165-171.static.adinet.com.uy [186.51.165.171]) by mx.google.com with ESMTPS id w12sm1547301qct.24.2011.08.04.12.08.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 12:08:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Arturo Servin In-Reply-To: <4E387674.5000000@gmail.com> Date: Thu, 4 Aug 2011 16:08:09 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4F75E001-06F8-4A90-B5B8-2A77DD306A58@gmail.com> References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> To: opsawg@ietf.org X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 08 Aug 2011 01:32:43 -0700 Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:08:03 -0000 Not in favour, not against. Only one comment. On 2 Aug 2011, at 19:13, Brian E Carpenter wrote: > I have concluded that it is inappropriate for the IETF to endorse > this hack. That isn't intended to be derogatory - there are many = aspects > of running code that depend on hacks. But the fact is that this is a = hack, > for reasons that have been discussed many times and that I won't > repeat here. I know that some aspects of RFC 6269 are contested, but > it does give the arguments. >=20 > I've also reviewed draft-bdgks-arin-shared-transition-space in = reaching > this conclusion. I am not happy that ARIN is going the way it = apparently is, > but that is my own problem. However, I don't support draft-bdgks's = call for > "consensus between the IETF and RIR communities" on this issue. It = isn't > necessary. There is no such thing as "RIR communities" consensus. ARIN !=3D = "RIR communities". Last time that I checked it was only one RIR supporting this = draft at community level. I encourage authors to change the text = accordingly. >=20 > At the very minimum, if draft-weil is to proceed, it should describe = the > phase-out plan for the proposed prefix (i.e. the phase-out plan for = CGN > deployment). One approach to that is documented in RFC 6264. >=20 > It is strange that draft-weil doesn't reference RFC 6319 and RFC 6269. >=20 > Regards > Brian Carpenter >=20 >=20 Regards, -as >=20 >=20 > On 2011-08-03 02:56, Scott O. Bradner wrote: >> this starts a WGLC on = draft-weil-shared-transition-space-request-03.txt >>=20 >> comments to the list by Aug 16 please >>=20 >> Scott >>=20 >> --- >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >> Title : IANA Reserved IPv4 Prefix for Shared = Transition Space >> Author(s) : Jason Weil >> Victor Kuarsingh >> Chris Donley >> Telstra Corp >> Marla Azinger >> Filename : = draft-weil-shared-transition-space-request-03.txt >> Pages : 12 >> Date : 2011-08-02 >>=20 >> This document requests a reserved IANA IPv4 address allocation as >> Shared Transition Space to support the deployment of IPv4 address >> sharing technologies post IPv4 exhaustion >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-req= uest-03.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-requ= est-03.txt >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >>=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From sagriffith@gci.com Thu Aug 4 13:48:14 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9142221F8663 for ; Thu, 4 Aug 2011 13:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIJbycU3hg7w for ; Thu, 4 Aug 2011 13:48:14 -0700 (PDT) Received: from mailgw2.gci.com (mailgw2.gci.com [209.165.141.87]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1AE21F8661 for ; Thu, 4 Aug 2011 13:48:10 -0700 (PDT) Received: from dtn1cas01.gci.com (10.100.4.60) by mailgw2.gci.com (172.19.0.32) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 4 Aug 2011 12:48:16 -0800 Received: from fnb1mbx01.gci.com ([10.100.230.59]) by dtn1cas01.gci.com ([10.100.4.60]) with mapi; Thu, 4 Aug 2011 12:48:25 -0800 From: Scott A Griffith To: "OPSAWG@ietf.org" Date: Thu, 4 Aug 2011 12:48:24 -0800 Thread-Topic: draft-wiel Thread-Index: AcxS59qlpaX8r6HvQPGmOPSA5cASuA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA6045981CEC1sagriffithgcicom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= X-Mailman-Approved-At: Mon, 08 Aug 2011 01:32:43 -0700 Subject: [OPSAWG] draft-wiel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 20:48:14 -0000 --_000_CA6045981CEC1sagriffithgcicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the draft-wiel proposal for a /10 shared transition space. Thanks Scott Griffith GCI Product Manager 9078686717 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-requ= est-03.txt --_000_CA6045981CEC1sagriffithgcicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support the draft-wiel prop= osal for a /10 shared transition space.

Thanks

Scott Griffith
GCI Product Manager
9078686717


--_000_CA6045981CEC1sagriffithgcicom_-- From wwwrun@rfc-editor.org Mon Aug 8 12:23:12 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A9821F8A51; Mon, 8 Aug 2011 12:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6qqj81kcHes; Mon, 8 Aug 2011 12:23:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC5D21F8876; Mon, 8 Aug 2011 12:23:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4741998C546; Mon, 8 Aug 2011 12:13:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110808191302.4741998C546@rfc-editor.org> Date: Mon, 8 Aug 2011 12:13:02 -0700 (PDT) Cc: opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 6340 on Textual Conventions for the Representation of Floating-Point Numbers X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 19:23:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6340 Title: Textual Conventions for the Representation of Floating-Point Numbers Author: R. Presuhn Status: Standards Track Stream: IETF Date: August 2011 Mailbox: randy_presuhn@mindspring.com Pages: 7 Characters: 13811 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsawg-mib-floats-02.txt URL: http://www.rfc-editor.org/rfc/rfc6340.txt This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. [STANDARDS-TRACK] This document is a product of the Operations and Management Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ccie15672@yahoo.com Tue Aug 9 04:50:09 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B4921F8AFD for ; Tue, 9 Aug 2011 04:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvYAPnBs06SV for ; Tue, 9 Aug 2011 04:50:09 -0700 (PDT) Received: from nm16-vm0.bullet.mail.bf1.yahoo.com (nm16-vm0.bullet.mail.bf1.yahoo.com [98.139.212.253]) by ietfa.amsl.com (Postfix) with SMTP id 8B6CC21F8AFC for ; Tue, 9 Aug 2011 04:50:04 -0700 (PDT) Received: from [98.139.212.151] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 09 Aug 2011 11:50:33 -0000 Received: from [98.139.212.223] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 09 Aug 2011 11:21:16 -0000 Received: from [127.0.0.1] by omp1032.mail.bf1.yahoo.com with NNFMP; 09 Aug 2011 11:11:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 729091.4372.bm@omp1032.mail.bf1.yahoo.com Received: (qmail 77689 invoked by uid 60001); 9 Aug 2011 11:11:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312888302; bh=FETdUmgyxAk4di93H+MKhAciLuuvudUL2QmRpI2YAgY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=n+B6xnlAJ/iC67K23uwtgo7LxJBLL5D77NoiToOjmCL4XjJVK3lxldnM3Qan8ry0ZdH7fnyumKYT4RV0SFkQ5d/3ZSEIX0B37VsEu91i3jqZXBWvKGI/Y9xPhSiQTG6n4RileDVOTud+BWpoRvFuFWSlJF4hh3aJFEQdntxlPhU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=M/D9YLZakndFnOPiTQiPIA+Xt1st1sAEE8104diyPo2+acGJL31J+CszUYog+qhyNN8jMXVC2RaASoh+8Eml54hNbm6HLUvpJUy5Zkes4VZqOdFhlvpUK1rVAN1p/Yhvni3sK1n8YrMNSWvcsht+XzKdTsiar2nAtroRld0CVys=; X-YMail-OSG: 8piC6tgVM1nqfqBiec1kVm86P7OMNlYw59RROnwBubuD2Jf wdKMlj8E9SPaVD2nyF0BB6NTEMuFyclxiYJ8zE.uhRe6i21tislE0UTtUnT. TJMLWmClqZVIVcdXbQJS94_3BbCnBZgnpNmpbu0m43Tuc1LGQc2gMNP9BUMw q0zyGr96vKr93sNJ8TleaI4A9o6IckLmePAisxFGx9kLMhAgRvsfjBzYWK_f PU.c4h06iy13ovB2QZQF46X9Qkw3bptU6veQddeFkFkX2xG8DNbwXcEHcLQX 0vY4kuQN9R0lwq8Yr.Y2TKUaF0m8Z3F.v2c.hxOIJGMgLkNDkOT8cOVgJ7yw hnHyKY.51tADpwFkszA_5cfonwyIXiYioJo67XGGaDxZETD2fenwB9nbVCLc 7_D78K_b_zzWijtE4OmSCHAdUaVBb.d1vpNWHAt9gYlATrlFustkljH_q7wL iXmmcXmmrD1ZFiWTV0geVC8PAayegR6EYpKXC8IEFMdSa8oxbXmEAJbO..mI 6aoUazyA_ULJZwZE9l_PrbtX7h1pkpDc- Received: from [76.194.43.66] by web161820.mail.bf1.yahoo.com via HTTP; Tue, 09 Aug 2011 04:11:42 PDT X-Mailer: YahooMailWebService/0.8.113.313619 Message-ID: <1312888302.64438.YahooMailNeo@web161820.mail.bf1.yahoo.com> Date: Tue, 9 Aug 2011 04:11:42 -0700 (PDT) From: Derick Winkworth To: "opsawg@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-684583658-800549402-1312888302=:64438" Subject: [OPSAWG] Minutes from IETF 81... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Derick Winkworth List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 11:50:09 -0000 ---684583658-800549402-1312888302=:64438 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Can anyone share the minutes/notes from any of the Data Center discussions = that occurred this past meeting? =A0Specifically VDCS, but any of DC relate= d conversations would be a bonus :-)=0A=0ADerick Winkworth=0ACCIE #15672, J= NCIE #721=0Ahttp://blinking-network.blogspot.com=0A ---684583658-800549402-1312888302=:64438 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Can = anyone share the minutes/notes from any of the Data Center discussions that= occurred this past meeting?  Specifically VDCS, but any of DC related= conversations would be a bonus :-)

Derick Winkwor= th
CCIE #15672, JNCIE #721
---684583658-800549402-1312888302=:64438-- From prvs=5202b98184=tina.morris@mybrighthouse.com Tue Aug 9 09:31:00 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951C321F8CB0 for ; Tue, 9 Aug 2011 09:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60gVbcfAjIGk for ; Tue, 9 Aug 2011 09:31:00 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX2.mybrighthouse.com [209.16.122.104]) by ietfa.amsl.com (Postfix) with ESMTP id E4C5621F8CDF for ; Tue, 9 Aug 2011 09:30:59 -0700 (PDT) Received: from pps.filterd (mx2 [127.0.0.1]) by mx2.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p79G3UCB032640 for ; Tue, 9 Aug 2011 12:31:28 -0400 Received: from tbstpcas02.corp.local ([10.226.201.192]) by mx2.mybrighthouse.com with ESMTP id y37tdg6t9-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 09 Aug 2011 12:31:28 -0400 Received: from CNEMAIL.corp.local ([10.225.1.130]) by tbstpcas02.corp.local ([10.226.201.192]) with mapi; Tue, 9 Aug 2011 12:31:27 -0400 From: "Morris, Tina L." To: "'opsawg@ietf.org'" Date: Tue, 9 Aug 2011 12:31:27 -0400 Thread-Topic: Re: [OPSAWG] WGLC on shared transition space Thread-Index: AcxWsck5dXk1Df3XR1+7Hi61Q/mLLg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA5611D0604E984E8EB9C62380032D707B60CAF35ACNEMAILcorplo_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=1 bulkscore=1 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1108090145 Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:32:14 -0000 --_000_CA5611D0604E984E8EB9C62380032D707B60CAF35ACNEMAILcorplo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in support of this draft 100%, as previously stated this will in no wa= y diminish our efforts to move to IPv6, however it does provide the extra I= P space required to fully implement CGN which will be required during the I= Pv4/IPv6 transition phase. This will help us manage IPv4 exhaustion, and c= ontinue to provide services in a dual stack environment. Without this policy and the space it provides, it seems clear that some wi= ll develop an internal solution using bogon space which could be more probl= ematic in the long run for everyone. Tina Morris ________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. --_000_CA5611D0604E984E8EB9C62380032D707B60CAF35ACNEMAILcorplo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in support of this draft 100%, as previously st= ated this will in no way diminish our efforts to move to IPv6, however it d= oes provide the extra IP space required to fully implement CGN which will b= e required during the IPv4/IPv6 transition phase.  This will help us manage IPv4 exhaustion, and continue to pro= vide services in a dual stack environment. 

 

Without this  policy and the space it provides,= it seems clear that some will develop an internal solution using bogon spa= ce which could be more problematic in the long run for everyone.=

 

Tina Morris

 


CONFIDENTIALITY NOTICE: This= e-mail may contain information that is privileged, confidential or otherwi= se protected from disclosure. If you are not the intended recipient of this= e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.
 --_000_CA5611D0604E984E8EB9C62380032D707B60CAF35ACNEMAILcorplo_-- From lee@asgard.org Tue Aug 9 10:18:59 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2D721F8CD6 for ; Tue, 9 Aug 2011 10:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on6XyFIpnZpt for ; Tue, 9 Aug 2011 10:18:58 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id D232021F8CC4 for ; Tue, 9 Aug 2011 10:18:56 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p79HJPlP004546 for ; Tue, 9 Aug 2011 13:19:25 -0400 Authentication-Results: cm-omr8 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [66.198.208.13] ([66.198.208.13:1415] helo=HDC00027112) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CF/3E-23389-A1C614E4; Tue, 09 Aug 2011 13:19:25 -0400 From: "Lee Howard" To: "Morris, Tina\(Brighthouse\)" , References: In-Reply-To: Date: Tue, 9 Aug 2011 13:19:13 -0400 Message-ID: <000601cc56b8$7a6a9bc0$6f3fd340$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxWsck5dXk1Df3XR1+7Hi61Q/mLLgABb9sw Content-Language: en-us Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 17:18:59 -0000 I've stated my support several times, but to be on the record: draft-weil-opsawg-provider-address-space is necessary, and accurately describes what needs to happen. The use case is not to bail out providers. Even if I deploy IPv6 to = 100% of my users, they still have home electronics that don't speak IPv6, and = need to connect to endpoints that don't speak IPv6. =20 Lee From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf = Of Morris, Tina L. Sent: Tuesday, August 09, 2011 12:31 PM To: 'opsawg@ietf.org' Subject: Re: [OPSAWG] WGLC on shared transition space I am in support of this draft 100%, as previously stated this will in no = way diminish our efforts to move to IPv6, however it does provide the extra = IP space required to fully implement CGN which will be required during the IPv4/IPv6 transition phase.=A0 This will help us manage IPv4 exhaustion, = and continue to provide services in a dual stack environment.=A0=20 Without this =A0policy and the space it provides, it seems clear that = some will develop an internal solution using bogon space which could be more problematic in the long run for everyone. Tina Morris ________________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you = are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy = it. From ning.so@verizon.com Wed Aug 10 07:35:06 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8BF21F8AAC for ; Wed, 10 Aug 2011 07:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.704 X-Spam-Level: X-Spam-Status: No, score=-3.704 tagged_above=-999 required=5 tests=[AWL=0.894, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWciBpLMkDgV for ; Wed, 10 Aug 2011 07:35:04 -0700 (PDT) Received: from fldsmtpe04.verizon.com (fldsmtpe04.verizon.com [140.108.26.143]) by ietfa.amsl.com (Postfix) with ESMTP id C63F121F8A4F for ; Wed, 10 Aug 2011 07:34:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe04.verizon.com with ESMTP; 10 Aug 2011 14:35:20 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.67,350,1309737600"; d="scan'208,217";a="112117262" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 10 Aug 2011 14:35:20 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.38]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Wed, 10 Aug 2011 10:35:19 -0400 To: "opsawg@ietf.org" Date: Wed, 10 Aug 2011 10:35:18 -0400 Thread-Topic: [OPSAWG] Minutes from IETF 81... Thread-Index: AcxWipIMMihBduoxQ3+6jScOgUM9wQA37+Pg Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC0813C4270@FHDP1LUMXC7V41.us.one.verizon.com> References: <1312888302.64438.YahooMailNeo@web161820.mail.bf1.yahoo.com> In-Reply-To: <1312888302.64438.YahooMailNeo@web161820.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6665BC1FEA04AB47B1F75FA641C43BC0813C4270FHDP1LUMXC7V41u_" MIME-Version: 1.0 Subject: Re: [OPSAWG] Minutes from IETF 81... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 14:35:06 -0000 --_000_6665BC1FEA04AB47B1F75FA641C43BC0813C4270FHDP1LUMXC7V41u_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I tried to reply Derick's e-mail to the WG yesterday, but my corporate mail= server has changed, so I have to subscribe to the mail list again using my= new e-mail address. I copied my e-mail below because it was meant to be p= osted to the WG as well. ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------------------------ Derick, I have also been waiting on the meeting minutes before taking any action. = Since you asked, I can give you a quick meeting update on VPN-oriented Data= Center Services (VDCS) based on my recollection. Other drafts' co-authors= can speak for their won category of work. VDCS draft fits into one of the nine categories of Cloud/Data identified at= OSAWG meeting. WG Chair (Scott) asked the question how many people think = this work belongs to IETF, and there are over 20 people raised hands in the= room. This draft does not fit into any one of the existing WG charter. = It is my intention to get some more participants to start working on this. = Please consider this as an open invitation for all to participate if you a= re interested in this work. We can take the discussion to a separate mail = list if it becomes too much for OPSAWG mail list to handle. There are two major tasks related to VDCS work before next IETF meeting. 1. Break up the current draft into a requirement draft and a separate = framework draft, and continue to refine the requirement draft by soliciting= additional requirements from carriers/service providers. 2. Write a clean, focused, and short charter proposal, so that the wor= k in this area can have a home to proceed at IETF. This can be done either= by re-charter an existing WG, or start a new one (going through the proces= s of BoF and son on). I welcome all commons and suggestions. Best regards, Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Derick Winkworth Sent: Tuesday, August 09, 2011 6:12 AM To: opsawg@ietf.org Subject: [OPSAWG] Minutes from IETF 81... Can anyone share the minutes/notes from any of the Data Center discussions = that occurred this past meeting? Specifically VDCS, but any of DC related = conversations would be a bonus :-) Derick Winkworth CCIE #15672, JNCIE #721 http://blinking-network.blogspot.com --_000_6665BC1FEA04AB47B1F75FA641C43BC0813C4270FHDP1LUMXC7V41u_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,=

 

I tried to reply Derick’s e-mail to the WG = yesterday, but my corporate mail server has changed, so I have to subscribe= to the mail list again using my new e-mail address.  I copied my e-ma= il below because it was meant to be posted to the WG as well.

 

----------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -----------------------------------------------

 

Derick,=

 = ;

I have also been waiting on the meeting= minutes before taking any action.  Since you asked, I can give you a = quick meeting update on VPN-oriented Data Center Services (VDCS) based on m= y recollection.  Other drafts’ co-authors can speak for their wo= n category of work.    

&n= bsp;

VDCS draft fits into one of the nine c= ategories of Cloud/Data identified at OSAWG meeting.  WG Chair (Scott)= asked the question how many people think this work belongs to IETF, and th= ere are over 20 people raised hands in the room.  This draft does not = fit into any one of the existing WG charter.   It is my intention= to get some more participants to start working on this.  Please consi= der this as an open invitation for all to participate if you are interested= in this work.  We can take the discussion to a separate mail list if = it becomes too much for OPSAWG mail list to handle. 

 

There are two ma= jor tasks related to VDCS work before next IETF meeting.

 

1.      Break up the current draft into a requirement draft and a separate fr= amework draft, and continue to refine the requirement draft by soliciting a= dditional requirements from carriers/service providers.

2.&nb= sp;     Write a clean, focused, and short c= harter proposal, so that the work in this area can have a home to proceed a= t IETF.  This can be done either by re-charter an existing WG, or star= t a new one (going through the process of BoF and son on).

 

I welcome all co= mmons and suggestions.=

 

 

B= est regards,

 

Ning So

Verizon Corporate Technolo= gy

(office) 972-729-7905

(Cell) 972-955-09= 14

 

&nb= sp;

From: opsawg-bounces@i= etf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Derick Winkwor= th
Sent: Tuesday, August 09, 2011 6:12 AM
To: opsawg@ie= tf.org
Subject: [OPSAWG] Minutes from IETF 81...

 

Can anyone share the minutes/notes fr= om any of the Data Center discussions that occurred this past meeting? &nbs= p;Specifically VDCS, but any of DC related conversations would be a bonus := -)

 

Derick Winkworth

CCIE #15672, JNCIE #721

=
= --_000_6665BC1FEA04AB47B1F75FA641C43BC0813C4270FHDP1LUMXC7V41u_-- From BCheck@NCTA.com Wed Aug 10 11:49:33 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37A221F8B0F for ; Wed, 10 Aug 2011 11:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZGEkUFuUpo0 for ; Wed, 10 Aug 2011 11:49:32 -0700 (PDT) Received: from mail-3.ncta.com (mail-3.ncta.com [209.23.210.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBE521F8AB8 for ; Wed, 10 Aug 2011 11:49:32 -0700 (PDT) Received: from MAILSTORE-A.ncta.com ([::1]) by Mailhubcas.ncta.com ([::1]) with mapi id 14.01.0270.001; Wed, 10 Aug 2011 14:50:04 -0400 From: William Check To: "opsawg@ietf.org" Thread-Topic: Re: [OPSAWG] WGLC on shared transition space Thread-Index: AcxXjk+akPwxd+1jSDmhVRblUXmDQg== Date: Wed, 10 Aug 2011 18:50:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.101.199] Content-Type: multipart/alternative; boundary="_000_FB0F18EA15458E44A955E8AAE17AEDD60B45B1MAILSTOREAnctacom_" MIME-Version: 1.0 Subject: Re: [OPSAWG] WGLC on shared transition space X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 18:49:33 -0000 --_000_FB0F18EA15458E44A955E8AAE17AEDD60B45B1MAILSTOREAnctacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I completely support this proposal. Will be essential for both large and s= mall operators. .... Bill Check --_000_FB0F18EA15458E44A955E8AAE17AEDD60B45B1MAILSTOREAnctacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I completely support this proposal.  Will be es= sential for both large and small operators.

 

    …. Bill Check

 

--_000_FB0F18EA15458E44A955E8AAE17AEDD60B45B1MAILSTOREAnctacom_-- From ning.so@verizon.com Tue Aug 9 08:48:29 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D8F21F876A for ; Tue, 9 Aug 2011 08:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt-eVhuGWdns for ; Tue, 9 Aug 2011 08:48:28 -0700 (PDT) Received: from fldsmtpe04.verizon.com (fldsmtpe04.verizon.com [140.108.26.143]) by ietfa.amsl.com (Postfix) with ESMTP id 05E9821F875C for ; Tue, 9 Aug 2011 08:48:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe04.verizon.com with ESMTP; 09 Aug 2011 15:48:56 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208,217";a="111415763" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 09 Aug 2011 15:48:56 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.38]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Tue, 9 Aug 2011 11:48:55 -0400 To: Derick Winkworth , "opsawg@ietf.org" Date: Tue, 9 Aug 2011 11:48:54 -0400 Thread-Topic: [OPSAWG] Minutes from IETF 81... Thread-Index: AcxWipIMMihBduoxQ3+6jScOgUM9wQAHpQhA Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC0811F897B@FHDP1LUMXC7V41.us.one.verizon.com> References: <1312888302.64438.YahooMailNeo@web161820.mail.bf1.yahoo.com> In-Reply-To: <1312888302.64438.YahooMailNeo@web161820.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6665BC1FEA04AB47B1F75FA641C43BC0811F897BFHDP1LUMXC7V41u_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 11 Aug 2011 05:02:47 -0700 Subject: Re: [OPSAWG] Minutes from IETF 81... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 15:50:00 -0000 --_000_6665BC1FEA04AB47B1F75FA641C43BC0811F897BFHDP1LUMXC7V41u_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Derick, I have also been waiting on the meeting minutes before taking any action. = Since you asked, I can give you a quick meeting update on VPN-oriented Data= Center Services (VDCS) based on my recollection. Other drafts' co-authors= can speak for their won category of work. VDCS draft fits into one of the nine categories of Cloud/Data identified at= OSAWG meeting. WG Chair (Scott) asked the question how many people think = this work belongs to IETF, and there are over 20 people raised hands in the= room. This draft does not fit into any one of the existing WG charter. = It is my intention to get some more participants to start working on this. = Please consider this as an open invitation for all to participate if you a= re interested in this work. We can take the discussion to a separate mail = list if it becomes too much for OPSAWG mail list to handle. There are two major tasks related to VDCS work before next IETF meeting. 1. Break up the current draft into a requirement draft and a separate = framework draft, and continue to refine the requirement draft by soliciting= additional requirements from carriers/service providers. 2. Write a clean, focused, and short charter proposal, so that the wor= k in this area can have a home to proceed at IETF. This can be done either= by re-charter an existing WG, or start a new one (going through the proces= s of BoF and son on). I welcome all commons and suggestions. Best regards, Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Derick Winkworth Sent: Tuesday, August 09, 2011 6:12 AM To: opsawg@ietf.org Subject: [OPSAWG] Minutes from IETF 81... Can anyone share the minutes/notes from any of the Data Center discussions = that occurred this past meeting? Specifically VDCS, but any of DC related = conversations would be a bonus :-) Derick Winkworth CCIE #15672, JNCIE #721 http://blinking-network.blogspot.com --_000_6665BC1FEA04AB47B1F75FA641C43BC0811F897BFHDP1LUMXC7V41u_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Derick,

 

I have also been waiting on the meeting minute= s before taking any action.  Since you asked, I can give you a quick m= eeting update on VPN-oriented Data Center Services (VDCS) based on my recol= lection.  Other drafts’ co-authors can speak for their won categ= ory of work.    

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

VDCS draft fi= ts into one of the nine categories of Cloud/Data identified at OSAWG meetin= g.  WG Chair (Scott) asked the question how many people think this wor= k belongs to IETF, and there are over 20 people raised hands in the room.&n= bsp; This draft does not fit into any one of the existing WG charter. =  It is my intention to get some more participants to start working on= this.  Please consider this as an open invitation for all to particip= ate if you are interested in this work.  We can take the discussion to= a separate mail list if it becomes too much for OPSAWG mail list to handle= . 

 =

There are two major tasks related to= VDCS work before next IETF meeting.

 

1.Brea= k up the current draft into a requirement draft and a separate framework dr= aft, and continue to refine the requirement draft by soliciting additional = requirements from carriers/service providers.

2.      = Write a clean, focused, and short charter proposal,= so that the work in this area can have a home to proceed at IETF.  Th= is can be done either by re-charter an existing WG, or start a new one (goi= ng through the process of BoF and son on).

 

I = welcome all commons and suggestions.

 

&nb= sp;

Best regards,

 

Ning So

=

Verizon Corporate Technology

(office) 972-729-7905

(Cell) 972-955-0914

 <= /span>

 

From: opsawg-bounces@ietf.org [mailto:opsawg-= bounces@ietf.org] On Behalf Of Derick Winkworth
Sent: Tues= day, August 09, 2011 6:12 AM
To: opsawg@ietf.org
Subject: [OPSAWG] Minutes from IETF 81...

 

 

Derick Wink= worth

CCIE #15672, JNCIE #721

=
= --_000_6665BC1FEA04AB47B1F75FA641C43BC0811F897BFHDP1LUMXC7V41u_-- From ning.so@verizon.com Tue Aug 9 11:41:26 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF7121F8C78 for ; Tue, 9 Aug 2011 11:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6iod8GU4k9y for ; Tue, 9 Aug 2011 11:41:26 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 623B221F8C75 for ; Tue, 9 Aug 2011 11:41:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe03.verizon.com with ESMTP; 09 Aug 2011 18:41:55 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208,217";a="111546326" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 09 Aug 2011 18:41:55 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.38]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Tue, 9 Aug 2011 14:41:55 -0400 To: "opsawg@ietf.org" Date: Tue, 9 Aug 2011 14:41:54 -0400 Thread-Topic: subscribe Thread-Index: AcxWxAH3WNHQMGSqT6aWZJyan5HySA== Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC0811F8AD5@FHDP1LUMXC7V41.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6665BC1FEA04AB47B1F75FA641C43BC0811F8AD5FHDP1LUMXC7V41u_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 11 Aug 2011 05:02:47 -0700 Subject: [OPSAWG] subscribe X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 18:41:27 -0000 --_000_6665BC1FEA04AB47B1F75FA641C43BC0811F8AD5FHDP1LUMXC7V41u_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Best regards, Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 --_000_6665BC1FEA04AB47B1F75FA641C43BC0811F8AD5FHDP1LUMXC7V41u_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

 <= o:p>

Best regards,

 

Ning So

Verizon Corporate Technology

(office= ) 972-729-7905

(Cell) 972-955-0914<= o:p>

 

 

= --_000_6665BC1FEA04AB47B1F75FA641C43BC0811F8AD5FHDP1LUMXC7V41u_-- From wwwrun@ietfa.amsl.com Wed Aug 10 14:22:25 2011 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 4803721F8715; Wed, 10 Aug 2011 14:22:25 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110810212225.4803721F8715@ietfa.amsl.com> Date: Wed, 10 Aug 2011 14:22:25 -0700 (PDT) X-Mailman-Approved-At: Thu, 11 Aug 2011 05:02:47 -0700 Cc: opsawg@ietf.org, sami@ietf.org Subject: [OPSAWG] New Non-WG Mailing List: sami -- State Migration X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 21:22:25 -0000 A new IETF non-working group email list has been created. List address: sami@ietf.org Archive: http://www.ietf.org/mail-archive/web/sami/ To subscribe: https://www.ietf.org/mailman/listinfo/sami (Subject to List Administrator Approval) Purpose: To facilitate Virtual Machine(VM) migration without disruption to running applications and security, service state associated with the specific migrating VM needs to be migrated too. This mail list is used for discussions on use cases, scope, and potential standard works. For additional information, please contact the list administrators. From sob@harvard.edu Fri Aug 12 05:14:20 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6968B21F8747 for ; Fri, 12 Aug 2011 05:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.981 X-Spam-Level: X-Spam-Status: No, score=-99.981 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArmcmamHc5Vn for ; Fri, 12 Aug 2011 05:14:19 -0700 (PDT) Received: from sobair.sobco.com (173-166-5-69-newengland.hfc.comcastbusiness.net [173.166.5.69]) by ietfa.amsl.com (Postfix) with ESMTP id D469E21F86C0 for ; Fri, 12 Aug 2011 05:14:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobair.sobco.com (Postfix) with ESMTP id BBD27B1DD7 for ; Fri, 12 Aug 2011 08:15:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobair.sobco.com ([127.0.0.1]) by localhost (cfc-air.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uR+UsUoj-q5e for ; Fri, 12 Aug 2011 08:15:07 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by sobair.sobco.com (Postfix) with ESMTPS id C8650B1DBE for ; Fri, 12 Aug 2011 08:15:07 -0400 (EDT) From: Scott O Bradner Content-Type: multipart/alternative; boundary="Apple-Mail=_99D023CE-4AE3-4273-804F-62A977822E20" Date: Fri, 12 Aug 2011 08:15:06 -0400 Message-Id: <9EC04C16-684B-4210-971D-EA6623DD33FB@harvard.edu> To: opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [OPSAWG] ietf 81 minutes X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 12:14:20 -0000 --Apple-Mail=_99D023CE-4AE3-4273-804F-62A977822E20 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii a first draft of the opsawg minutes have been posted http://www.ietf.org/proceedings/81/minutes/opsawg.txt Scott --Apple-Mail=_99D023CE-4AE3-4273-804F-62A977822E20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii a = first draft of the opsawg minutes have been posted


Sc= ott





= --Apple-Mail=_99D023CE-4AE3-4273-804F-62A977822E20-- From ning.so@verizon.com Fri Aug 12 07:56:40 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1828421F88A5 for ; Fri, 12 Aug 2011 07:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tt5ir8bgTJiF for ; Fri, 12 Aug 2011 07:56:38 -0700 (PDT) Received: from fldsmtpe04.verizon.com (fldsmtpe04.verizon.com [140.108.26.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB5021F88DC for ; Fri, 12 Aug 2011 07:56:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe04.verizon.com with ESMTP; 12 Aug 2011 14:57:10 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.67,362,1309737600"; d="scan'208,217";a="113537149" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi01.verizon.com with ESMTP; 12 Aug 2011 14:57:01 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.38]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Fri, 12 Aug 2011 10:57:01 -0400 To: Scott O Bradner , "opsawg@ietf.org" Date: Fri, 12 Aug 2011 10:56:59 -0400 Thread-Topic: [OPSAWG] ietf 81 minutes Thread-Index: AcxY6XdNSHf/Ci2SQeOZa5KoNCi0KQAFFPow Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC0813C4C05@FHDP1LUMXC7V41.us.one.verizon.com> References: <9EC04C16-684B-4210-971D-EA6623DD33FB@harvard.edu> In-Reply-To: <9EC04C16-684B-4210-971D-EA6623DD33FB@harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6665BC1FEA04AB47B1F75FA641C43BC0813C4C05FHDP1LUMXC7V41u_" MIME-Version: 1.0 Subject: Re: [OPSAWG] ietf 81 minutes X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 14:56:40 -0000 --_000_6665BC1FEA04AB47B1F75FA641C43BC0813C4C05FHDP1LUMXC7V41u_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Based on the meeting minutes and whatever the memories I have left from the= meeting, the most important thing to progress the data center/cloud work i= n IETF is to clearly define what work belongs to IETF. Multiple categories= defined in the last OPSAWG meeting had good supporting, meaning many peopl= e in the meeting think those work belong in IETF. The challenge is to put = it together in a way to either fit it into an existing WG, or start the pro= cess for a new WG. My primary focus will be on VPN-for DC/Cloud category. The process has alr= eady begun to narrow down the IETF scope in that area, and break the existi= ng draft into separate requirement and framework drafts. Parallel work in = that area has also begun in other SDOs for non-IETF work. I would like to = solicit additional interested parties to work with me (and other co-authors= on the draft) on this. I highly recommend other drafts' co-authors to do = the same thing for the category that your draft belongs to. Otherwise it w= ill be the same situation again for the next IETF meeting. Best regards, Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Scott O Bradner Sent: Friday, August 12, 2011 7:15 AM To: opsawg@ietf.org Subject: [OPSAWG] ietf 81 minutes a first draft of the opsawg minutes have been posted http://www.ietf.org/proceedings/81/minutes/opsawg.txt Scott --_000_6665BC1FEA04AB47B1F75FA641C43BC0813C4C05FHDP1LUMXC7V41u_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,=

 

Based on the meeting minutes and whatever the mem= ories I have left from the meeting, the most important thing to progress th= e data center/cloud work in IETF is to clearly define what work belongs to = IETF.  Multiple categories defined in the last OPSAWG meeting had good= supporting, meaning many people in the meeting think those work belong in = IETF.  The challenge is to put it together in a way to either fit it i= nto an existing WG, or start the process for a new WG. 

 

My primary focus will be on VPN-for DC/Cloud category.&nbs= p; The process has already begun to narrow down the IETF scope in that area= , and break the existing draft into separate requirement and framework draf= ts.  Parallel work in that area has also begun in other SDOs for non-I= ETF work.  I would like to solicit additional interested parties to wo= rk with me (and other co-authors on the draft) on this.  I highly reco= mmend other drafts’ co-authors to do the same thing for the category = that your draft belongs to.  Otherwise it will be the same situation a= gain for the next IETF meeting.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

 

Best regards,

 

Ning So

Verizon Corporate Technology

(office) 972-729-7905=

(Cell) 972-955-0914<= /span>

 

 

From: opsawg-bounces@ietf.org [mailto:opsawg-bounc= es@ietf.org] On Behalf Of Scott O Bradner
Sent: Friday, Au= gust 12, 2011 7:15 AM
To: opsawg@ietf.org
Subject: [OPS= AWG] ietf 81 minutes

=  

a first draft of the opsawg minut= es have been posted

 

 =

Scott

 

 



 =

= --_000_6665BC1FEA04AB47B1F75FA641C43BC0813C4C05FHDP1LUMXC7V41u_-- From tim.pittman@bt.com Tue Aug 16 07:17:24 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2492021F8B6E for ; Tue, 16 Aug 2011 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.823 X-Spam-Level: X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95MxAnLR+SiX for ; Tue, 16 Aug 2011 07:17:23 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4476121F8B6C for ; Tue, 16 Aug 2011 07:17:23 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 16 Aug 2011 15:18:09 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.191]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Tue, 16 Aug 2011 15:18:10 +0100 From: To: Content-Class: urn:content-classes:message Date: Tue, 16 Aug 2011 15:18:24 +0100 Thread-Topic: [OPSAWG] draft-weil-shared-transition-space-request-03.txt Thread-Index: Acxb+JwaKqHz6gRbRiiQX87LOTFJJgAJpuRCAAAJJg0= Message-ID: <032D30F3-204F-4797-BB8E-7F601D3F542C@mimectl> References: <6AEE1195-A613-4F4E-9F77-CBC7365F7A68@mimectl> In-Reply-To: <6AEE1195-A613-4F4E-9F77-CBC7365F7A68@mimectl> Accept-Language: en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-GB x-mimectl: Produced By Microsoft Exchange V8.3.105.0 Content-Type: multipart/alternative; boundary="_000_032D30F3204F4797BB8E7F601D3F542Cmimectl_" MIME-Version: 1.0 Subject: [OPSAWG] draft-weil-shared-transition-space-request-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:17:24 -0000 --_000_032D30F3204F4797BB8E7F601D3F542Cmimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BT Retail fully supports the proposal for the assignment of a /10 for ISP s= hared transition use. As an ISP with a few million customers our momentum is well and truly behin= d IPv6 deployment during 2012 and we will use NAT444 to maintain v4 service= from thereon. Our analysis is that the use of RFC1918 space for CGN will g= reatly increase the likelihood of address collision and loss of user servic= e, due to the widespread use of RFC1918 already made in ours and our custom= ers environments. BR/ Tim --_000_032D30F3204F4797BB8E7F601D3F542Cmimectl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

BT Retail fully supports the proposal for the&n= bsp;assignment of a /10 for ISP shared transition&nb= sp;use.
As an ISP with a few million customers our momentum is= well and truly behind IPv6 deployment during 2012 and we will use NAT444 to maintain v4 service from thereon. Ou= r analysis is that the use of RFC1918 spac= e for CGN will greatly increase the likelihood = of address collision and loss of user service, = due to the widespread use of RFC1918 already ma= de in ours and our customers environments.

 

BR/ Tim

 

--_000_032D30F3204F4797BB8E7F601D3F542Cmimectl_-- From tim.pittman@bt.com Tue Aug 16 02:40:02 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAA021F8B17 for ; Tue, 16 Aug 2011 02:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJQXZat5bYIp for ; Tue, 16 Aug 2011 02:40:01 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2084121F8B05 for ; Tue, 16 Aug 2011 02:40:01 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 16 Aug 2011 10:40:47 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.191]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 16 Aug 2011 10:40:47 +0100 From: To: Content-Class: urn:content-classes:message Date: Tue, 16 Aug 2011 10:41:01 +0100 Thread-Topic: [OPSAWG] draft-weil-shared-transition-space-request-03.txt Thread-Index: Acxb+JwaKqHz6gRbRiiQX87LOTFJJg== Message-ID: <6AEE1195-A613-4F4E-9F77-CBC7365F7A68@mimectl> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V8.3.105.0 acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_6AEE1195A6134F4E9F77CBC7365F7A68mimectl_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 16 Aug 2011 10:04:02 -0700 Subject: [OPSAWG] draft-weil-shared-transition-space-request-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 09:43:18 -0000 --_000_6AEE1195A6134F4E9F77CBC7365F7A68mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BT Retail fully supports the proposal for the assignment of a /10 for ISP s= hared transition use. As an ISP with a few million customers our momentum is well and truly behin= d IPv6 deployment during 2012 and we will use NAT444 to maintain v4 service= from thereon. Our analysis is that the use of RFC1918 space for CGN will g= reatly increase the likelihood of address collision and loss of user servic= e, due to the widespread use of RFC1918 already made in ours and our custom= ers environments. BR/ Tim --_000_6AEE1195A6134F4E9F77CBC7365F7A68mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

BT Retail fully supports the proposal for the&n= bsp;assignment of a /10 for ISP shared transition&nb= sp;use.
As an ISP with a few million customers our momentum is= well and truly behind IPv6 deployment during 2012 and we will use NAT444 to maintain v4 service from thereon. Ou= r analysis is that the use of RFC1918 spac= e for CGN will greatly increase the likelihood = of address collision and loss of user service, = due to the widespread use of RFC1918 already ma= de in ours and our customers environments.

 

BR/ Tim

 

--_000_6AEE1195A6134F4E9F77CBC7365F7A68mimectl_-- From tim.pittman@bt.com Tue Aug 16 13:24:36 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2B11E8081 for ; Tue, 16 Aug 2011 13:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.878 X-Spam-Level: X-Spam-Status: No, score=-2.878 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvmfT9tGu-X3 for ; Tue, 16 Aug 2011 13:24:36 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id C957C11E807F for ; Tue, 16 Aug 2011 13:24:35 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 16 Aug 2011 21:25:23 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.191]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 16 Aug 2011 21:25:23 +0100 From: To: Date: Tue, 16 Aug 2011 21:21:20 +0100 Thread-Topic: [OPSAWG] draft-weil-shared-transition-space-request-03.txt Thread-Index: Acxb+JwaKqHz6gRbRiiQX87LOTFJJgAJpuRCAAAJJg0ADKzbdg== Message-ID: <12BF5EA014130B458A4FF2982872616426A4F0C51C@EMV64-UKRD.domain1.systemhost.net> References: <6AEE1195-A613-4F4E-9F77-CBC7365F7A68@mimectl>, <032D30F3-204F-4797-BB8E-7F601D3F542C@mimectl> In-Reply-To: <032D30F3-204F-4797-BB8E-7F601D3F542C@mimectl> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_12BF5EA014130B458A4FF2982872616426A4F0C51CEMV64UKRDdoma_" MIME-Version: 1.0 Subject: [OPSAWG] draft-weil-shared-transition-space-request-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 20:24:36 -0000 --_000_12BF5EA014130B458A4FF2982872616426A4F0C51CEMV64UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I fully support the proposal for the assignment of a /10 for ISP-shared tra= nsition use. BR/ Tim --_000_12BF5EA014130B458A4FF2982872616426A4F0C51CEMV64UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I fully support the proposal for the ass= ignment of a /10 for ISP-shared transition use.

 

BR/ Tim

--_000_12BF5EA014130B458A4FF2982872616426A4F0C51CEMV64UKRDdoma_-- From michaelg@prime-tel.com Wed Aug 17 00:50:47 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D4C21F861A for ; Wed, 17 Aug 2011 00:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nXfFv+3yW2r for ; Wed, 17 Aug 2011 00:50:44 -0700 (PDT) Received: from cezanne.office-net.spidernet.net (cezanne.office-net.spidernet.net [194.154.133.233]) by ietfa.amsl.com (Postfix) with ESMTP id 85C1121F85F2 for ; Wed, 17 Aug 2011 00:50:41 -0700 (PDT) Received: from [10.5.10.157] (10.5.10.157) by cezanne.office-net.spidernet.net (194.154.133.233) with Microsoft SMTP Server id 8.2.255.0; Wed, 17 Aug 2011 10:51:29 +0300 Message-ID: <4E4B73BA.5040007@prime-tel.com> Date: Wed, 17 Aug 2011 10:54:34 +0300 From: Michael Georgiades Organization: Primetel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Thunderbird/3.1.7 MIME-Version: 1.0 To: References: <9EC04C16-684B-4210-971D-EA6623DD33FB@harvard.edu> In-Reply-To: <9EC04C16-684B-4210-971D-EA6623DD33FB@harvard.edu> Content-Type: multipart/alternative; boundary="------------000006090502080500050106" Subject: Re: [OPSAWG] ietf 81 minutes X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 07:50:47 -0000 --------------000006090502080500050106 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Dear Scott and all, Thank you for the minutes and for taking time in the meeting to present the= Inter-Carrier OAM Requirements draft as well. Please see inline for my response to the related minutes: 2 - Inter-Carrier OAM Requirements draft-georgiades-opsawg-intercar-oam-req-00 was presented next by Mike (?) Scott announced that the Speaker will send the slides for uploading soon AIM: To support the operation regional scope of OAM mechanism proposals To differentiate between single carrier and inter-carrier OAM requirements To differentiate inter-carrier requirements derived from inter-operability versus business interworking considerations: Mike: Not exactly "versus" but actually "plus" heterogeneous technology int= er-operation as well as inter-carrier sharing willingness (e.g. privacy, qo= s performance, trust) To define the OAM operational area scope: The draft attempts to list all single carrier single technology requirements identified within IETF, ITU-T, MEF, and IEEE Mike: This will be a good SoA for the draft. Particularly OAM inter-operabi= lity considerations of each technology with other technologies. Also wants to address: network OAM vs service OAM where the latter will be of interest for end to end inter-carrier Inter Carrier OAM requirements addressed so far: Should be supported by MEs that are handled by different operators Some questions and Open Issues from the mailing list How the OAM system can monitor QoS Scott asked how many people had read the draft - 1 Scott asked if the author had talked to any carriers? A. yes, 2 Mike: More operators are concerned about these issues. This is clear from t= he authors' involvement in related European projects where Operators are co= nsidering new ecosystem models which generally tend to emphasise the need of inter-ne= tworking confidence on such issues e.g. remote failure tracking, remote QoS= monitoring. Scott: is there any parallel activity in ITU-T? A. "No." Mike: IEEE 802.1, ITU SG 13, and the MEF have been working in close coopera= tion to develop complimentary standards for multi-domain Ethernet Service O= AM. The approved ITU-T Y.1731 attempted to differentiate the different levels o= f OAM. The MEF is developing MEF Service OAM Requirements & Framework - Phase 1 Technical Specification. The IEEE 802.1 committee is also looking a= t Connectivity Fault Management. These work items and the distinction of OA= M levels between the involved actors is related and of interest. Inter-carrier (prov= ider) is a sub-part of this work. UNI_N to UNI_N Provider ME (Pa1a) assigned MEG Level 4 and Inter-operator M= E (IOa) assigned a MEG Level 0 are both related to inter-carrier OAM issues [see MEF 17- Service OAM Framework and Requirements and Y.1731]. Scott: how many people think it is a interesting work for the WG: A: 6 Scott: Some people think that it is a topic of interest, so Scot will take it to the list. Dan (AD) says there is mild interest only, so let us talk to the list and see what happens. Mike: FYI I will try to address certain issues that where directly sent to = the authors and not on the list. I will also add some more text to the moti= vation behind the draft and its distinction from the other standardisation activities. Cheers, Mike -- Dr Michael Georgiades Telecommunications Research Analyst Primetel PLC The Maritime Center, 141 Omonia Avenue, 3045 Limassol, Cyprus Mobile: +357 95 195295, Office +357 25 867212, Fax: +357 22 102211 Email: michaelg@prime-tel.com Web: www.prime= tel.com.cy On 08/12/2011 03:15 PM, Scott O Bradner wrote: a first draft of the opsawg minutes have been posted http://www.ietf.org/proceedings/81/minutes/opsawg.txt Scott ________________________________ CONFIDENTIALITY NOTICE AND DISCLAIMER This message contains information, which may be confidential and privileged= . Unless you are the intended recipient (or authorized to receive this mess= age for the intended recipient), you may not use, copy, disseminate or disc= lose to anyone the message or any information contained in the message. If = you have received the message in error, please advise the sender by reply e= -mail, and delete the message. PrimeTel Plc --------------000006090502080500050106 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 
Dear Scott and all,
Thank you for the minutes and for taking time in the meeting to presen=
t the Inter-Carrier OAM Requirements draft as well. 
Please see inline for my response to the related minutes:
2 - Inter-Carrier OAM Requirements
	draft-georgiades-opsawg-intercar-oam-req-00
	was presented next by Mike (?)

Scott announced that the Speaker will send the slides for uploading soon
AIM:
To support the operation regional scope of OAM mechanism proposals
To differentiate between single carrier and inter-carrier OAM
requirements
To differentiate inter-carrier requirements derived from
inter-operability versus business interworking considerations:

Mike: Not exactly "versus" but actually "plus" heteroge=
neous technology inter-operation as well as inter-carrier sharing willingne=
ss (e.g. privacy, qos performance, trust)

To define the OAM operational area scope:
The draft attempts to list all single carrier single technology
requirements identified within IETF, ITU-T, MEF, and IEEE

Mike: This will be a good SoA for the draft. Particularly OAM inter-operabi=
lity considerations of each technology with other technologies.=20

Also wants to address: network OAM vs service OAM where the latter will
be of interest for end to end inter-carrier

Inter Carrier OAM requirements addressed so far:
Should be supported by MEs that are handled by different operators
Some questions and Open Issues from the mailing list
How the OAM system can monitor QoS=20
Scott asked how many people had read the draft - 1
Scott asked if the author had talked to any carriers? =20
A. yes, 2

Mike: More operators are concerned about these issues. This is clear from t=
he authors' involvement in related European projects where Operators are co=
nsidering=20
new ecosystem models which generally tend to emphasise the need of inter-ne=
tworking confidence on such issues e.g. remote failure tracking, remote QoS=
 monitoring.  =20

Scott: is there any parallel activity in ITU-T?=20
A. “No.”

Mike: IEEE 802.1, ITU SG 13, and the MEF have been working in close coopera=
tion to develop complimentary standards for multi-domain Ethernet Service O=
AM.=20
The approved ITU-T Y.1731 attempted to differentiate the different levels o=
f OAM. The MEF is developing MEF Servi=
ce OAM Requirements & Framework –=20
Phase 1 Technical Specification. The IEEE 802.1 committee is also lo=
oking at Connectivity Fault Management. These work items and the distinctio=
n of OAM levels
between the involved actors is related and of interest. Inter-carrier (prov=
ider) is a sub-part of this work. =20
UNI_N to UNI_N Provider ME (Pa1a) assigned MEG Level 4 and Inter-operator M=
E (IOa) assigned a MEG Level 0 are both related to inter-carrier OAM issues=
=20
[see MEF 17- Service OAM Framework and Requireme=
nts and Y.1731]. 

Scott: how many people think it is a interesting work for the WG: A: 6
Scott: Some people think that it is a topic of interest, so Scot will
take it to the list.
Dan (AD) says there is mild interest only, so let us talk to the list
and see what happens.

Mike: FYI I will try to address certain issues that where directly sent to =
the authors and not on the list. I will also add some more text to the moti=
vation behind=20
the draft and its distinction from the other standardisation activities.=20

Cheers,

Mike
-- 
Dr Michael Georgiades
Telecommunications Research Analyst
Primetel PLC
The Maritime Center, 141 Omonia Avenue, 3045 Limassol, Cyprus
Mobile: +357 95 195295, Office +357 25 867212, Fax: +357 22 102=
211
Email: michaelg@prime-tel.com Web: www.primetel.com.cy

On 08/12/2011 03:15 PM, Scott O Bradner wrote:
a first draft of the opsawg minutes have been posted


Scott












CONFIDENTIALITY NOTICE AND D=
ISCLAIMER

This message contains information, which may be confidential and privileged=
. Unless you are the intended recipient (or authorized to receive this mess=
age for the intended recipient), you may not use, copy, disseminate or disc=
lose to anyone the message or any
 information contained in the message. If you have received the message in =
error, please advise the sender by reply e-mail, and delete the message.
PrimeTel Plc





--------------000006090502080500050106--

From ietfc@btconnect.com  Wed Aug 17 01:48:34 2011
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119E421F8A23 for ; Wed, 17 Aug 2011 01:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.869
X-Spam-Level: 
X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_05=-1.11]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5rHedAxlilx for ; Wed, 17 Aug 2011 01:48:33 -0700 (PDT)
Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id 060B821F899F for ; Wed, 17 Aug 2011 01:48:32 -0700 (PDT)
Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr08.btconnect.com with SMTP id DYO70175; Wed, 17 Aug 2011 09:49:16 +0100 (BST)
Message-ID: <00c401cc5cb1$ad8bf860$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Brian E Carpenter" , 
References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com>
Date: Wed, 17 Aug 2011 09:45:43 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0303.4E4B808C.0068, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.17.73617:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4E4B8090.01A9,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Subject: Re: [OPSAWG] WGLC on shared transition space
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 08:48:34 -0000

I think that this is a bad idea and one that the IETF should not endorse.  I
suspect that the ISPs will go ahead anyway, in their own way, but that should be
their choice, not as an officially sanctioned approach.

I see Brian asking for a phase-out plan, but I think that this is one of those
uses of technology that, once approved, will be with us for ever, never to be
phased out.

I would rather see the ISPs putting more effort into getting IPv6 in place for
real, eg 464 and not 444.  My ISP, for example, has recently announced an IPv6
trial for 2012, no sign of a production network (I notice that supporters of
this proposal, who of course are on this list as individuals, as we all are,
have e-mail addresses with a domain part for that ISP:-(

Again as Brian said, this should have been thought about years ago; we should be
thinking now about the problems of IPv6 and eliminating them.

Tom Petch

> On 2011-08-03 02:56, Scott O. Bradner wrote:
> > this starts a WGLC on draft-weil-shared-transition-space-request-03.txt
> >
> > comments to the list by Aug 16 please
> >
> > Scott
> >
> > ---
> > A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> >
> > Title           : IANA Reserved IPv4 Prefix for Shared Transition Space
> > Author(s)       : Jason Weil
> >                          Victor Kuarsingh
> >                          Chris Donley
> >                          Telstra Corp
> >                          Marla Azinger
> > Filename        : draft-weil-shared-transition-space-request-03.txt
> > Pages           : 12
> > Date            : 2011-08-02
> >
> >   This document requests a reserved IANA IPv4 address allocation as
> >   Shared Transition Space to support the deployment of IPv4 address
> >   sharing technologies post IPv4 exhaustion
> >
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-0
3.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> >
ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-request-03
.txt
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> >
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


From owen@delong.com  Wed Aug 17 02:40:41 2011
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3317D21F8AFB for ; Wed, 17 Aug 2011 02:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.708
X-Spam-Level: 
X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJfMY8OJsu60 for ; Wed, 17 Aug 2011 02:40:40 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B0CF121F8AF9 for ; Wed, 17 Aug 2011 02:40:39 -0700 (PDT)
Received: from delong-dhcp202.delong.com (delong-dhcp2 [192.159.10.202]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p7H9cfZP024500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Aug 2011 02:38:42 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p7H9cfZP024500
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1313573924; bh=9lP+mWlJYTKMIQ/sVgp6gC7nbTQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=In/WcEAKQQ2MPgI9u6rzc4Ja7l962bagCfRblz5db8DlqFMJb/Lt9CcvI37WdRv/h 7ae0jf1HuvvmhMFLvb4U9FknUA5/opwpd6PjIl10TJDJdAlabRWK0UvE3PSM8dqG1T DqWlUv1fDmCcHYfkKRfdcOKxtj2tkieln08kjI1s=
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/signed; boundary="Apple-Mail=_3A27D883-2504-47E8-A3C5-226A5486E274"; protocol="application/pkcs7-signature"; micalg=sha1
From: Owen DeLong 
X-Priority: 3
In-Reply-To: <00c401cc5cb1$ad8bf860$4001a8c0@gateway.2wire.net>
Date: Wed, 17 Aug 2011 02:38:41 -0700
Message-Id: <7C936C36-1A33-4218-BF98-A23336562E6E@delong.com>
References: <20110802145602.C7987DC4344@newdev.eecs.harvard.edu> <4E387674.5000000@gmail.com> <00c401cc5cb1$ad8bf860$4001a8c0@gateway.2wire.net>
To: "t.petch" 
X-Mailer: Apple Mail (2.1244.3)
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Wed, 17 Aug 2011 02:38:44 -0700 (PDT)
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] WGLC on shared transition space
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 09:40:41 -0000

--Apple-Mail=_3A27D883-2504-47E8-A3C5-226A5486E274
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Tom,

Step out of the ivory tower for a moment and look at the real world.

Anyone who knows me will have a pretty hard time saying that I am not
an IPv6 zealot. My official job title is IPv6 Evangelist and I work for =
Hurricane
Electric. You won't find too many people who do more IPv6 cheerleading
than I do.

However, there's also reality and trying to keep things running and keep
customers happy through the transition process.

Reality=85 No matter how well an ISP does on making IPv6 available to
their customers, the fact that the customer still has a bunch of =
electronics
that need to talk to the internet and won't speak IPv6 means that we =
have
to provide a  way for them to talk to IPv4 for the foreseeable future
no matter how much we wish that wasn't the case.

Keeping things running=85 Since we have to provide some mechanism
for customers to reach the IPv4 internet, we're going to be faced with
some form of multi-layer or multi-protocol NAT that will (in most cases)
require some form of intermediate addressing.

One of the least disruptive approaches available is 444. While there
are some things that can be done with 464, in reality, it has it's =
problems,
too and in most production environments, it's a lot more sensible to run
native 6 and 444 parallel to each other than to try and force everything
through an IPv6 translation (and back).

I'm all for thinking about and eliminating the problems of IPv6. I'd =
love
to see us solve the route scalability problem with some form of feasible
and widely deployable locater/ID split solution.

I'd love to see us make DHCPv6 and SLAAC both fully capable standalone
autoconfiguration protocols so that a site administrator can choose the =
one
that best meets his/her needs.

I'd love to see vendors putting RA Guard into all the WAPs and Switches.

However, this is a real problem with a relatively simple solution that =
makes
sense. The operational community in the ARIN region overwhelmingly
supports this proposal. If I understand correctly, the main objection in =
the
APNIC region was "Not from our address space", but, they generally =
supported
the idea of reserving the block.

As to domain parts=85 I'm a supporter of this proposal and my ISP is
most definitely dual stacked, so, while some supporters may be with
ISPs that don't have production IPv6 networks as yet, you certainly
can't make that claim in my case. Both of my upstream
ISPs (6939 and 8121) are most definitely dual-stack. My network
is most definitely dual stack.

However, even in my fully dual-stack environment (including my
printer), I still have a few devices that are not dual-stack.
	2* yamaha amplifiers
	3* TiVO boxes
	1* Nintendo Wii
	2* Sony Playstations (1@ PS2, PS3)
	1* HD-DVD Player (yeah, I know, but, I still have the discs and =
they still play)
	2* Blu-Ray Players
	1* Livingston Portmaster 2e

Owen

On Aug 17, 2011, at 12:45 AM, t.petch wrote:

> I think that this is a bad idea and one that the IETF should not =
endorse.  I
> suspect that the ISPs will go ahead anyway, in their own way, but that =
should be
> their choice, not as an officially sanctioned approach.
>=20
> I see Brian asking for a phase-out plan, but I think that this is one =
of those
> uses of technology that, once approved, will be with us for ever, =
never to be
> phased out.
>=20
> I would rather see the ISPs putting more effort into getting IPv6 in =
place for
> real, eg 464 and not 444.  My ISP, for example, has recently announced =
an IPv6
> trial for 2012, no sign of a production network (I notice that =
supporters of
> this proposal, who of course are on this list as individuals, as we =
all are,
> have e-mail addresses with a domain part for that ISP:-(
>=20
> Again as Brian said, this should have been thought about years ago; we =
should be
> thinking now about the problems of IPv6 and eliminating them.
>=20
> Tom Petch
>=20
>> On 2011-08-03 02:56, Scott O. Bradner wrote:
>>> this starts a WGLC on =
draft-weil-shared-transition-space-request-03.txt
>>>=20
>>> comments to the list by Aug 16 please
>>>=20
>>> Scott
>>>=20
>>> ---
>>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>>>=20
>>> Title           : IANA Reserved IPv4 Prefix for Shared Transition =
Space
>>> Author(s)       : Jason Weil
>>>                         Victor Kuarsingh
>>>                         Chris Donley
>>>                         Telstra Corp
>>>                         Marla Azinger
>>> Filename        : draft-weil-shared-transition-space-request-03.txt
>>> Pages           : 12
>>> Date            : 2011-08-02
>>>=20
>>>  This document requests a reserved IANA IPv4 address allocation as
>>>  Shared Transition Space to support the deployment of IPv4 address
>>>  sharing technologies post IPv4 exhaustion
>>>=20
>>>=20
>>> A URL for this Internet-Draft is:
>>>=20
> =
http://www.ietf.org/internet-drafts/draft-weil-shared-transition-space-req=
uest-0
> 3.txt
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> This Internet-Draft can be retrieved at:
>>>=20
> =
ftp://ftp.ietf.org/internet-drafts/draft-weil-shared-transition-space-requ=
est-03
> .txt
>>> _______________________________________________
>>> OPSAWG mailing list
>>> OPSAWG@ietf.org
>>> https://www.ietf.org/mailman/listinfo/opsawg
>>>=20
>> _______________________________________________
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
>=20
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


--Apple-Mail=_3A27D883-2504-47E8-A3C5-226A5486E274
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIERDCCBEAw
ggOpoAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTER
MA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoTEURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxE
ZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJ
KoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tMB4XDTA2MTIxNjE2MzcxN1oXDTE2MTIxMzE2MzcxN1ow
fTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzEP
MA0GA1UECxMGUGVyc29uMRQwEgYDVQQDEwtPd2VuIERlTG9uZzEeMBwGCSqGSIb3DQEJARYPb3dl
bkBkZWxvbmcuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7H7JBEUaAy56E6qY
0JoHKfI+6QT7hYjnc1JezeZOA5XxK7QERkx8rdcND47xeNXjw06ZMjfhrcGkxM+1PEatBxC1Aax1
V95fKtw0DkNMKRgH138E6mZhwuWsvcA1bhxJQQc++SumEX5Uyr5dX4jYy2WgmaLKc8TD/N5G+/zb
Rc1sLrznovNvv7daKfDFlufRkPnLpeG0gx/HIFa4csMNYH2rdLt2xUBAt4TSy3fjEbp0HFVRJI4G
QRHbMmb6tBMnT9vpUZrwMHydqHHTiGr2A8PgdQeQLNEknKynVFTjJIXhBUSINhCl2HtQA+TKv+gu
EF9HrIybZSDlhGym0JUgKwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADAdBgNVHQ4EFgQUzaaV8BC8
UhxaWk6IQTpqK9mLnSgwgdMGA1UdIwSByzCByIAU15gTZIxt8E1K2l0KkjrRFpdc5eyhgaykgakw
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tggEA
MBoGA1UdEQQTMBGBD293ZW5AZGVsb25nLmNvbTANBgkqhkiG9w0BAQUFAAOBgQCWRsD48eQfaNKH
K2lohMTD9voszp/GuoWTyi6RckNxW0b0V0gv7ZGH1BUmgq2Jt7SjIis7vTY3FCZUDcR9e7fpBXJL
/euk2pPEBSHbCWAYO+uFeZ17UHz0WtInBB7Yo2EHUrkf4jeJDL7rHOG5YOVQzoV1+vdFkmQvPCPX
zPyYyzGCA7cwggOzAgEBMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcT
CFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMGA1UECxMcRGVMb25nIENl
cnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNvbTEcMBoGCSqGSIb3DQEJ
ARYNY2FAZGVsb25nLmNvbQIBFDAJBgUrDgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MTcwOTM4NDJaMCMGCSqGSIb3DQEJBDEWBBQ6NFwZAnna
DTiCpDFrVxUNGl0ioDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGmMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRowGAYDVQQKExFEZUxvbmcgQ29uc3VsdGluZzElMCMG
A1UECxMcRGVMb25nIENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNY2EuZGVsb25nLmNv
bTEcMBoGCSqGSIb3DQEJARYNY2FAZGVsb25nLmNvbQIBFDCBvwYLKoZIhvcNAQkQAgsxga+ggaww
gaYxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxGjAYBgNVBAoT
EURlTG9uZyBDb25zdWx0aW5nMSUwIwYDVQQLExxEZUxvbmcgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRYwFAYDVQQDEw1jYS5kZWxvbmcuY29tMRwwGgYJKoZIhvcNAQkBFg1jYUBkZWxvbmcuY29tAgEU
MA0GCSqGSIb3DQEBAQUABIIBAG+Bdx29LmmN75fSeeOyaeCJSbToBu//ROkQyX7Mv4ANb9yFMBtp
8k+iBV4cpc91u7b904WNsrqIDk8pC7eUOpTXjPjA1tmiztOI/otkdFHo+1att8yXQNqVZUK57h2V
vUDZVkQwQXdwAE+kwR/We8FeZRltdtQLAMmHUsJfGe4e6O/ZHpYUXc2bwqnE8AG5DSffra5WYP3u
Fb0JMl8pD4/gGVX/wOGvh7Bu8+Yo0vN8M0cQ0mPj9D9N36BH/MoftW6bnnJ0fMT0wM4+BoanHNer
78vQ1S8QRLbSAOhnqDFbLVu7Aa0F2kYZuFfEnziJ0Oiym5TUJUMK6X602KlG74cAAAAAAAA=

--Apple-Mail=_3A27D883-2504-47E8-A3C5-226A5486E274--

From sob@harvard.edu  Wed Aug 17 04:48:59 2011
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5943921F8B30 for ; Wed, 17 Aug 2011 04:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBd8WsIHIc-Z for ; Wed, 17 Aug 2011 04:48:58 -0700 (PDT)
Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id C2FCD21F8B2F for ; Wed, 17 Aug 2011 04:48:58 -0700 (PDT)
Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id AF14CE599CD; Wed, 17 Aug 2011 07:49:46 -0400 (EDT)
To: opsawg@ietf.org
Message-Id: <20110817114946.AF14CE599CD@newdev.eecs.harvard.edu>
Date: Wed, 17 Aug 2011 07:49:46 -0400 (EDT)
From: sob@harvard.edu (Scott O. Bradner)
Subject: [OPSAWG] end of WGLC on transition space
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 11:48:59 -0000

this concludes the opsawg WGLC on shared transition space

There were 45 messages from 22 people on the opsawg mailing list in
response to the WGLC.  Assuming I counted correctly, four of the
posters were opposed to the proposal, 17 in favor and one said he was
not in favor or opposed. 

Based on the mailing list discussion I would conclude that there is
consensus in support of the proposal.  

In addition the proposal was discussed during the opsawg session in
Quebec City.  Seventy nine people signed opsawg blue sheets for that
session and I expect that a number of people present for the
discussion did not sign since the room was standing room only and the
blue sheets did not get to everyone and a number of people left after
the shared transition space discussion.

Most people in room raised a hand when asked if the supported goal of
ID, I did not see any that disagreed but a few people spoke against
the proposal so I may have missed a few hands.


from RFC 2418
   In the case where a consensus which has been reached during a face-
   to-face meeting is being verified on a mailing list the people who
   were in the meeting and expressed agreement must be taken into
   account.  If there were 100 people in a meeting and only a few people 
   on the mailing list disagree with the consensus of the meeting then
   the consensus should be seen as being verified.  Note that enough
   time should be given to the verification process for the mailing list
   readers to understand and consider any objections that may be raised
   on the list.  The normal two week last-call period should be
   sufficient for this.

Thus, based on the combination of the very strong support shown in
the face-to-face meeting and the strong support in response to the
WGLC, I conclude that the WG has reached consensus in support of the
proposal.

I will now forward a request to the ADs that the ID be published
using the AD sponsored procedure.

Scott






From cdl@asgaard.org  Wed Aug 17 10:23:13 2011
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F63721F8BB1 for ; Wed, 17 Aug 2011 10:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqokyUBMvvWr for ; Wed, 17 Aug 2011 10:23:11 -0700 (PDT)
Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED5521F8B90 for ; Wed, 17 Aug 2011 10:23:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 905015D687F; Wed, 17 Aug 2011 17:24:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at asgaard.org
Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mJL-zW5xW9Y; Wed, 17 Aug 2011 17:24:00 +0000 (UTC)
Received: from fenrir.asgaard.org (173-228-29-16.dsl.static.sonic.net [173.228.29.16]) by asgaard.org (Postfix) with ESMTPSA id A126B5D6874; Wed, 17 Aug 2011 17:23:57 +0000 (UTC)
Date: Wed, 17 Aug 2011 10:23:48 -0700
From: Christopher LILJENSTOLPE 
To: tim.pittman@bt.com
Message-ID: 
In-Reply-To: <12BF5EA014130B458A4FF2982872616426A4F0C51C@EMV64-UKRD.domain1.systemhost.net>
References: <6AEE1195-A613-4F4E-9F77-CBC7365F7A68@mimectl> <,> <032D30F3-204F-4797-BB8E-7F601D3F542C@mimectl> <12BF5EA014130B458A4FF2982872616426A4F0C51C@EMV64-UKRD.domain1.systemhost.net>
X-Mailer: sparrow 1.3.2 (build 814.60)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] draft-weil-shared-transition-space-request-03.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 17:23:13 -0000

As do I. (hat off)

-- 
Christopher LILJENSTOLPE
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Tuesday, 16 August 2011 at 13.21, tim.pittman@bt.com (mailto:tim.pittman@bt.com) wrote:

> I fully support the proposal for the assignment of a /10 for ISP-shared transition use.
> 
> BR/ Tim
> 
> 
> 
> 
> 
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org (mailto:OPSAWG@ietf.org) (mailto:OPSAWG@ietf.org)
> https://www.ietf.org/mailman/listinfo/opsawg



From brian.e.carpenter@gmail.com  Wed Aug 17 14:16:16 2011
Return-Path: 
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16A721F8C12 for ; Wed, 17 Aug 2011 14:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.601
X-Spam-Level: 
X-Spam-Status: No, score=-103.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um72rCFcu1eU for ; Wed, 17 Aug 2011 14:16:16 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 088E621F8C08 for ; Wed, 17 Aug 2011 14:16:15 -0700 (PDT)
Received: by gxk19 with SMTP id 19so1178665gxk.31 for ; Wed, 17 Aug 2011 14:17:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VypBN8V7ckBRkqC8vffHbCXNd/mSirrfp4vXFs2FYVA=; b=Q6EgPoakntj0rZiJ6gDwamQoJ0yYtTa/2qJQDHnjnX2jMeuvYEdgtySTmWasDQedZ4 EX6D1hduNZCuUVUgaNOVzL6bCBv0cXS/ERvo1q/xcPcSM/vVH+h5KRjdjQ5VOKgcfFei ww0zvRgA6+y9PfgoQRUYE9ox4rYIyC7VvOdMk=
Received: by 10.90.5.25 with SMTP id 25mr1624416age.200.1313615827823; Wed, 17 Aug 2011 14:17:07 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id l14sm1232054anl.8.2011.08.17.14.17.05 (version=SSLv3 cipher=OTHER); Wed, 17 Aug 2011 14:17:07 -0700 (PDT)
Message-ID: <4E4C2FD0.2010902@gmail.com>
Date: Thu, 18 Aug 2011 09:17:04 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Scott O. Bradner" 
References: <20110817114946.AF14CE599CD@newdev.eecs.harvard.edu>
In-Reply-To: <20110817114946.AF14CE599CD@newdev.eecs.harvard.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] end of WGLC on transition space
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2011 21:16:16 -0000

Being one of the four opposed, I'd like to say that I think
Scott has correctly stated the (rough) consensus.

Regards
   Brian Carpenter

On 2011-08-17 23:49, Scott O. Bradner wrote:
> this concludes the opsawg WGLC on shared transition space
> 
> There were 45 messages from 22 people on the opsawg mailing list in
> response to the WGLC.  Assuming I counted correctly, four of the
> posters were opposed to the proposal, 17 in favor and one said he was
> not in favor or opposed. 
> 
> Based on the mailing list discussion I would conclude that there is
> consensus in support of the proposal.  
> 
> In addition the proposal was discussed during the opsawg session in
> Quebec City.  Seventy nine people signed opsawg blue sheets for that
> session and I expect that a number of people present for the
> discussion did not sign since the room was standing room only and the
> blue sheets did not get to everyone and a number of people left after
> the shared transition space discussion.
> 
> Most people in room raised a hand when asked if the supported goal of
> ID, I did not see any that disagreed but a few people spoke against
> the proposal so I may have missed a few hands.
> 
> 
> from RFC 2418
>    In the case where a consensus which has been reached during a face-
>    to-face meeting is being verified on a mailing list the people who
>    were in the meeting and expressed agreement must be taken into
>    account.  If there were 100 people in a meeting and only a few people 
>    on the mailing list disagree with the consensus of the meeting then
>    the consensus should be seen as being verified.  Note that enough
>    time should be given to the verification process for the mailing list
>    readers to understand and consider any objections that may be raised
>    on the list.  The normal two week last-call period should be
>    sufficient for this.
> 
> Thus, based on the combination of the very strong support shown in
> the face-to-face meeting and the strong support in response to the
> WGLC, I conclude that the WG has reached consensus in support of the
> proposal.
> 
> I will now forward a request to the ADs that the ID be published
> using the AD sponsored procedure.
> 
> Scott
> 
> 
> 
> 
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>