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 PROTECTED]
--------------------------------------------------------------------
