Subject: [dhcwg] comments on draft-ietf-dhc-lifetime-02.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 08 Nov 2004 13:59:38 +0900

Hello,

I should have done this much earlier, but I just went through
draft-ietf-dhc-lifetime-02.txt.  Overall, this version addresses all
my previous concerns, and I believe it's almost ready for publication.

I have some minor comments:

1. In section 3 (the second last paragraph), the draft says

   The client is however
   free to fall back to other mechanisms if it cannot refresh the data
   within a reasonable amount of time.

I'm not really sure what this sentence means.  Specifically, I don't
understand what "other mechanisms" mean in this context.  Please
clarify that.

2. In section 3 (last paragraph), it says:

   When a client receives a Reply to an Information-Request that
   contains configuration information (i.e., does not contain a Status
   Code option), it should [...]

I don't think the part with "i.e." is really correct.  I can imagine
an implementation that successfully returns configuration information
with Status Code being "Success".  (In fact, I remember an
implementation that behaved like this).  Perhaps we can simply remove
the "i.e." clause, or clarify that "does not contain a Status Code
option with a code other than Success", or remove this phrase but add
"successfully" between "that" and "contains", etc.

3. In section 3.1, the draft says

     IRT_DEFAULT 86400
          In some cases the client uses a default refresh time
          IRT_DEFAULT.  The recommended value for IRT_DEFAULT is 86400
          (24 hours).  The client implementation should allow for this
          value to be configurable.

  Perhaps the "should" in the last sentence might be "SHOULD".  (I
  don't have a particular preference/opinion on this though)

4. This document uses a phrase like "client MUST include this option
   in ORO".  I don't think this is really accurate, since an ORO does
   not contain the option itself, but just indicates the client's
   desire to receive the option by specifying the option code value.

   So, for example, I'd rephrase the first sentence of Section 3.2
   from

     A client MUST include this option in the Option Request Option (ORO)
     when sending Information-Request messages to the DHCPv6 server.

  to

     A client MUST specify this option in the Option Request Option (ORO)
     when sending Information-Request messages to the DHCPv6 server.

  That is, s/include/specify/.

  The same comment should also apply to:
  - the 2nd sentence of Section 3.2
  - the 1st sentence of Section 3.3

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Stig Venaas <[email-masked]>
Date: Tue, 9 Nov 2004 14:44:37 +0100

> my previous concerns, and I believe it's almost ready for publication.

Thanks. I would like for the draft to go to WGLC now. I think your
comments below can be addressed in a revised draft when WGLC is ended.

This is what I want to discuss in the meeting today,

Stig