Subject: WG: general releasable resources?

From: "Michael W. Carney" <[email-masked]>
Date: Wed, 8 Dec 1999 16:37:11 -0500 (EST)

Well, we've talked alot about general releasable resources and what
their semantics might be (summary below).

The question I have for the WG is:

Do we attempt to specify general releasable resources now, or should we
defer their specification till later if we find them useful?

Please respond with your preference.

Thanks!

"Michael W. Carney" wrote:
> 
> Ralph Droms wrote:
> >
> > At 06:49 PM 11/30/99 -0500, Michael W. Carney wrote:
> > >The discussion clearly showed that support for releasable resources was
> > >something that the WG wanted. That said, what would be the semantics
> > >that would resolve the issues raised during the discussion of this
> > >question? It is this point I'm attempting to address.
> >
> > Mike - Which discussion are you referring to, here?  IMO, we initiated
> > the discussion of releasable resources on the mailing to explore the
> > complexity of adding support to DHCPv6 for releasable resources, so we
> > could make an informed engineering decision about whether or not to
> > incorporate releasable resources into the spec.  We have had a good
> > discussion about how releasable resources might work and how they might
> > be supported in DHCPv6, but I don't think we've had an expression of
> > consensus about whether we want to go ahead and add releasable resources
> > to the spec.
> 
> I fear I may have jumped ahead alittle. You are right. I believe are
> close to having the semantics completely defined such that general
> support for releasable resources is possible.
> 
> Those semantics are:
> 
> Either one of the following:
> 
> a) Extensions all have a "generic" header portion of which there are
> bits which are present in all extensions. One such bit would indicate
> that the resource carried in the extension is releasable, and that there
> are two fields in the extension (a'la lifetimes in the IP address
> extension) which represent the "preferred" and "absolute" lifetimes
> represented in seconds relative to the transaction. (now).
> 
> b) A range of extensions is carved out and used for releasable
> extensions. The fact that the extension is releasable is a
> characteristic of the extension's code value.
> 
> Client implementations (scheme a or b)
> 
>         - Must request releasable resources - via extension request extension
> in solicit.
> 
>         - Will track owner of such resources and SHOULD release them to the
> allocating server, and MAY release them to another server if the
> allocating server is unreachable.
> 
>         - A client will attempt to update the lifetimes on the releasable
> resource if necessary. However, if the lifetimes expire, the resource
> must be considered no longer usable. There's an interesting point -
> since the DHCP client won't deal with most releasable resources, it will
> not have control over whether or not a resource continues to be used
> when the lifetime expires, whereas it certainly has control over IP
> addresses acquired through DHCP.
> 
>         - A releasable resources can be reconfigured (again, the client
> probably won't have the necessary control of the resource in order to
> prevent its use, with the current exception of IP addresses).
> 
> Server implementations (scheme a or b)
> 
>         - Must have a generic mechanism for dealing with releasable resources.
> 
>         - A server will only advertise releasable resources if the client
> requests it to do so in the Solicit.
> 
>         - A server controls a client's access to releasable resources based
> upon the lifetimes associated with these resources.
> 
> So I think this is mostly it in summary. The potential inability of the
> client to enforce access to expired releasable resources is an issue.
> 
> If folks believe I've covered the required semantics / caveats of
> general releasable resources, the question is: Do we try to specify
> general releasable resources now, or should we defer till later if we
> find them useful?
> 
> >
> > - Ralph
> 
> --
> 
> Mike Carney

-- 

Mike Carney

---

From: Ralph Droms <[email-masked]>
Date: Thu, 9 Dec 1999 11:42:05 -0500 (EST)

>defer their specification till later if we find them useful?

The work we've done in defining releasable resources has convinced me
that the cost of adding releasable resources to the protocol spec (including
additional work to complete the definition, add text to the spec and
confirm the correctness of the spec) and
implementation outweighs the potential benefit - especially
as the only example of a releasable resource we've come up with
to date has been IPv6 addresses.

I would suggest we leave hooks for future definition of releasable
resources in the spec and defer additional work on releasable resources
until we have a more compelling case in support of them.

- Ralph

---

From: Francis Dupont <[email-masked]>
Date: Thu, 9 Dec 1999 12:52:19 -0500 (EST)

In your previous mail you wrote:

=> I believe a part of your statement is missing (and you think this cost
is too high).

=> I agree: I prefer a working DHCPv6 spec ASAP.

Thanks

[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Thu, 9 Dec 1999 13:44:58 -0500 (EST)

>=> I believe a part of your statement is missing (and you think this cost

I meant to imply that the cost is "too high" with the phrase "outweighs the
potential benefit"...

- Ralph