RE: [dhcwg] Commentsondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt-imap-00.txt

In preparing for IETF-62 I dug up this old discussion and I second Ted's
question. I really don't see this as something coming from DHCP -- it really
is specific to the user, not the client, and isn't really access-point
specific (as most DHCP information is).

As we have DHCPv4 options (69 for SMTP and 70 for POP3), I would first ask
how widely used are these options? Are they supported by any clients? Are
they configured in any DHCPv4 servers?

If the answer is that they are heavily used, I'm all for adopting them for
DHCPv6. But if the answer is that they're basically never used, why do you
now feel they'll be used for DHCPv6?

Perhaps at the Thursday AM DHC WG session you can address this usage
question as that might gave the WG important information as to whether these
options are warranted for DHCPv6 or not.

Also, if we were to consider these options, how about a more general format
so we don't need a new option for every application that comes along?

For example, you could define a "default application server option" which
would be formatted as:
	well-known-service-port-number (2 bytes)
	length or number of addresses to follow (1 or 2 bytes)
	ipv6 addresses
And this could repeat. Now we have one option into which we can bundle up
all of the servers and when someone else comes along wanting to provide
clients the addresses for server foo, no new option need be written (and
implemented).

Well, just an idea ... It does complicate the configuration at the servers
and parsing at the clients.

If we do move forward with your work, I'd like to see more explicit text
around ORO requirements. I think this option *MUST* be requested in the ORO
receive from the client before a server would return it.

- Bernie

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Van Aken Dirk
> Sent: Sunday, August 01, 2004 2:50 PM
> To: Ted Lemon; Cristian Cadar
> Cc: dhcwg@ietf.org
> Subject: RE: [dhcwg] 
> Commentsondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-
> dhc-opt-imap-00.txt
> 
> Hello Ted, Cristian,
> 
> See some comments inline.
> 
> Best regards - Dirk
> 
> > -----Original Message-----
> > From: dhcwg-bounces@ietf.org 
> > [mailto:dhcwg-bounces@ietf.org]On Behalf Of
> > Ted Lemon
> > Sent: vrijdag 30 juli 2004 18:33
> > To: Cristian Cadar
> > Cc: dhcwg@ietf.org
> > Subject: Re: [dhcwg] Comments
> > ondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt-
> > imap-00.txt
> >  
> > I guess my first question about this is why?
> 
> I assume to come closer to zero-config of hosts and 
> applications I would say.
>     
> > Why would you want a client to trust the DHCP server to 
> tell you what IMAP server to 
> > contact?
> 
> Is this not true for all options that are returned by a server ?
> 
> >  What if you wind up talking to a rogue server, or roam to a 
> > different network?   These don't seem like things that are 
> > location-dependent - they seem like things that you want to 
> configure 
> > on the client and not change as the client moves around.
> 
> True, but on the other hand from the perspective of a system 
> admin, he/she must use two methods for host/application 
> configuration. That is, a DHCP server for a first set of 
> parameters and scripts or even manual config for other parameters.
> 
> > 
> > 
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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