Subject: RE: I-D ACTION:draft-privat-dhc-doublephase-01.txt

From: [email-masked]
Date: Fri, 1 Oct 1999 04:10:48 -0400 (EDT)

Thanks for your comments. See my answers below.

> I'm a bit confused as to why we would want to make a change as drastic as
> this to the clients, much more time intensive than a server change (i.e.,
> I prefer the proxy method much more).
	[Privat,J,Jerome] 
	I also prefer the proxy option as it does not require any client
changes and makes it easier to preserve
	the atomicity of the transaction. All the answers I got in private
emails also agree with that.

>   I think DHCP server A proxies to DHCP server B to get the options
> between DHCPDISCOVER & DHCPOFFER using LDAP or some other generic
> mechanism is a better approach.  While it is sometimes difficult to insert
> an extra processing step between discover & offer due to time constraints,
> it would not require massive client changes.
	[Privat,J,Jerome]
	In the proxy option, the draft proposes to use DHCP to do the
communication between the 2 DHCP servers
	[in a similar way as we would use a AAA protocol to do proxying
between AAA servers]. Another possibility,
	as you mention, would be to have server_1 do an ODBC or LDAP query
to server_2. Has anyboby a strong view on which
	of these two options is the best?
>   
> In section 5, also, the client is quite broken if something more than just
> the IP address, netmask and default gateway are not given.  You do specify
> the specific partitions to be outside the scope of the document; perhaps a
> warning indicating broken clients would be appropriate or a more complete
> fallback set of options?  What I'm getting at is some method of informing
> the user that their configuration is incomplete and should not expect full
> functionality.  (A special DNS server with a * RR that points to a default
> "your client is broken" website is a possibility, but perhaps beyond the
> scope of this document.)
	[Privat,J,Jerome] In normal operation, server_1 will be able to
retrieve information from server_2 and will therefore return
	a complete configuration to the client. But you are right there may
some conditions in which this is not possible. In this
	case, server_1 could in some way notify the client that its
configuration is incomplete. Or server_1 could return a local
	set of options. This would depend on agreement between the two
administrations.
	 
	Thanks,
	Jerome 
> Just some ideas that may help us all to better understand and use this
> effectively.
> 
> -Nathan Lane
> Senior Network Engineer
> Wal-Mart Stores, Inc.
> (501) 277-5786
> 
> > -----Original Message-----
> > From:	Thomas Narten [SMTP:[email-masked]]
> > Sent:	Wednesday, September 29, 1999 9:41 AM
> > To:	Multiple recipients of list
> > Subject:	FWD: I-D ACTION:draft-privat-dhc-doublephase-01.txt
> > 
> > Comments? Seems like a protocol change as much as a new option. The
> > option specifies that the client should also send additional DHCP
> > packets to a second server.
> > 
> > ------- Forwarded Message
> > 
> > From: [email-masked]
> > To: IETF-Announce: ;
> > Date: Wed, 29 Sep 1999 06:56:14 -0400
> > Subject: I-D ACTION:draft-privat-dhc-doublephase-01.txt
> > Reply-to: [email-masked]
> > 
> > --NextPart
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > 
> > 
> > 	Title		: Double Phase DHCP Configuration
> > 	Author(s)	: J. Privat
> > 	Filename	: draft-privat-dhc-doublephase-01.txt
> > 	Pages		: 4
> > 	Date		: 28-Sep-99
> > 	
> >

---

From: Richard Jones <[email-masked]>
Date: Wed, 6 Oct 1999 19:57:31 -0400 (EDT)

>Date: Fri, 1 Oct 1999 08:59:00 +0100
>From: [email-masked]
>To: [email-masked], [email-masked]
<Subject: RE: I-D ACTION:draft-privat-dhc-doublephase-01.txt
>Message-ID: <[email-masked]>
>

Count me as another vote for not requiring client behavior changes whenever
possible (except where they already violate the protocol!).

>> it would not require massive client changes.

The draft has the first server sending a DHCPINFORM message to the second one.
Not a problem, except that the second server is expected to use the subnet that
the request came in on (or the giaddr field in the packet) to determine the set
of configuration parameters that should be returned. In this case, the first
server would have to pretend to be a relay agent and create a request packet that
will be interpreted properly. Doable, certainly, but it seems like on a heavily
used
network it could mean a noticeable amount of overhead. The 'user-class' option
might take care of this when it gets more solid, but there could still be some
troublesome ambiguity concerning the origin of the request.

>       of these two options is the best?

I think a protocol should be restricted to defining the behavior of service
providers and consumers, and keep implementation requirements to a minimum
(or at least at the 'suggestion' level). In this draft, that means doing a
DHCPINFORM
is a good way to go, because there's no specification of how the servers handle
their own information - in fact, the two could each do it differently with
no conflict.

In the example in section 6, it appears that server 1 needs to be configured with
at least enough knowledge spanning service providers that it can decide from a
user class which 'server 2' to get more configuration info from. This means that
there is by definition some serious cooperation between the admins of the
various servers; why not centralize all of the configuration data?

>        set of options. This would depend on agreement between the two

RFC 2131 already talks about the problem of incomplete parameters coming
back to a client - it has always been a potential problem, if due to nothing
more than mis- or incomplete server configuration. It seems to me that all of the
functionality that this draft tries to specify can be implemented within the
current reach of the protocol - are any changes or additions
really necessary?

Regards,
Richard

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Thu, 7 Oct 1999 07:27:45 -0400 (EDT)

message sent to [email-masked] by [email-masked]
follows.
----------------------------------------------------------------------------
---
>Message-ID:
<[email-masked]>

The draft has the first server sending a DHCPINFORM message to the second one.
Not a problem, except that the second server is expected to use the subnet
that
the request came in on (or the giaddr field in the packet) to determine the
set
of configuration parameters that should be returned. In this case, the first
server
would have to pretend to be a relay agent and create a request packet that
will be

interpreted properly. Doable, certainly, but it seems like on a heavily used
network it could mean a noticeable amount of overhead.

I think a protocol should be restricted to defining the behavior of service
providers
and consumers, and keep implementation requirements to a minimum (or at least
at the 'suggestion' level). In this draft, that means doing a DHCPINFORM is a
good way to go, because there's no specification of how the servers handle
their
own information - in fact, the two could each do it differently with no
conflict.

In the example in section 6, it appears that server 1 needs to be
configured with
at least enough knowledge spanning service providers that it can decide from a
user class which 'server 2' to get more configuration info from. This means
that
there is by definition some serious cooperation between the admins of the
various servers; why not centralize all of the configuration data?

RFC 2131 already talks about the problem of incomplete parameters coming
back to a client - it has always been a potential problem, if nothing more
than
due
to mis- or incomplete server configuration. It seems to me that all of the
functionality
that this draft tries to specify can be implemented within the current
reach of
the
protocol - are any changes or additions really necessary?

Regards,
Richard

---

From: Richard Jones <[email-masked]>
Date: Thu, 7 Oct 1999 11:41:57 -0400 (EDT)

Thank you, Ralph! I'm currently having some problems with the list server,
having been subscribed long before under a different email address. I've
repeated the unsubscribe/subscribe ritual this morning, and will see if that
helps... If not, may I contact you again for assistance?

Regards,
Richard