[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard

Pekka - thanks for your review. My responses to your comments are inline.

- Ralph

At 02:27 PM 11/3/2003 +0200, Pekka Savola wrote: 
On Thu, 30 Oct 2003, The IESG wrote:
> The IESG has received a request from the Dynamic Host Configuration WG to
> consider the following document:
>
> - 'A Guide to Implementing Stateless DHCPv6 Service'
>    <draft-ietf-dhc-dhcpv6-stateless-01.txt> as a Proposed Standard

Comments below.  The document needs a revision, but does not have, AFAICS,
major issues to deal with, except for better considerations on how DHCP
relays work (or don't :-) in the stateless/full DHCP model.. that is, do
you have "stateless relays" and "full relays", and potential problems to
stateful services stemming from that or not.

Note: IMHO, DHCP spec should have been the other way around, stateless
first, adding stateful parts on top of that as an extension.  Can't be
changed now, but might be something to consider when going to Draft
Standard or the like.

substantial
-----------

1) the spec is not sufficiently clear how the relays behave in a mixed world
of stateless/stateful DHCP service.  That is, would deploying a
stateless-only relay (if such a thing is possible?) harm the stateful DHCP
clients?  Is the implementation of a relay any different for full/stateless
DHCP service, etc. ?:

   The operation of relay agents is the same for stateless and stateful
   DHCPv6 service.  The operation of relay agents is described in the
   DHCPv6 specification.


The functions referenced in draft-ietf-dhc-dhcpv6-stateless-01.txt are
all completely defined in RFC 3315.  From the point of view of the
DHCPv6 relay agent, there is no difference between the subset of
RFC 3315 referred to as "stateless DHCPv6" and the full set of
functions in  RFC 3315.

More concisely, there are just "DHCPv6 relay agents" that work with both
full RFC 3315 clients and stateless-only clients...


2) there are a few remnants on the spec which talk about "DNS configuration
parameters".  One should be more generic than that; these are listed in the
editorials section.

OK...


3) I'm not familiar with DHCPv6 spec, but I'd like a confirmation that the
last sentence is actually true, and to reword it for clarity if so:

   A DHCP server that is only able to provide stateless configuration
   information through an Information-request/Reply message exchange
   discards any other DHCP messages it receives. Specifically, the
   server discards any messages other than Information-Request or
   Relay-forward it receives, and the server does not participate in any
   stateful address configuration messages exchanges.  If there are
   other DHCP servers that are configured to provide stateful address
   assignment, one of those servers will provide the address assignment.

==> that is, do relays really *flood* these messages to all the DHCPv6
servers they know, so that if one doesn't process the request but silently
ignores it, the others can step up and handle the job?  See also the point
1) above.


Yes, a relay agent forwards a copy of each message it receives from a client
to each of the servers in its configured list of servers.


editorial
---------

   the node's message with a Reply message that carries the DNS
   configuration parameters.  The Reply message from the server can

==> s/DNS//

OK.


   1-4:   give an introduction to DHCPv6 and an overview of DHCP message
      flows

==> some of those flows are redundant to Stateless DHCPv6 operation,
though.. :-)


OK, would a more precise list (e.g., individual subsections rather than
simply "1-4") be helpful?


5. Implementation of stateless DHCP


==> s/stateless/Stateless/

OK.


   DNS configuration information, it includes either or both of the DNS
   configuration options in the Information-request message.

==> one should list here the two kinds of DNS config options, or reword the
sentence.

OK.


5.1 Messages required for stateless DHCP


==> s/r/R/, s/s/S/

OK.


   Clients and servers implement the following messages for stateless
   DHCP service; the section numbers in this list refer to the DHCPv6
   specification:

==> many sections are missing the "the section ..." blurb.  It might make
sense to add something at the end of section 5, like, "In the following
subsections, the section numbers used refer to the DHCPv6 specification".

   Information-request: sent by a DHCP client to a server to request DNS
      configuration parameters (sections 18.1.5 and 18.2.5)


   Reply:               sent by a DHCP server to a client containing the
      DNS configuration parameters (sections 18.2.6 and 18.2.8)

==> s/DNS// (2 cases)

OK.


5.2 Options required for stateless DHCP service


==> s/r/R/, s/s/S/, s/service// (remove service for consistency with other
5.x)

OK


5.3 Options used for configuration information


==> s/u/U/, s/c/C/, s/i/I/

OK


5.4 Other options used in stateless DHCP


==> s/o/O/, s/u/U/, s/s/S/ 

OK (more precisely, I'll make sure the capitalization is consistent
in section headers throughout)


   DHCP service; the section numbers in this list refer to the DHCPv6
   specification, RFC 3315>:

==> see above, but if keeping it here, make consistent with the rest

OK


      22.2).  Clients are not required to send this option; servers send
      the option back if included in a message fro ma client


==> s/fro ma/from a/

OK


--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg