Subject: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Mar 2004 16:30:57 +0200 (EET)

Hi,

Vijay asked me to look at this, so blame him.. comments below.

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

 1) you assume the deployment of DHCPv6 relays.  DHCPv6 can work without
relays as well, right?  What if those do not exist?

 2) Using "reconfigure" messages to relays, instead of hosts, seems a bit
hackish -- but I don't know DHCPv6 spec in enough detail to know whether
there might be some other ways of redistributing this information.

 3) I'm not sure if I understand the applicability correctly.  I guess this
is useful when you're using stateless DHCPv6, use DHCPv6 relays, and would
like to trigger the updates automatically, not through a manual (or
otherwise automated) process?  Note that I don't think the interaction with
this and the host-side protocol (draft-vijay-ipv6-icmp-other-refresh-otherconf)
has been explicitly spelled out?

 4) the security requirements are not considered sufficiently.  reconfigure
messages, when used end-to-end must have been secured -- but you're using
them (secured) up to the DHCPv6 relay.  What about authentication from the
relay to the clients?

editorial
---------

Abstract

   Stateless DHCPv6 [DHCPv6Light] is a light-weight DHCPv6 [DHCPv6]
   protocol in which the server manages only the service parameters like

==> no refs in the abstract!!

   2.  For the model suggested in this specification to work better, the
   DHCPv6 server SHOULD be configured with information about all relay
   agents in the DHCPv6 administrative domain. If it is not configured
   so, then it MUST learn about the relay agents in the DHCPv6
   administrative domain.

==> isn't this SHOULD/MUST an operational mandate, which the implementations
cannot check?  If so, the uppercase keyword may not be appropriate (I think
there are other such keywords elsewhere in the document as well)

   IPv6Sec.  Thus, this is not a new constraint introduced by the

==> s/IPv6Sec/IPsec/

   Note:  Throughout this specification DHCPv6 means stateless DHCPv6
   unless or otherwise, it is explicitly mentioned as stateful DHCPv6.

==> remove "or otherwise, it is".
==> this should probably be stated earlier, in the Introduction, maybe.

   The server constructs a Reconfigure message with a non-zero  
   transaction id generated through some random number generation
   mechanism or through some incremental counter, but the transaction id
   generator mechanism should make sure that the same value is not
   repeated in minimal iterations.

==> what do you mean with "minimal iterations" ?

   DHCPv6 specification constraint of having "0" as transaction id for
   reconfigure message.  The reason will be discussed in the following

==> use consistent style throughout the document for "transaction-id".

Full Copyright Statement

==> add IPR statement around here.

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg