Re: Node Req: Issue31: DHCPv6 text (ignore previous mails)

Tim Chown <tjc@ecs.soton.ac.uk> Thu, 04 December 2003 12:19 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21928 for <ipv6-archive@odin.ietf.org>; Thu, 4 Dec 2003 07:19:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARsRe-0003Ct-Vk for ipv6-archive@odin.ietf.org; Thu, 04 Dec 2003 07:18:58 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4CIwoY012321 for ipv6-archive@odin.ietf.org; Thu, 4 Dec 2003 07:18:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARsRe-0003Ce-Rp for ipv6-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 07:18:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21891 for <ipv6-web-archive@ietf.org>; Thu, 4 Dec 2003 07:18:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARsRe-0007Pv-00 for ipv6-web-archive@ietf.org; Thu, 04 Dec 2003 07:18:58 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARsRe-0007Ps-00 for ipv6-web-archive@ietf.org; Thu, 04 Dec 2003 07:18:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARsQj-0002zw-BA; Thu, 04 Dec 2003 07:18:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARsQA-0002z7-W8 for ipv6@optimus.ietf.org; Thu, 04 Dec 2003 07:17:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21856 for <ipv6@ietf.org>; Thu, 4 Dec 2003 07:17:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARsQA-0007Nr-00 for ipv6@ietf.org; Thu, 04 Dec 2003 07:17:26 -0500
Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARsQ9-0007NZ-00 for ipv6@ietf.org; Thu, 04 Dec 2003 07:17:25 -0500
Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA29853 for <ipv6@ietf.org>; Thu, 4 Dec 2003 12:17:14 GMT
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA29754 for <ipv6@ietf.org>; Thu, 4 Dec 2003 12:17:11 GMT
Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hB4CHBU11029 for ipv6@ietf.org; Thu, 4 Dec 2003 12:17:11 GMT
Date: Thu, 04 Dec 2003 12:17:11 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: ipv6@ietf.org
Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails)
Message-ID: <20031204121711.GL6808@login.ecs.soton.ac.uk>
Mail-Followup-To: ipv6@ietf.org
References: <DADF50F5EC506B41A0F375ABEB320636A8BC07@esebe023.ntc.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DADF50F5EC506B41A0F375ABEB320636A8BC07@esebe023.ntc.nokia.com>
User-Agent: Mutt/1.4i
X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information
X-ECS-MailScanner: Found to be clean
Sender: ipv6-admin@ietf.org
Errors-To: ipv6-admin@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>

I guess it would be good to get Ralph's input here.

Clearly clients may implement a subset, and if we consider that for this
document we can either

a) add references to stateless DHCPv6, but this is not finished so that 
   is not ideal

b) use language that emphasises whether the client implements stateful
   address configuration and/or other configuration options (and for now
   we assume that these are the two possible subsets of functionality)

Running with b) seems safer at this stage - it would add a bit of wordage 
but avoid the possible hold-up that Thomas hints at?

Tim

On Thu, Dec 04, 2003 at 02:05:24PM +0200, john.loughney@nokia.com wrote:
> Tim & Pekka,
> 
> I got this comment from Thomas wrt Stateless DHCP:
> 
>  Does this even need mentioning? I.e, what are the real implications
>  for clients? Do they need to implement full blown dhc (the client
>  part)? Or do they implement some subset?  (Hmm... reading the related
>  draft, clients implement a subset... And this document has a normative
>  reference to the other ID, so either this document needs to be more
>  explicit about what stateless DHCPv6 is, or will have to wait on the
>  other document.)
> 
> We agreed that perhaps discussion of Statless DHCP need not be mentioned.
> 
> John
> 
> > -----Original Message-----
> > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext
> > Tim Chown
> > Sent: 04 December, 2003 13:54
> > To: ipv6@ietf.org
> > Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails)
> > 
> > 
> > On Thu, Dec 04, 2003 at 01:42:36PM +0200, Pekka Savola wrote:
> > > On Thu, 4 Dec 2003, Tim Chown wrote:
> > > > On Thu, Dec 04, 2003 at 01:25:35PM +0200, Pekka Savola wrote:
> > > > > 
> > > > > Also, there are basically two versions of "DHCP": the 
> > one specified in 
> > > > > RFC3315, and the "stateless DHCP", in IESG review at 
> > the moment.  It 
> > > > > is not clear to which you're referring to here.
> > > > 
> > > > Does that matter to the client?
> > > 
> > > The sentences start basically like, "If the node implements 
> > DHCP, it 
> > > MUST/SHOULD do foo".
> > > 
> > > Does a stateless DHCP count as implmenting DHCP?  Is stateless DHCP 
> > > non-compliant with Node Requirements?
> > 
> > OK, so the node may implement the full DHCPv6 spec (for 
> > address and other 
> > info) or stateless DHCPv6 (only for other info).   The 
> > implementation of
> > how other info is obtained would be the same.   
> > 
> > So I agree we should say something like "If the node 
> > implements stateful
> > address configuration for DHCPv6 then"
> > 
> > i.e. put the language in terms of client functionality rather 
> > than whether
> > the server is full or ststeless?
> > 
> > Tim
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------