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

[Stig Venaas <[e-mail]>]

On Wed, Sep 01, 2004 at 11:52:32PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Wed, 1 Sep 2004 14:30:29 +0200, 
> >>>>> Stig Venaas <[e-mail]> said:
> 
> > 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?).
> 
> 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.

Yes

> Secondly, if I understand the sense in this list correctly, I believe
> 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.

> 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.

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).

> ...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).

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.

> > 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.
> 
> 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.).

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

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