Re: [OPSAWG] WGLC on draft-bdqks-arin-shared-transition-space

"George, Wesley" <wesley.george@twcable.com> Thu, 08 September 2011 17:31 UTC

Return-Path: <wesley.george@twcable.com>
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 AAD4A21F8565 for <opsawg@ietfa.amsl.com>; Thu, 8 Sep 2011 10:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.04
X-Spam-Level:
X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SARE_SUB_OBFU_Q1=0.227]
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 fFj3vuJgATj7 for <opsawg@ietfa.amsl.com>; Thu, 8 Sep 2011 10:31:29 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 123B021F8546 for <opsawg@ietf.org>; Thu, 8 Sep 2011 10:31:28 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.67,498,1309752000"; d="scan'208";a="256479236"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 08 Sep 2011 13:32:03 -0400
Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 8 Sep 2011 13:33:20 -0400
From: "George, Wesley" <wesley.george@twcable.com>
To: "sob@harvard.edu" <sob@harvard.edu>, "opsawg@ietf.org" <opsawg@ietf.org>, "rbonica@juniper.net" <rbonica@juniper.net>
Date: Thu, 08 Sep 2011 13:33:19 -0400
Thread-Topic: [OPSAWG] WGLC on draft-bdqks-arin-shared-transition-space
Thread-Index: Acxtw7tn+rNST6cNS5Ke4l0pvvPpmQAWrv0QAAAxP3A=
Message-ID: <34E4F50CAFA10349A41E0756550084FB0E0D6188@PRVPEXVS04.corp.twcable.com>
References: <20110901154335.8E474EB1EA1@newdev.eecs.harvard.edu> <34E4F50CAFA10349A41E0756550084FB0DF09129@PRVPEXVS04.corp.twcable.com> <4A7C4308-04D2-4403-BFC9-0B189448525B@delong.com> <34E4F50CAFA10349A41E0756550084FB0E0D5DAF@PRVPEXVS04.corp.twcable.com> <ED5A1260-931A-480B-93B8-374CE057BBB6@delong.com> <D4759D49578EC2458DD252B993155A2E095EB683FA@CATL0MS112.corp.cox.com>
In-Reply-To: <D4759D49578EC2458DD252B993155A2E095EB683FA@CATL0MS112.corp.cox.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
Cc: "draft-bdgks-arin-shared-transition-space@tools.ietf.org" <draft-bdgks-arin-shared-transition-space@tools.ietf.org>, "draft-weil-shared-transition-space-request@tools.ietf.org" <draft-weil-shared-transition-space-request@tools.ietf.org>
Subject: Re: [OPSAWG] WGLC on draft-bdqks-arin-shared-transition-space
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2011 17:31:29 -0000

-----Original Message-----
From: Stan.Barber2@cox.com [mailto:Stan.Barber2@cox.com]
Sent: Thursday, September 08, 2011 7:59 AM

Wes,
Can you point out where it seemed this changed?
_______
WEG] Ron's message explains what happened - someone noted during WGLC of draft-weil that you can't have a normative ref to a draft that's not complete, which effectively stopped the current plan. Mea culpa, I missed that.
However, we shouldn't be surprised that there was confusion over this (or at least *I* am not surprised that *I* was confused). Note that over the past year, there have been 3 or 4 different versions of a draft for shared transition space:
draft-weil-opsawg-provider-address-space, which had at least 2 dramatically different versions
draft-weil-shared-transition-space-request (the current one) which has added and then removed justification over each version
And some of that orphaned text made it into draft-bdgks-arin-shared-transition-space
And in between, it made the rounds through ARIN (policy 2011-5), only to be sent back here by IAB.

Independent of whether the opposition represents consensus or simply a vocal minority, this has always been a controversial idea and it feels more like we're trying to play shell games to avoid controversy and push this through quickly than to build consensus and a quality document(s).
First it dropped from a /8 to a /10 to try to reduce the opposition due to size
Then it dropped most of the justification text from the draft to "reduce the attack surface"
Then it split the drafts, with draft-weil becoming an AD-sponsored draft (for rapid adoption) and some other draft (eventually bdgks) providing the rationale and justification to provide the WG time to properly review and refine the details around draft-weil.
Now, based on the author's responses, it leaves draft-weil without any justification, and has a separate draft that covers additional use cases. If bdgks isn't the justification for draft-weil, perhaps draft-weil doesn't actually *need* a normative reference to bdgks, which would address the concern brought up at its last call. Whether the lack of rationale now brings up a new concern for draft-weil is for the sponsoring AD to address, I suppose.

I'm starting to think that it's not productive to continue discussing the content of the drafts until we have a clearer direction of what that content and the separation between them is supposed to be. If the plan is to push through both drafts largely as-is, and I am truly in the minority, so be it, I'll hold my nose and get out of the way. If, however, the aim is to actually provide a convincing argument for shared transition space, we need some additional guidance from the AD and Chairs. Most notably, for additional use cases, should there be a formal update to RFC1918 to acknowledge that there are circumstances where RFC1918 space is not an acceptable solution, and that additional address space is required to avoid conflicts?

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.