Subject: RE: general releasable resources?

From: Richard Draves <[email-masked]>
Date: Wed, 8 Dec 1999 18:05: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.

Defer their specification until later.

Thanks,
Rich

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 8 Dec 1999 18:05:41 -0500 (EST)

Mike, Ralph, et al.,

Inasmuch as we've only determined one releasable resource, the IP address,
to date, I'm in favor of making a first pass at the general solution now:
the existence of a versioning mechanism makes it possible for us to replace
(or augment) such a mechanism in the future if our operating experience
isn't great.

I also favor approach 'A' with an extension header that identifies the
resource as being releasable.

However, I think there is one issue we must resolve first:  why must a
client request a releasable resource, but not be required to explicitly
request non-releasable ones?  If some extensions are intended to always be
supplied by a server, are these specified in one of the drafts?  I actually
favor a scheme where clients explicitly request all extensions that they
desire, with the server supplying any that are required because of [other]
protocol requirements or local site policy.  I just want to see the language
about what is and which ones are automatically provided and which ones must
be requested to be unambiguous in the RFCs.

--Barr

---

From: Thomas Narten <[email-masked]>
Date: Thu, 9 Dec 1999 09:17:33 -0500 (EST)

> be requested to be unambiguous in the RFCs.

My understanding of the reason for requiring that client's explicitly
request releasable resources is to avoid the problem in DHCPv4 where
it is problematical for the server to send options that the client
doesn't understand.

I too share your concern that one of the benefits of DHCP is allowing
the sys admin to say (via a configuration in the server) here is what
I want the client to have, independent of what the client actually
requests. So, maybe what is needed is not that the client explicitely
request a releasable resource, but a way for the client to indicate
that it supports a particular resource, should the server choose to
send it. But even that may be unnecessarily restrictive.

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 9 Dec 1999 11:41:51 -0500 (EST)

> send it. But even that may be unnecessarily restrictive.

I think this is a good formulation.  Assuming we have an
"extension request extension", it would be simple for a client
to include the resources it can support receiving from the server.
If the server is not configured to send the resource, the client
cannot force it to do so.

Regards,
Charlie P.

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Wed, 15 Dec 1999 17:13:04 -0500 (EST)

> it is problematical for the server to send options that the client

Mostly correct. Clients in DHCPv4 were supposed to ignore options that they
didn't recognize. Unfortunately, some client vendor's implementations fell
over if they got options they didn't request or expect. That left server
vendors grappling with increasingly complicated schemes to control what client
got what options, etc.

My personal opinion is that the original design of the protocol was correct;
clients MUST ignore options they don't recognize/request. Since some
implementors got this wrong, RFC 2131 must not have been clear enough
regarding this point.

v6 is different in that we have been discussing releasable resources in
addition to IP addresses. Since these resources are "releasable", a client
would need to accept some responsibility for managing that resource. Thus, at
Minneapolis, the WG decided that resources which require management by the
client should only be returned if the client requests them, thus communicating
to the server the client's ability to properly "care" for that resource.
Nonreleasable (informational) extensions could either be requested or always
sent depending on the administrator's policy decisions. It's very important
that we get this text right in V6 such that client implementors understand
that they MUST be prepared to receive informational extensions they didn't
request and may not understand, and *ignore* it. > 
> send it. But even that may be unnecessarily restrictive.

Well, you don't give kittens to kids that aren't responsible enough to care
for them. ;^)

> Thomas

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
Mailstop UBUR02-212
One Network Drive
Burlington, MA 01803