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

["Cristian Cadar" <[e-mail]>]

Hi Bernie,

I have seen clients implementation as well which supported SMTP/POP3
option. I would like to integrate this
option in our DHCPv6 full-fletched implementation both in our server and
client. Since our prototype is currently tested
within the JOIN project (see
http://www.electronicsweekly.com/articles/article.asp?liArticleID=36721&
liFlavourID=1 ) we would 
consider a good idea to delegate this information with DHCPv6 as well.

Cristian


-----Original Message-----
From: Bernie Volz [mailto:[e-mail]] 
Sent: Wednesday, March 09, 2005 3:26 PM
To: Cristian Cadar; 'Van Aken Dirk'; 'Ted Lemon'
Cc: [e-mail]
Subject: RE:
[dhcwg]Commentsondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc
-opt-imap-00.txt

Yes, I'm sure a lot of servers implement it since it really isn't an
issue for them to do so - it is just one more IP-address list option.

- Do you have a requirement for this option? Are you presently using it
for
DHCPv4 (I don't just mean configuring in the DHCPv4 server, but
expecting clients to make use of it)?
- Do you know if it is in actual use (again, clients using the values
received from a DHCPv4 server) anywhere?

- Bernie

> -----Original Message-----
> From: Cristian Cadar [mailto:[e-mail]]
> Sent: Wednesday, March 09, 2005 4:06 AM
> To: Bernie Volz; Van Aken Dirk; Ted Lemon
> Cc: [e-mail]
> Subject: RE: 
> [dhcwg]Commentsondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft
-cadar-dhc-opt-imap-00.txt
> 
> Hi there,
> 
> From my experience I know for sure that you can find the SMTP option 
> in the most DHCP servers for Windows and Unix OS. In my opinion the 
> usage of this option should be decided by the network administrators.
> I don't think that we have a correct survey on how frequently this 
> option is used in reality. I agree with you that this option is not 
> heavily used in comparison with the DNS one for instance, but having 
> this option among the configurable DHCPv6 options would be an asset in

> my opinion than a burden.
> 
> Bernie- we can discuss on the format of this option.
> 
> 
> Cristian
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf

> Of Bernie Volz
> Sent: Tuesday, March 08, 2005 11:32 PM
> To: 'Van Aken Dirk'; 'Ted Lemon'; Cristian Cadar
> Cc: [e-mail]
> Subject: 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: [e-mail]
> [mailto:[e-mail]] On Behalf
> 
> > Of Van Aken Dirk
> > Sent: Sunday, August 01, 2004 2:50 PM
> > To: Ted Lemon; Cristian Cadar
> > Cc: [e-mail]
> > 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: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of Ted Lemon
> > > Sent: vrijdag 30 juli 2004 18:33
> > > To: Cristian Cadar
> > > Cc: [e-mail]
> > > 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
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/dhcwg
> > > 
> > 
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg