Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails)

From: [email-masked]
Date: Thu, 4 Dec 2003 13:38:44 +0200

Pekka,

> > > Use DHCP for what?  both address config (if available) as well?
> > 
> > The text says:
> > 
> > 	... to obtain other  configuration.
> 
> Yes, in the first sentence.  No, in the second.

It can be added to the 2nd sentence.

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 4 Dec 2003 13:40:14 +0200

Pekka,

> 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.

There is no discussion of stateless DHCP, the section heading is:

5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315

John

---

From: [email-masked]
Date: Thu, 4 Dec 2003 13:58:20 +0200

Hi Tim,

> Remove site-local as we're deprecating them?

I agree.  It was an oversite.

> >    An IPv6 node that receives a router advertisement with the 'M' flag
> >    set and that contains advertised prefixes will configure interfaces
> >    with both stateless autoconfiguration addresses and addresses
> >    obtained through DHCP.
> 
> Perhaps cite 5.6 of 2462 here?  It hadn't occured to me that both stateless
> and stateful could be used together.   Is this discussed anywhere else
> other than 5.6 in 2462?

Let me look.

> >    For those IPv6 nodes that implement DHCP, those nodes should use DHCP
> >    upon the receipt of a Router Advertisement with the 'M' flag set (see
> >    section 5.5.3 of RFC2462) for address configuration.  In addition, 
> >    in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt 
> >    to use DHCP for address configuration.
> 
> Hmmm... in 5.5.2 of 2462 it says
> 
>    "If a link has no routers, a host MUST attempt to use stateful
>     autoconfiguration to obtain addresses and other configuration
>     information."
> 
> so it's not just for address configuration.  Perhaps cite 5.5.2 here.
> M means use DHCP for addresses and other config info, O means just other
> config info (an odd way for it to be specified, but... :)

Good catch, I will fix the text.
 
> > 5.3.2 Other Stateful Configuration
> > 
> >    DHCP provides the ability to provide other configuration information
> >    to the node. An IPv6 node that does not include an implementation of
> >    DHCP will be unable to obtain other configuration information such as
> >    the addresses of DNS servers when it is connected to a link over
> 
> Perhaps say "DNS or NTP" so that we emphasise it's not just about DNS.

Agreed.

> Do you have a target date to release the next version of the nodes
> requirements draft?  I appreciate it's a lot of work.

Shortly, as soon as we resolve this.

John

---

From: Ralph Droms <[email-masked]>
Date: Thu, 04 Dec 2003 07:46:42 -0500

I'm just catching up on this thread ... I was off-line (sleeping) and found
it in my inbox this AM.

I'll follow up in a couple of hours, after I catch up on a couple of
pressing day job issues.

There is another issue with RFC 2462 that will fall somewhere among
clarification/update/revision of the spec in RFC 2462: the text describing
the use of the OtherConfigFlag and the O flag in RAs is slanted toward the
definition of the protocol for "other configuration information" as a
"stateful" protocol (if I remember correctly, the text in question is in
section 5.5.3 of RFC 2462).  There are both technical and editorial issues
with that text.  I'll follow up a little later this AM.

- Ralph

At 02:24 PM 12/4/2003 +0200, [email-masked] wrote:
>Hi Tim,
>
> > 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?
>
>I'd prefer adding an informative reference to stateless DHCPv6, and mention
>its relation to 'normal' DHCP.
>
>Ralph, any suggested text?
>
>John
>

---

From: Alain Durand <[email-masked]>
Date: Thu, 04 Dec 2003 14:31:51 -0800

Catching up with things.

I support Christian objection 100%.
Protocols may be implemented in the stack but turned on/off by 
configuration.

    - Alain.

Christian Huitema wrote:

>>Also, I think we should revisit this text in the RFC2462bis
>>effort.  Changing the MUST to MAY in the 5.5.2 paragraph looks like
>>    
>>
>the
>  
>
>>right change to me, but that's a different email thread.
>>    
>>
>
>I would agree with that. In any case, I object to tying a MUST condition
>to the availability of the code in the implementation. Implementation is
>a necessary condition, but so is for example user or admin consent,
>maybe battery state, whatever. The text should not speak about
>implementation.
>
>-- Christian Huitema
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 6 Dec 2003 06:40:11 -0500

Stateless DHCPv6 is a proper subset of DHCPv6 3315.  Just say DHCPv6.
This is exact example of the silliness we do on mail lists taking up
peoples time.  Thomas Narten is correct and giving good AD advice to
John.  Chairs overruled.  Lets move on.

/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, December 04, 2003 7:05 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails)
> 
> 
> 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: [email-masked] [mailto:[email-masked]]On 
> Behalf Of ext
> > Tim Chown
> > Sent: 04 December, 2003 13:54
> > To: [email-masked]
> > 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:
> > > > > 
> > > > 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
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 6 Dec 2003 06:45:04 -0500

Pekka,

Have you read both specs?  Both Ralph and I have told you it's a total
proper subset.  We are the TECHNICAL experts and both are working
implementations hands on of both specs, the AD has stated a good opinion
too.  You now are using up our time with your opinion and have been told
by many now its not a problem.  Your using up precious mail time here on
this list and would you now please clarify when your speaking as Chair
and when as "individual" so we can get an idea what portion of your mail
is breaking the defacto rule of 15 mail messages a week.  You have lost
this debate please accept it and move on I am sure John can get text
from all said can we please move on to next topic.

Thanks
/jim

> Behalf Of Pekka Savola
> Sent: Thursday, December 04, 2003 1:32 PM
> To: Ralph Droms
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> On Thu, 4 Dec 2003, Ralph Droms wrote:
> > No, there are not really two versions of DHCPv6 - all of 
> the various message
> > exchanges and modes of operation are defined in RFC 3315.
> > draft-ietf-dhc-dhcpv6-stateless-02.txt is an aid to the 
> implementation of
> > DHCP that provides other configuration information but not 
> address assignment.
> 
> Sure, but then a sentence like "if DHCP is implemented" makes a bit 
> sense as some may implement the critical part and some not.  It's not 
> a binary yes/no decision.
> 
> > It might clarify the text a little to refer to "a node that 
> uses DHCP for
> > address assignment" and "a node that uses DHCP to obtain 
> other configuration
> > information"; 
> 
> Based on the wording, that might be fine.
> 
> > I think references to "stateless DHCPv6" are confusing.
> 
> Maybe, maybe not.  A brief reference could maybe be added 
> just to make 
> the folks realize that there is a implementable and "blessed" subset 
> of DHCP.. but the main point is clarity in the body of the 
> description.
> 
> 
> > At 01:25 PM 12/4/2003 +0200, Pekka Savola wrote:
> > >[...]
> > >--
> > >Pekka Savola                 "You each name yourselves 
> king, yet the
> > >Netcore Oy                    kingdom bleeds."
> > >Systems. Networks. Security. -- George R.R. Martin: A 
> Clash of Kings
> > >
> > >
> > >
> > 
> > >Administrative Requests: 
> https://www1.ietf.org/mailman/listinfo/ipv6
> > 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 6 Dec 2003 06:57:57 -0500

Your not chair here my mistake.  So you are breaking the defacto rule
and methodology. Do you think your more special than the rest of us or
something, smarter, wiser, etc?
/jim

> Behalf Of Bound, Jim
> Sent: Saturday, December 06, 2003 6:45 AM
> To: Pekka Savola; Ralph Droms

---

From: [email-masked]
Date: Mon, 8 Dec 2003 13:57:43 +0200

Hi Ralph, 

Thanks for the text, I agree & will add it.

thanks,
John

> From: ext Ralph Droms [mailto:[email-masked]]
> Sent: 04 December, 2003 22:52
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; Pekka Savola
> Here are some comments and suggested text for 
> draft-ietf-ipv6-node-requirements-06.txt:
> 
> 
> It would be good to use either DHCP or DHCPv6 (but not both) 
> consistently 
> throughout the doc.
> 
> 
> 5.3.1 Managed Address Configuration
> 
> The first two paragraphs are sort of redundant relative to the second 
> paragraph in section 4.5.5.  I suggest that the union of the 
> information in 
> the two sources be put into section 4.5.5, and the first two 
> paragraphs of 
> 5.3.1 be deleted.
> 
> I suggest the following text for 5.3.1:
> 
>     Those IPv6 Nodes that use DHCP for address assignment 
> initiate DHCP
>     to obtain IPv6 addresses and other configuration information upon
>     receipt of a Router Advertisement with the 'M' flag set, as
>     described in section 5.5.3 of RFC 2462.  In addition, in the
>     absence of a router, those IPv6 Nodes that use DHCP for address
>     assignment MUST initiate DHCP to obtain IPv6 addresses and other
>     configuration information, as described in section 5.5.2 of RFC
>     2462.  Those IPv6 nodes that do not use DHCP for address 
> assignment
>     can ignore the 'M' flag in Router Advertisements.
> 
> 
> 5.3.2 Other configuration information
> 
> I suggest changing the title of this section because the 
> development of 
> DHCP has moved toward using a DHCP in a way that is typically 
> known as 
> "stateless".  I recognize the potential confusion with RFC 
> 2462, in which 
> "stateful" is pretty deeply embedded.
> 
> I think the first paragraph of 5.3.2 is redundant and should 
> be merged in 
> with the text in 4.5.5.
> 
> I suggest the following text for 5.3.2
> 
>     Those IPv6 Nodes that use DHCP to obtain other configuration
>     information initiate DHCP for other configuration information upon
>     receipt of a Router Advertisement with the 'O' flag set, as
>     described in section 5.5.3 of RFC 2462.  Those IPv6 nodes that do
>     not use DHCP for other configuration information can 
> ignore the 'O'
>     flag in Router Advertisements.
> 
>     An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL]
>     to obtain other configuration information.
> 
> 
>

---

From: [email-masked]
Date: Mon, 8 Dec 2003 14:11:23 +0200

Hi Tim,

> There is a minor discrepancy in text between 2461 and 2462 that could
> perhaps be clarified in the -bis work for those texts.   This is regarding 
> the M flag referring to addresses and other options, or just addresses.
> Three parts of the texts have different nuances:
> 
> a) 2461 section 4.2 says M flag means hosts use the stateful protocol
>    for address assigment, and O flag means hosts used the stateful protocol
>    for other (non-address) information.
> 
> b) Then in 2462 it says in Section 4 (p.9) and Section 5.2 (p.11) again
>    that a "managed address configuration" flag indicates whether hosts should 
>    use stateful autoconfiguration to obtain addresses and an "other stateful
>    configuration" flag indicates whether hosts should use stateful 
>    autoconfiguration to obtain additional information (excluding addresses).
> 
> c) But then in 5.5.3 of 2462 the RA processing text states what I expect
>    most (all?) implementations actually do:  "If the value of ManagedFlag 
>    changes from FALSE to TRUE ...  the host should invoke the stateful address 
>    autoconfiguration protocol, requesting both address information and other 
>    information." (i.e. for both information)
> 
> So the question is should the wording of (a) and (b) be changed to reflect
> the processing text of (c)?  On their own, (a) and (b) suggest that to get
> the behaviour of (c) *both* the M and O bits should be set, but (c) states
> that only the M bit need be set for full stateful autoconfiguration. 

I think that (c) is the correct behavior - should you suggest text
for 2461 & 2462?

John