Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

Ted Lemon <Ted.Lemon@nominum.com> Wed, 26 September 2012 12:57 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7D21F86CB for <dhcwg@ietfa.amsl.com>; Wed, 26 Sep 2012 05:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.737
X-Spam-Level:
X-Spam-Status: No, score=-105.737 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, 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 IYQe7NMk54I4 for <dhcwg@ietfa.amsl.com>; Wed, 26 Sep 2012 05:57:45 -0700 (PDT)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3912D21F860D for <dhcwg@ietf.org>; Wed, 26 Sep 2012 05:57:45 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUGL7yc3cfG/OaUqTkKx7G+ISAV/pK+XT@postini.com; Wed, 26 Sep 2012 05:57:45 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 890A81B82E5 for <dhcwg@ietf.org>; Wed, 26 Sep 2012 05:57:44 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7C74619005C; Wed, 26 Sep 2012 05:57:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 26 Sep 2012 05:57:44 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Ole Trøan <otroan@employees.org>
Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
Thread-Index: AQHNeWDyHUsxdHhkUUml/eENyUzBb5dt5P4AgCx5BwCAASw+gIAASXKAgAE2VICAAEWWgA==
Date: Wed, 26 Sep 2012 12:57:43 +0000
Message-ID: <8275EA44-3606-4C82-A656-653B56009D09@nominum.com>
References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C4668ED@SZXEML510-MBS.china.huawei.com> <8AC1BB64-BA6D-4395-ABA7-1F317C3550D0@nominum.com> <D4AB11DA-0815-4E79-A097-F9B408210D81@employees.org> <C53F80F0-F243-4A0D-B03D-BDEE4B4246BC@nominum.com> <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org>
In-Reply-To: <39714EDD-C5DA-4DDF-AD10-E06A934EEDAE@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <B5867200363CC84A84368992FD492F5A@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: dhc WG <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2012 12:57:46 -0000

On Sep 26, 2012, at 4:48 AM, Ole Trøan <otroan@employees.org>
 wrote:
> I think we should do this too. let us make sure we get that into the RFC3315bis that I clearly remember you volunteered to write. ;-)
> this draft proposes a solution that only affects the client implementation though (that is changing anyway), so I think we need this for a deployable solution.

The changes required to RFC3315 to do what you want are minor and don't require a spin of the full document—you can just issue a short document, about the length of your current one, that updates RFC3315.   This will get you what you want in the short term, and then we can fold your work into the RFC3315 update when the time comes.

What you are doing here is proposing something completely different, that is unnecessarily complicated, and makes things worse, and that will not be compatible with the subsequent update to RFC3315.   IOW, two solutions, where one would have done better.