Subject: Re: [dhcwg] Re: one more comment about the lifetime option

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 02 Sep 2004 18:20:57 +0900

(forgot to reply to this...)

I've changed the order of the citation below.

>>>>> On Tue, 24 Aug 2004 20:55:14 -0400, 
>>>>> "Bernie Volz" <[email-masked]> said:

>> > We should also restrict the position where the lifetime option can
>> > appear: it should only be able to appear at the "top level" 
>> of option 
>> > hierarchy.
>> 
>> I think this is a good idea.

> If it is restricted to a REPLY to an INFORMATION-REQUEST, there is
> no need for this explicit statement as that's all that is currently
> possible - there are no IA_NA, IA_TA, or IA_PD options for these
> messages.

I don't think this is really the case.  An authentication option can
be used with Information-request and can have sub-options.

					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: "Bernie Volz" <[email-masked]>
Date: Thu, 2 Sep 2004 08:46:24 -0400

> An authentication 
> option can be used with Information-request and can have sub-options.

That's news to me and I don't see where this is possible based on RFC 3315.

But in any case, its no big deal to specify that the option is restricted to
the message level.

- Bernie

> -----Original Message-----
> From: JINMEI Tatuya / _–¾’BÆ [mailto:[email-masked]] 
> Sent: Thursday, September 02, 2004 5:21 AM
> To: Bernie Volz
> Cc: 'Ted Lemon'; [email-masked]
> Subject: Re: [dhcwg] Re: one more comment about the lifetime option
> 
> 
> > If it is restricted to a REPLY to an INFORMATION-REQUEST, 
> there is no 
> > need for this explicit statement as that's all that is currently 
> I don't think this is really the case.  An authentication 
> option can be used with Information-request and can have sub-options.
> 
> 					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 03 Sep 2004 15:35:10 +0900

>>>>> On Thu, 2 Sep 2004 08:46:24 -0400, 

> That's news to me and I don't see where this is possible based on RFC 3315.

Ah, okay, I was wrong.  The authentication option is a variable-length
option but does not take a sub-option according to RFC3315.

> But in any case, its no big deal to specify that the option is restricted to

That's correct.  But at the same time, I believe we all agree that
there is no reason to allow the lifetime (or refresh timer) option
appearing as a sub-option.

We can prefer the former logic for the reason not to specify this
point in the document.  We can also prefer the latter logic for the
reason to specify this point in the document.  I believe this is a
matter of taste, and I myself can live with either approach.  So, I'd
leave the decision to the document author.

					JINMEI, Tatuya

---

From: Stig Venaas <[email-masked]>
Date: Fri, 3 Sep 2004 09:56:17 +0200

> appearing as a sub-option.

Yes, I don't mind adding some wording to the fact. It's against the
whole idea to use it as a sub-option.

I must say though that I'm a little bit surprised this came up. I'm
not that into the world of DHCP, but I don't recall seeing specs for
other options saying this, and I had thought that they should only
be used as sub-options if specified as such. Or is the idea that in
general, any option could be used as a sub-option?

I think though that the IRT (lifetime) option might appear to make
sense as a sub-option, while many other options pretty obviously
don't make sense. So I'm happy to add the wording, just to avoid
possible misuse.

Stig

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 04 Sep 2004 15:20:27 +0900

>>>>> On Fri, 3 Sep 2004 09:56:17 +0200, 
>>>>> Stig Venaas <[email-masked]> said:

> general, any option could be used as a sub-option?

I think your understanding is basically correct.  RFC3315 says in
Section 22 that:

   Unless otherwise noted, each option may appear only in the options
   area of a DHCP message and may appear only once.

The term "options area" does not seem to be officially defined in the
RFC, but it should be natural to interpret this to mean areas which
are not a sub-option of a separate option.

But at the same time, the RFC explicitly mentions the default
restriction in some places.  For example, in Section 22.5 it says:

   An IA_TA option may only appear in the options area of a DHCP
   message.

And,

> don't make sense. So I'm happy to add the wording, just to avoid

this is exactly my point.

 I believe it depends on whether we want to avoid possible misuse
 explicitly.  And then it depends on how we asses the possibility of
 the misuse.  Of course, the sense on this may vary among people (so I
 won't push my preference).  But if we recall that we are talking
 about this in the context where we are trying to add a note that a
 single IRT (or lifetime) optin should be common for all possible
 information resources, I personally think it's reasonable to add an
 explicit note here.

					JINMEI, Tatuya

---

From: Joe Quanaim <[email-masked]>
Date: Tue, 7 Sep 2004 09:07:59 -0400

>  information resources, I personally think it's reasonable to add an

I also think it is worthwhile to add text limiting this option's position to 
the message options.

Joe.