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

On Mon, Sep 06, 2004 at 10:43:27AM +0200, Stig Venaas wrote:
> On Sat, Sep 04, 2004 at 12:33:37PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> > >>>>> On Fri, 3 Sep 2004 10:34:50 +0200, 
> > >>>>> Stig Venaas <Stig.Venaas@uninett.no> said:
> > 
> > > 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.
> > 
> > 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.

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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg