Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt)

From: Stig Venaas <[email-masked]>
Date: Wed, 1 Sep 2004 14:30:29 +0200

On Wed, Sep 01, 2004 at 01:01:51AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Tue, 24 Aug 2004 11:08:14 -0400, 
> >>>>> Ted Lemon <[email-masked]> said:
> 
> > However, let's consider your scenario a little more closely.   You 
> > acquire some information from the DHCP server.   Subsequently, for some 
> > reason, it becomes impossible for the server to respond to the client.
> 
> > I have a couple of observations about this.   First, the time at which 
> > it becomes impossible for the server to respond is not the same as the 
> > time at which the client attempts to refresh its configuration 
> > information.   The two events are unrelated.
> 
> Okay, I concur on this.  I also see that the scenario might differ
> based on whether the client moves to a new link or it stays in the
> same link.

What you write sounds reasonable, but I'm still not sure we should go
into the details. The reason is that we don't know in general what
the behaviour should be, and it's a generic issue. It's obviously a
related issue though. We could as Ted suggests, specify this later
when we have more information. That could either be as an update to
the lifetime RFC, or IMO perhaps better, add some text if an update
to RFC 3315 is done. There seems to be other reasons to update RFC
3315 too (draft-jinmei-dhc-dhcpv6-clarify-auth-00?).

In general I agree with your distinction between still and moving
clients. What worries me though, is that it might not be possible for
a client to distinguish between movement and renumbering. The fact
that a new prefix is announced in RAs is not sufficient.

Stig

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 01 Sep 2004 23:52:32 +0900

>>>>> On Wed, 1 Sep 2004 14:30:29 +0200, 
>>>>> Stig Venaas <[email-masked]> said:

> 3315 too (draft-jinmei-dhc-dhcpv6-clarify-auth-00?).

I would first like to note that the suggestion by Ted of leaving it to
a later document was followed by his response to me where he agreed
(or at least seemed to agree) with my proposal.

Secondly, if I understand the sense in this list correctly, I believe
my proposal reflects some level of consensus here.

Third, I personally think we can reflect the proposal without making
the document unnecessarily long.  (If you want, I'll try to contribute
to some text.)

So, I personally think it makes sense to clarify the points at this
chance even though the points can be extended to general issues.

...but I don't want to delay this important work due to my pedantic
ego.  If others still want to leave those points to other documents,
I'll obey that decision (but at least I want the "lifetime" document
to mention those a bit and to say that those are beyond the scope of
the doc).

> that a new prefix is announced in RAs is not sufficient.

As I said in my previous message, I basically think we can concentrate
on the "still" clients in this document, and do not have to worry
too much about miscellaneous subtle cases of moving vs
not-actually-moving.  Movement detection is itself a difficult
challenge (we even have a dedicated wg on this!), so I think it is
enough in the scope of dhc wg to show some preliminary considerations
on the moving clients (e.g., as shown in Section 18.1.2 of RFC3315.).

Besides, I don't see an actual problem in that particular case you
raised above, along with my proposed approach.  If the client
misunderstands that it has moved to a different link while it
actually stays in the same link, the client will resend an
Information-request message immediately based on the proposed
scenario.  In this case, however, the legitimate DHCPv6 server should
still be there and will respond to the Information-request with valid
configuration information.  (request storm might be an issue, but
confusing events like renumbering should be rare).

On the other hand, if the client misunderstands that it stays in the
same link while it has actually moved, the client will perhaps have a
trouble.  Along with the proposed approach, however, I think we don't
have to worry about that within the scope of this document; we'll
basically note that issues regarding moving clients are difficult and
will need future analysis.

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Sep 2004 10:13:29 -0700

On Sep 1, 2004, at 5:30 AM, Stig Venaas wrote:
> What worries me though, is that it might not be possible for

I would like to point out the work that they're doing in the DNA 
working group.   This is what I had in mind when I spoke earlier about 
detecting that the client had moved.   This work does not depend on 
noticing differences in RA messages.

---

From: Robert Elz <[email-masked]>
Date: Fri, 03 Sep 2004 04:13:07 +0700

Date:        Wed, 01 Sep 2004 23:52:32 +0900
    From:        JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
		 <[email-masked]>
    Message-ID:  <[email-masked]>

  | ...but I don't want to delay this important work due to my pedantic
  | ego.  If others still want to leave those points to other documents,
  | I'll obey that decision (but at least I want the "lifetime" document
  | to mention those a bit and to say that those are beyond the scope of
  | the doc).

There's no question of ego here.

The document is logically incomplete and meaningless if there's no
discussion (either in the document, or in a companion) of what happens
when a renewal attempt fails to achieve what was expected.

It is all obvious what to do when a "renewal" info request gets back the
same data as last time - even perhaps when it gives back that data, and
more.   It may even be fairly obvious (if not quite as obvious) what to
do if there's no reply at all (dead dhcp server, or node moved to a location
where there is no server).

Dealing with replacement data (conceptually anyway) isn't hard to understand
(in some cases it might be hard to implement) - ut dealing with getting an
answer with some data missing is quite a different thing - it clearly isn't
the same case as not getting an answer at all.

Once again, the relevance of this to this doc is just that this doc is
incomplete without that extra detail specified somewhere.   It is however
totally irrelevant what causes the new request to be made - whether it is
the expiration of one timer or another, or the detection of some kind of
"connected to a different link" signal, or even the (let's hope it is
defunct) proposal where the server sent out messages to clients telling
them to ignore previous timers and renew now.

Because of this, having the specification in a different (referenced,
and a normative ref at that) doc is an entirely reasonable thing to do.

But moving forward with this "explicitly demand refresh" doc without
any indication what should be done if it fails is simply not good enough.

kre

---

From: Stig Venaas <[email-masked]>
Date: Fri, 3 Sep 2004 10:34:50 +0200

> (or at least seemed to agree) with my proposal.

Yes

> my proposal reflects some level of consensus here.

Yes, my impression too. Note that I'm saying that I don't think we
should go into details, I think it's reasonable to write something.
I just think that this document isn't the right place to solve that
issue. Also, since the issue is present when not implementing this
draft, I believe it's good to specify some text in a place where it
will be read by those not implementing this option.

> chance even though the points can be extended to general issues.

Yes, so I would suggest adding some text, see suggestion below, that
raises the issue and gives some general recommendation, without
being too strict (no MUSTs).

> to mention those a bit and to say that those are beyond the scope of

The latter part I agree with. I really welcome your comments, I don't
always agree with them, but you have raised many interesting issues,
and helped improve the draft.

> on the moving clients (e.g., as shown in Section 18.1.2 of RFC3315.).

Right.

[Deleted some text below that I agree with]

So how about something like this:

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 install that new configuration
information after removing any previously received configuration
information.  There may be reasons not to always do this.  One
example might be when client has indication that it has moved to
a new link.  How a client copes with movement is outside the scope
of this document.

I'm not not sure if it should be "SHOULD" or "should" there. At
least I don't see this as part of the protocol. In my opinion
the idea is just to give a general recommendation or some guidance
to implementors.

Stig

---

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

>>>>> On Fri, 3 Sep 2004 10:34:50 +0200, 

> the idea is just to give a general recommendation or some guidance

The proposed text basically looks fine.  But I'd be a bit more
specific that the above description means if the new configuration
information does not have any update on a particular instance of the
old information (e.g., DNS server list) the client will simply remove
the old information.

As for "SHOULD" vs "should", I don't have a strong opinion.  If you
prefer "should", please just go for it.

					JINMEI, Tatuya

---

From: Stig Venaas <[email-masked]>
Date: Mon, 6 Sep 2004 10:43:27 +0200

> old information (e.g., DNS server list) the client will simply remove

Note that I say "after removing any previously received configuration
information". To me at least, that says that ALL the previously
received data is removed when receiving new information. It doesn't in
any way say that this is on a per option basis. E.g. if you previously
received options A, B and C, and you in the new message receive only a
new option D, then you should still remove previous information (A, B
and C).

But, if you still think this is not clear, I will try to improve it. If
it's not clear to you, then it may not be clear to others either.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 7 Sep 2004 11:00:29 +0200

> > old information (e.g., DNS server list) the client will simply remove

Since I felt the need to explain further what I meant, I should put
something in the draft too. I've now changed it to this:

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 install that new configuration
information after removing any previously received configuration
information.  Note that it should also remove information that
is missing from the new information set, e.g. an option might be
left out or contain only a subset of what it did previously.
There may be reasons not to always do this.  One example might
be when client has indication that it has moved to a new link.
How a client copes with movement is outside the scope of this
document.

Stig

---

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

> How a client copes with movement is outside the scope of this

Should "does not contain a Status Code option" be replaced with "does not 
contain a negative Status Code option"?  A status code of 0 should be 
acceptable.

Otherwise, this text looks good.

Joe.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 9 Sep 2004 14:11:34 +0200

> Otherwise, this text looks good.

Negative is a bit misleading perhaps since the values are not
negative, but I see what you mean. We could say non-zero or that
the code is not "success".  Or perhaps just remove the "i.e.".

Unfortunately I just submitted 02 version of the draft, and forgot
to consider this. This is easy to fix later though.

Stig