Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues
draft-ietf-dhc-dual-stack-04

[Ballot comment]
Comments received from the Ops Directorate by Pekka Savola:

This seemed to be a relatively good document.  More or less editorial
comments below.

(in Section 5)
  On reflection on the above observations, it was the strong consensus
  of the dhc WG to adopt the two-server approach (separate DHCP and
  DHCPv6 servers) in favour to a combined, single server returning IPv4
  information over IPv6.  The two servers may be co-located on a single
  node, and may have consistent configuration information generated
  from a single asset database.

==> this is the first time you mention that DHC WG has already made a
decision on this.  Making this more prominent earlier in the spec (e.g.,
abstract, introduction, section 4.1/4.2) would probably be useful.

If the goal of this to-be-RFC is to document issues and discussions for
historical reference and further development, some minor rewording could be
helpful.

mostly editorial
----------------

==> please remove references from the abstract.

  These protocols allow nodes to communicate via IPv4 or IPv6 to
  retrieve configuration settings for operation in a managed
  environment

==> s/IPv6/IPv6 (respectively)/, otherwise this could be read that DHCPv4
would also support v6, or DHCPv6 support v4.

  While there is a more general multihoming issue to be solved for DHC,
  in this text we focus on the specific issues for operating DHCP in a
  mixed (typically dual-stack) IPv4 and IPv6 environment.

==> you mention 'multihoming' in two occasions, but don't really include
enough context to convey what you're talking about.  The last paragraph
of section 5 makes this a bit clearer; maybe reordering text or making a
separate subsection on multihoming would help.

  The DNS search path may vary for administrative reasons.  For
  example, a site under the domain foo.com chooses to place an early
  IPv6 deployment under the subdomain ipv6.foo.com, until it is
  confident of offering a full dual-stack service under its main
  domain.  The subtlety here is that the DNS search path then affects
  choice of protocol used, such as IPv6 for nodes in ipv6.foo.com.

==> s/foo.com/example.com/, s/chooses/may choose/ ?

==> btw, a related issue (similar text in 1st paragraph of section 4.4)
has been discussed briefly in section 4.2 of
draft-ietf-dnsop-ipv6-dns-issues-12.txt (in rfc-ed queue).

The
  principle operational choice is whether separate DHCP and DHCPv6
  servers should be maintained by a site, or whether DHCPv6 should be
  extended to carry IPv4 configuration settings for dual-stack nodes.

==> is this only an operational choice?  it's probably also an
implementation and specification choice.