[dhcwg] comments on draft-jiang-dhc-stateless-reconfiguration-00

神明達哉 <jinmei@wide.ad.jp> Sun, 02 March 2014 17:04 UTC

MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Date: Sun, 02 Mar 2014 17:04:15 +0000
Message-ID: <CAJE_bqe2v8b3L1pQpsgkXf4dbvy88s+4MHWfOmME6HSgfKcd6A@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: draft-jiang-dhc-stateless-reconfiguration@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/gNcSMum01vF60CiJkFIgRpElzAE
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: [dhcwg] comments on draft-jiang-dhc-stateless-reconfiguration-00
Precedence: list

I have one higher level comment (or question) on the draft: how should
this be reliable?  Specifically, what if the STATELESS RECONFIGURE
message is lost for some of the clients that would need it?  The
original (stateful) RECONFIGURE addresses the issue by resending it
until the subsequent Renew (or Information-request) message is
received by the server, but we cannot use the same approach since the
server doesn't know the full set of the expected clients.

I also have some specific comments:

- In Section 1, I suggest referring to RFC 4242 and explaining that
  this proposal tries to fill some gap that the RFC still doesn't
  address.

- In Section 4.1, the draft states:

   Notes: since there is no previous Relay-Forward message that went
   through multiple relay agents and the server has to send the Relay-
   Reply message through the return same path, the server should be able
   to send the Relay-Reply message to the relay agent that direct
   connects with clients.

  First off, this sentence is grammatically awkward.  But I think I
  understand what it tried to say.  And, on top of that understanding,
  I don't think this is necessarily correct.  I think it's still
  possible that a client sends an Information-request message through
  multiple relay agents, and if the assumption is to manually
  configure the addresses of relay agents (as described in Section 3),
  it should be possible to configure it with the information of
  nesting.  It's a different question whether such an operation is
  recommended, but I think it's at least possible in principle.

- On question No.4 in Section 4.3, my personal take is to at least
  define it in the specification.  I think that's the general practice
  for parameters like this.  If we see the need for varying it, we may
  want to just define it as the default value and allow the server to
  tell the clients to use a different value (using a new option or
  something), but right now I don't know if we need such flexibility.

--
JINMEI, Tatuya

[dhcwg] comments on draft-jiang-dhc-stateless-rec… 神明達哉