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

Qi Sun <sunqi.csnet.thu@gmail.com> Wed, 27 November 2013 15:06 UTC

Return-Path: <sunqi.csnet.thu@gmail.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 E93321ADDBD for <dhcwg@ietfa.amsl.com>; Wed, 27 Nov 2013 07:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 hMIUi7UG-M1R for <dhcwg@ietfa.amsl.com>; Wed, 27 Nov 2013 07:06:44 -0800 (PST)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 78F791AD958 for <dhcwg@ietf.org>; Wed, 27 Nov 2013 07:06:44 -0800 (PST)
Received: by mail-pd0-f179.google.com with SMTP id r10so10006751pdi.24 for <dhcwg@ietf.org>; Wed, 27 Nov 2013 07:06:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=6jjs07wDpf68Lf8Ih2XkP6pdTv8SSG2OHS2h7mOh/bk=; b=aAEFtUNw1AFFpzi7b3l+th9DsCBFlRs2uphMlAPTFXH8swsMlhzTdvee61K8ppR85y xcnGgpF2DTBjYdSVqA04uZjQlCyOlaj9SwsJ2PyDacNzFMRtpLwIknL1shiLdqOp+Bgc jJzCWdHXb28l0LmdJM8eOv9gKOwSU7LpzysjBLcb96hcvDX0qmaxwO/MHLfNPK/f51HO cSFXwyv3clX1JIEoCki7ThkZk6OWgQxonnpnVPmA6Lh2mFIt7PASFkisJgDui3DkDjiL jDUP8cIwzoNR93MiukCJ08oaP7MlVEdMaAsPJVGWiHxaz0Uljfadi7ovuuI/lt93HDzQ DMFg==
X-Received: by 10.66.121.131 with SMTP id lk3mr42018821pab.61.1385564804051; Wed, 27 Nov 2013 07:06:44 -0800 (PST)
Received: from [192.168.1.106] ([59.64.255.197]) by mx.google.com with ESMTPSA id bp5sm88577938pbb.18.2013.11.27.07.06.39 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 07:06:43 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-3--764299513
From: Qi Sun <sunqi.csnet.thu@gmail.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ADC151D@xmb-rcd-x04.cisco.com>
Date: Wed, 27 Nov 2013 23:06:33 +0800
Message-Id: <B880A35E-38A4-4A4E-B858-3455359E0D6C@gmail.com>
References: <CEBB74DD.9C090%ian.farrer@telekom.de> <124F1F54-5997-46D9-A6F1-54F94E3D6423@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1ADC151D@xmb-rcd-x04.cisco.com>
To: Bernie Volz (volz) <volz@cisco.com>
X-Mailer: Apple Mail (2.1085)
Cc: "dhcwg@ietf.org" <dhcwg@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: Wed, 27 Nov 2013 15:06:48 -0000

Hi Bernie,

Thanks for your reminding. I agree that we should not exclude ORO option in the two messages.

Best Regards,
Qi


On 2013-11-27, at 下午10:01, Bernie Volz (volz) wrote:

> Hi:
>  
> I agree with Qi that these options should not be used for the BOOTREQUESTV6/BOOTREPLYV6 messages.
>  
> While we might want to think about some words to indicate that these messages should not typically have options (other than the OPTION_BOOTP_MSG option), I think we do want to be careful as someone might have a reason to include some options that could be useful to the 4o6 DHCP Server or Client in the future.
>  
> The bottom line is that these messages SHOULD NOT be used to configure DHCPv6 client and interface related settings – hence why the OPTION_DHCP4_O_DHCP6_ENABLE and OPTION_DHCP4_O_DHCP6 options SHOULD NOT be present. Normal DHCPv6 messages should be used for configuring anything related to DHCPv6 (including the two just mentioned options).
>  
> -          Bernie
>  
> From: Qi Sun [mailto:sunqi.csnet.thu@gmail.com] 
> Sent: Wednesday, November 27, 2013 6:10 AM
> To: <ian.farrer@telekom.de>
> Cc: Bernie Volz (volz); dhcwg@ietf.org
> Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
>  
>  
> Hi Ian,
>  
> Thanks for comments.
>  
>  
> On 2013-11-27, at 下午5:50, <ian.farrer@telekom.de> <ian.farrer@telekom.de> wrote:
>  
> Section 8, the sentence beginning ‘The client that intends…’ should read ‘A client that intends….'
>  
> [Qi] Will correct it.
> 
> 
>  
> Section 8  - Question regarding the sentence ‘The 4o6 DHCP client MUST NOT request the DHCPv4-over-DHCPv6 Enable Option nor the 4o6 Server Address Option in the Boot-request-v6 message’. I think that this text as written is ambiguous.
>  
> Is it meant to mean that the boot-request-v6-message can contain any DHCPv6 option with the exception of the 4o6 enable and 4o6 server options? Saying that the client may not request certainly implies that the client could include an ORO option alongside OPTION_BOOTP_MSG. Is the intention to allow this?
>  
> [Qi] The reason I added this sentence was that it's not necessary for the client to ask for the Enable Option again in Boot-request-v6 message as the DHCPv4-over-DHCPv6 function has been running. The DHCPv4-over-DHCPv6 function status should be refreshed alongside IPv6 configuration process rather than DHCPv4 over DHCPv6 process. 
>  
> IMHO, the Boot-request-v6 msg and Boot-reply-v6 msg should only be used for v4-related configuration, which makes it simple.  Would it reasonable to exclude the ORO option in the two messages?
>  
> If not, why exclude requesting the 4o6 server option? Obviously, it’s pointless allowing the Enable option, but sending the 4o6 server option within the BOOTREPLYV6 to allow a dedicated DHCP4o6 server to tell the client to use unicast seems like it could be a good idea. What’s the reason for specifically excluding it?
>  
> [Qi] Allowing the client to request the 4o6 server address option would violate the Bullet 4 in section 8: the client only receives the 4o6 Server Address option but no DHCPv4 over DHCPv6 Enable option, then the client is required to ignore the 4o6 Server Address option. 
>  
> IMHO, we could make it simple: the server signals the client to use unicast or multicast when the client is enabled to invoke the DHCPv4 over DHCPv6 and it's not necessary for the client to change that.
>  
> Best Regards,
> Qi 
> 
> 
>  
> There’s also a few other places in the text that need to be aligned with this (the ‘options’ description in Sec 5.2 and paragraph 8 of section 8).
>  
> Thanks,
> Ian
>  
>  
> From: "Bernie Volz (volz)" <volz@cisco.com>
> Date: Sunday, 24 November 2013 23:02
> To: "dhcwg@ietf.org" <dhcwg@ietf.org>
> Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
>  
> Folks, the authors of draft-ietf-dhc-dhcpv4-over-dhcpv6-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03.txt) believe it is ready for working group last call. Please review this draft and indicate whether or not you feel it is ready to be published. Your input is important! Please respond by Dec 9th, 2013.
>  
> At the time of this writing, there is no IPR reported against this draft.
>  
> Bernie will be the document shepherd.
>  
> Thanks,
>  
> -          Tomek & Bernie
>  
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>