Subject: Summary of issues from DHCPv6 spec last call

From: Ralph Droms <[email-masked]>
Date: Wed, 16 Jan 2002 21:32:02 -0500

Bernie - I've been in allday meetings Mon and Tue, and more meetings for a 
good part of today.

I put together the following message to send to the dhcwg and ipng mailing 
lists, summarizing the comments during the last call.  There is one more 
batch of comments from Vijay Bhaskar A K that I need to address.  Would you 
please review this message and confirm that I've captured all of the 
threads from the last call?  Thanks...

I will be travelling Thu and Fri, but will be checking e-mail intermittently...

- Ralph

The following issues were raised during the last call for the DHCPv6 spec 
<draft-ietf-dhc-dhcpv6-22.txt>; I will kick off separate discussion threads 
for each open issue later today:

Open issues
-----------
* Does DHCPv6 need a "default routes" option?

* Does DHCPv6 need a "static routes" option?

* Does DHCPv6 need an FQDN option (basically identical
   to proposed DHCPv4 FQDN option)?

* Should the DHCPv6 option codes start at 256 to avoid
   overlap with DHCPv4 option codes; overlap of
   option codes would be an issue for the DHCID RR.

* What error codes may a server send in response to
   an Information-Request message?

* Does the Information-Request message require a DUID?
   Could the "MUST" in the third paragraph of 18.1.5
   be changed to "SHOULD"?  If a DUID "SHOULD" be
   included, text needs to be added pointing out the
   client-specific information (based on identifying the
   client with a DUID) cannot be returned if a DUID
   is not included.

* Is a client required to implement the Reconfigure
   message - supporting Reconfigure will require that
   the client maintain state.

Changes to be made in -23
-------------------------
* Editorial changes:
   - Change "Inform message" to "Information-request message"
     and "INFORM" to "INFORMATION-REQUEST" throughout the
     document
   - Fix redundancy between sections 18.2.5 and 18.2.8
   - Change "Rebind" to "Inform" in the last paragraph
     of section 18.1.5 (cut-and-paste error)
   - Fix page 10 (which is blank in -22 draft)
   - In third paragraph of section 14, change "Requested
     Temporary Addresses Option 22.5" to "Requested
     Temporary Addresses Option (see section 22.5)"
   - Change last sentence of section 22.5 to: "A client MUST
     only include this option when it wants to have
     additional temporary address allocated; a client SHOULD
     NOT send this option if 'num-requested' is 0".

* Remove references to "IAs" in section 19.2

* Fix chart in Appendix B to allow DSTM option in same
   messages as IA option

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Ralph Droms <[email-masked]>
Date: Wed, 16 Jan 2002 21:43:13 -0500

Please ignore my previous message to this list - I'll post a complete 
summary of the discussion of the DHCPv6 draft tomorrow.

- Ralph Droms