Subject: RE: DC meeting: Discussion question #1, releasable resources

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 17 Nov 1999 19:40:29 -0500 (EST)

[Charlie Perkins]

> It seems to me that one of the sticking points in this discussion
> is some difficulty in imagining other releasable resources besides
> IP addresses.  I'd like to address that issue in two ways:
> 
> 1. I can imagine a _lot_ of releasable resources in the future, but
>    it would be a mistake to try to specify them before we can have
>    DHCPv6 as a Proposed Standard.  After that time, new extensions
>    to specify new releasable resources will come up for discussion
>    in a natural way, as long as we have a natural mechanism specified
>    for handling them.  Some possible examples of releasable resources:
>    = disk space
>    = network memory
>    = I/O devices
>    = Licensed software
>    = time-metered equipment
>    = ports
>    = protocol translators
> 
[Barr Hibbs]

I can think of a few interesting cases where parametric information supplied
by a server (which, by definition, is NOT a releasable resource, as it is
not "owned" by the DHCP server) might require treatment in a similar
fashion.

Consider a list of DNS server addresses.  Slow or no response from a
particular DNS server MAY be a good reason for a client to abandon use of
that server, and for a client to attempt to "replace" that address with
another one (especially if the server "list" contained only one address.)
In this case, the client is essentially saying to the server, "I can't use
an address you supplied me:  give me a replacement," which is not quite the
same thing as saying, "Please reconfigure me."

[Charlie Perkins]

> 2. However, in a way, imagining cool resources as in (1) even misses
>    the point.  I think the point is that DHCP is a way to configure
>    computers, and it seems clear to me that computers (especially
>    computers on networks) can be considered to be composed of  allocated
>    resources structured according to parametric values.  DHCPv6 makes
>    a nice way to collect such parameters and resources, after some
>    years of work.  I vote for keeping it that way.
> 
[Barr Hibbs]

This does seem to be a valid use of a DHCP server, so the question really
becomes "Is the proposed release mechanism appropriate for the [one known]
resource and likely parameters?"  Given that an answer is forthcoming, we
will also need to ask "What are the proposed semantics?" in order to
determine the [probable] complexity of implementations, which drives the
cost/benefit analysis.

[Jim Bound]

> > > Today we have no mechanism for servers to know about each others
> > > databases and entries.  So we assume that servers can't do this and
> say
> > > a client can keep the address of a server who gave them their address,
> > > because we know new servers can't "today" know about each others
> > > databases in a "standard" way.
> > 
> > > But..tomorrow it may be there is a standard way for servers to know
> > > about each other and clients can clearly just send the release to any
> > > server if that exists in Theory....if the standard exists.
> > 
> > > Here is a suggestion for discussion:
> > 
> > > 1.  Lets make the default that the client has no knowledge of servers
> > >     and can release addresses to the next server it hears (e.g.
> > >     reconfigure, reply, advertise [from reboot]).
> 
[Charlie Perkins]

> I think it would be better for clients, by default, to release resources
> to the server that allocated them.  We've already got this mechanism
> specified in the draft now.
> 
[Barr Hibbs]

While a server-to-server protocol for DHCPv6 MAY be developed in the future,
I think we are doing the larger community a huge disservice to predicate the
behavior of a DHCPv6 client and server today on the basis of unknown future
developments.  We need to specify something that will work without a
server-to-server protocol, with an eye towards its possible future
implementation, but not hold these drafts for months or years waiting on an
as-yet-to-be-started design effort.

[Jim Bound]

> > > 2.  But put a MAY in the protocol that permits clients to keep
> > >     the address of servers to later release addresses from where
> > >     it got them.
>  
[Thomas Narten]

> > This seems reasonable to me. I might even go a bit further and say
> > that a client SHOULD (?) keep track of one server, the one it most
> > recently got resources/parameters from and use that one first when
> > releasing resources. If that fails, fall back to finding and trying a
> > different server. I think this retains the spirit of what is on the
> > current draft but also provides more flexibility in the event that a
> > server-server protocol comes along.
> 
[Charlie Perkins]

> To me it seems natural to let clients release things to the server
> that allocated them by default, and if that isn't possible then the
> client MAY release them to the next server it knows about.
> 
> When a server-server protocol is designed, this can be evaluated again,
> but in the meantime it would be better to make things work in the
> logical way without such server coordination.
> 
[Barr Hibbs]

Absolutely!  Given that no inter-server protocol currently exists, I believe
that a client MUST release resources [well, the one we can agree on, anyway]
to the server who originally granted rights to it.  Otherwise, why even
bother with a release message?  I also believe that it is completely
appropriate to reconsider this approach in the future when an inter-server
protocol exists.

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 17 Nov 1999 20:12:42 -0500 (EST)

[Jim Bound]

> > databases and entries.  So we assume that servers can't do this and say
[Thomas Narten]

[Barr Hibbs]

I am definitely missing something in this discussion.  Why would you permit
a client to release a resource to a server that might have no knowledge of
it, and could simply discard the release message because it has no way to
determine/communicate with the owner of the resource?  How does permitting a
client to send a release message to the "next server that happens along"
represent an improvement over dropping the resource on the floor?