IETF Logo Mail Archive

Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Ted Lemon <ted.lemon@nominum.com> Thu, 12 December 2013 04:20 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FB81ADF7C for <dhcwg@ietfa.amsl.com>; Wed, 11 Dec 2013 20:20:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz36Y3r_qLhj for <dhcwg@ietfa.amsl.com>; Wed, 11 Dec 2013 20:20:21 -0800 (PST)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1371ADF73 for <dhcwg@ietf.org>; Wed, 11 Dec 2013 20:20:21 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUqk5fz+jQoFwLYevHaLXugnVd0MeJ5/D@postini.com; Wed, 11 Dec 2013 20:20:15 PST
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 740131B82DC for <dhcwg@ietf.org>; Wed, 11 Dec 2013 20:20:15 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 498CC190043; Wed, 11 Dec 2013 20:20:15 -0800 (PST)
Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 20:20:15 -0800
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <CAFGoqUMbbH3h2ouf+9JphYoM2wTGK0tiRSSscPMuPB4Xq51XGg@mail.gmail.com>
Date: Wed, 11 Dec 2013 23:20:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <EFF87BCD-CD0E-46B5-B4B2-107DF49ABD1E@nominum.com>
References: <489D13FBFA9B3E41812EA89F188F018E1ADA99A8@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1ADD590C@xmb-rcd-x04.cisco.com> <CAFGoqUMbbH3h2ouf+9JphYoM2wTGK0tiRSSscPMuPB4Xq51XGg@mail.gmail.com>
To: Marcin Siodelski <msiodelski@gmail.com>
X-Mailer: Apple Mail (2.1822)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Bernie Volz <volz@cisco.com>, "draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org" <draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 12 Dec 2013 04:20:23 -0000

On Dec 11, 2013, at 2:39 PM, Marcin Siodelski <msiodelski@gmail.com> wrote:
> Before the client gets the tunnel configuration the tunnel interface
> doesn't exist. The 4o6 client just generates the client identifier
> (unique by IAID) for the tunnel to be established. Once the v4
> configuration is complete, the tunnel is created and the client
> associates the client identifier with this tunnel/interface.

I think it's important to be aware that this function is for "getting an IPv4 configuration," not "configuring an interface."   The document should certainly say as much as it can about what to do with the configuration, but we're really documenting a mechanism here for getting a configuration from a DHCP server, not documenting specific use cases for that mechanism.   So e.g. the expectation is that if lw4over6 uses this mechanism, it will say what to do with the information gathered as a result.   If some future spec needs this mechanism, it will say something that might be quite different. It is un-possible that this mechanism might be used without some other spec referring to it.

v2.23.0 | Report a Bug | By Email