Subject: Re: [dhcwg] What sorts of services does DHCP configure?

From: "Simon Hobson" <[email-masked]>
Date: Wed, 16 Oct 2013 14:10:27 +0100

"Reinaldo Penno (repenno)" wrote:
Sten Carlsen wrote:
>> I tend to look at this from the opposite side, what are the services that need to be configured and infomation
>> that needs to be delivered? And as a consequence what are the tools?
>> What is in the toolbox now and what is missing? Some of the missing tools are leading to ugly hacks now.
>> The answer might not be DHCP, but then what is it?

> Agree with Sten.

I do too.

Looking back through the thread, I agree with Ted - we have options for things that it doesn't make sense for DHCP to configure. IMO I can see no use case for configuring IMAP like services - those are user-centric (or more importantly, user-account centric - there is a difference) and in the general case not connected to network location.

SMTP is similarly (IMO) generally user-account specific. When I'm sending mail, I will normally expect to use my "home" server for the account - which is the one server in the world that I can authenticate to and know that it will pass my outbound mail (not reject or block it because the email address isn't one accepted by whatever random SMTP server the DHCP config might supply).
As an aside, I believe Exchange client config is done initially by DNS - the client does a lookup for autoconfigure.<domain name> and requests the config from it. In a large corporate environment, it's possible that they simply setup difference autoconfig servers (I assume this is an integral part of Exchange but that's not something I've worked with) and configure the local DNS accordingly. Which leads on to ...

DNS. This is not as location agnostic as Ted makes out in his first post. IME it's far from rare to have different views of the DNS in different locations - so accessing web.mycompanyname.com in one office may well take you to a server close (in network terms) to the user. Move to a different office and this same FQDN may well resolve to a different IP. Anycast addressing could well achieve the same thing, but fiddling with the DNS is easier (and more understandable for a lot of people).

And then we get services like SIP.
For a "public" account then the config is again user-account specific - wherever I am I'll need to connect back to the same registrar. If the telephony provider has multiple SIP registrar servers then I may well be best connecting to whichever one is closest (in network terms) to me - but that's not something some random DHCP admin will have any knowledge of when setting up his server.
But there may well be corporate SIP implementations where DHCP is currently the best (or least bad ?) way of configuring things. For devices that are only intended to work within the corporate network, the various administrators could would out which SIP options to pass to a device depending on network location. But again, I think that such a config system would be better if separate from DHCP.

To finish, as has already been pointed out - much of this is "if we were starting from here we wouldn't do ..." - not because the original decisions were wrong in the context in which they were taken, but simply because things have changed dramatically over the years.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 16 Oct 2013 14:15:55 +0000

> To finish, as has already been pointed out - much of this is "if we were starting from here we wouldn't do ..." - not because the original decisions were wrong in the context in which they were tak…

And, I bet they'll change more over the next years.

When DHCP started it was mostly about configuring big machines that serviced many users. Today, most of the devices configured are tightly bound to a single user (though there are still lots of big machines too). I'm not saying we should be configuring user specific settings, but we don't know what the future might hold.

The option guidelines should focus on providing information we can safely provide, such as:
- Formats for encoding data into options.
- Rules about how to handle multiple instances (i.e., single option with multiple values is generally better than multiple options) and that order is not to be relied on when multiple instances of options exist.
- Client and server behavior for "simple" data only options (client adds to ORO, server responds if configured).

Any guidance we give for what is 'in scope' or 'out of scope' should be limited as this will be more fluid over the years.

Please don't flame this as I'm not suggesting user settings will be configured by DHCP.

The basic philosophy is that DHCP should be used for getting a DEVICE (client) connectivity to a network and network resources needed for connectivity, not to configure all of the services a USER might want to use.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Hobson
Sent: Wednesday, October 16, 2013 9:10 AM
To: [email-masked] WG
Subject: Re: [dhcwg] What sorts of services does DHCP configure?

Sten Carlsen wrote:
>> I tend to look at this from the opposite side, what are the services 
>> that need to be configured and infomation that needs to be delivered? And as a consequence what are the tools?

I do too.

To finish, as has already been pointed out - much of this is "if we were starting from here we wouldn't do ..." - not because the original decisions were wrong in the context in which they were taken, but simply because things have changed dramatically over the years.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 16 Oct 2013 16:48:32 +0200

> When DHCP started it was mostly about configuring big machines that serviced many users. Today, most of the devices configured are tightly bound to a single user (though there are still lots of big…
This makes me think of the Internet of Things. Would the configuration
of all those things be done over DHCP and another question, who will
decide those configurations?

I ask because I do not know how this will work out, I expect nobody is
certain about it but some informed guessing is better than none.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Oct 2013 10:51:47 -0400

> The basic philosophy is that DHCP should be used for getting a DEVICE (client) connectivity to a network and network resources needed for connectivity, not to configure all of the services a USER m…

Yup, that's my thinking as well.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 16 Oct 2013 15:01:17 +0000

> This makes me think of the Internet of Things. Would the configuration of all those things be done over DHCP and another question, who will decide those configurations?

That's exactly my point about the future - we just don't know what will come down the road. And in a "home" network, DHCP might well be a good thing to use for some future application for the IoT or IoE (Everything).

Again ... The basic philosophy is that DHCP should be used for getting a DEVICE (client) connectivity to a network and network resources needed for connectivity, not to configure all of the services a USER might want to use.

USER here is probably changing as well since a "refrigerator" or "washing machine" is not a USER as we traditional think about it. And, while perhaps not "low power" in these examples, at least some of these devices are certainly likely to be somewhat limited in their capabilities.

So, perhaps my basic philosophy statement needs to be revised:

The basic philosophy is that DHCP should be used for getting a DEVICE (client) connectivity to a network and network resources needed for connectivity, not to configure all of the services the DEVICE or a USER of the DEVICE might want to use.

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sten Carlsen
Sent: Wednesday, October 16, 2013 10:49 AM
To: [email-masked]
Subject: Re: [dhcwg] What sorts of services does DHCP configure?

When DHCP started it was mostly about configuring big machines that serviced many users. Today, most of the devices configured are tightly bound to a single user (though there are still lots of big machines too). I'm not saying we should be configuring user specific settings, but we don't know what the future might hold.
This makes me think of the Internet of Things. Would the configuration of all those things be done over DHCP and another question, who will decide those configurations?

I ask because I do not know how this will work out, I expect nobody is certain about it but some informed guessing is better than none.

- Bernie

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Simon Hobson

To: [email-masked]<mailto:[email-masked]> WG

Sten Carlsen wrote:

Agree with Sten.

I do too.

dhcwg mailing list

[email-masked]<mailto:[email-masked]>

dhcwg mailing list

[email-masked]<mailto:[email-masked]>

--

Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 16 Oct 2013 17:10:16 +0200

On 16/10/13 17:01, Bernie Volz (volz) wrote:
>
> > This makes me think of the Internet of Things. Would the
> configuration of all those things be done over DHCP and another
> question, who will decide those configurations?
>
>  
>
> That's exactly my point about the future -- we just don't know what
> will come down the road. And in a "home" network, DHCP might well be a
> good thing to use for some future application for the IoT or IoE
> (Everything).
>
>  
>
> Again ... The basic philosophy is that DHCP should be used for getting
> a DEVICE (client) connectivity to a network and network resources
> needed for connectivity, not to configure all of the services a USER
> might want to use.
>
>  
>
> USER here is probably changing as well since a "refrigerator" or
> "washing machine" is not a USER as we traditional think about it. And,
> while perhaps not "low power" in these examples, at least some of
> these devices are certainly likely to be somewhat limited in their
> capabilities.
>
>  
>
> The basic philosophy is that DHCP should be used for getting a DEVICE
> (client) connectivity to a network and network resources needed for
> connectivity, not to configure all of the services the DEVICE or a
> USER of the DEVICE might want to use.
>
Or the USER wants the DEVICE to use. (Like what to send to whom etc.)

Ok, so far I don't disagree.

We could make 2 lists to get on:
1 - those configurations that we think DHCP must provide and those it
should provide
2 - All the other configurations that today are handled by DHCP that we
think don't belong there.

The problem then becomes to define where list 2 should/could be dumped?
Assuming the floor is not really acceptable.
>
>  
>
> -          Bernie
>
>  
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Sten Carlsen
> *Sent:* Wednesday, October 16, 2013 10:49 AM
> *To:* [email-masked]
> *Subject:* Re: [dhcwg] What sorts of services does DHCP configure?
>
>  
>
>  
>
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Simon Hobson
> To: [email-masked] <mailto:[email-masked]> WG
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Oct 2013 11:14:53 -0400

> I ask because I do not know how this will work out, I expect nobody is certain about it but some informed guessing is better than none.

I think you could ask about this in the 6lo, core and dice working groups and get some informative answers.   This is a topic about which there has been substantial discussion, and those working groups are where the experts hang out.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 16 Oct 2013 15:17:18 +0000

Right, I think we are on the same page.  Dumping on the floor (2) should be avoided in order to provide a hand-off.

As we go through this exercise we might find a few nuggets that blue the line between USER and DEVICE and that might be interesting to look at so our decisions as well founded.

From: Sten Carlsen <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 16, 2013 8:10 AM
To: "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] What sorts of services does DHCP configure?

> This makes me think of the Internet of Things. Would the configuration of all those things be done over DHCP and another question, who will decide those configurations?

That’s exactly my point about the future – we just don’t know what will come down the road. And in a “home” network, DHCP might well be a good thing to use for some future application for the IoT or IoE (Everything).

Again … The basic philosophy is that DHCP should be used for getting a DEVICE (client) connectivity to a network and network resources needed for connectivity, not to configure all of the services a USER might want to use.

USER here is probably changing as well since a “refrigerator” or “washing machine” is not a USER as we traditional think about it. And, while perhaps not “low power” in these examples, at least some of these devices are certainly likely to be somewhat limited in their capabilities.

We could make 2 lists to get on:
1 - those configurations that we think DHCP must provide and those it should provide
2 - All the other configurations that today are handled by DHCP that we think don't belong there.

The problem then becomes to define where list 2 should/could be dumped? Assuming the floor is not really acceptable.

-          Bernie

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Sten Carlsen
Sent: Wednesday, October 16, 2013 10:49 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] What sorts of services does DHCP configure?

- Bernie

-----Original Message-----

Sten Carlsen wrote:

Agree with Sten.

I do too.

dhcwg mailing list

dhcwg mailing list

--

Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

--
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Oct 2013 11:26:07 -0400

> The problem then becomes to define where list 2 should/could be dumped? Assuming the floor is not really acceptable.

We don't need to go that far.   The reason I asked this question is that there was strong pushback from the apps area on the recommendation against using FQDNs in DHCP options.   We propose to make the language clearer, but wanted to see what the working group thought about it.

Whether some apps get configured using DHCP or not, the question is, should we make recommendations that assume that this is the common use case for DHCP options, or is the common use case for DHCP options what you and Bernie seem to agree it is: configuring devices.

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 16 Oct 2013 17:50:19 +0200

> Whether some apps get configured using DHCP or not, the question is, should we make recommendations that assume that this is the common use case for DHCP options, or is the common use case for DHCP…
I was also thinking that making those two lists would probably not take
too much time but might be a tool to get the overview and a clearer
picture; as well as put everyone on the same page?

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Oct 2013 13:40:58 -0400

On Oct 16, 2013, at 11:50 AM, Sten Carlsen <[email-masked]> wrote:
> I was also thinking that making those two lists would probably not take too much time but might be a tool to get the overview and a clearer picture; as well as put everyone on the same page?

There's a really easy way for you to put this theory to the test... ;)

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 17 Oct 2013 02:39:53 +0200

> There's a really easy way for you to put this theory to the test... ;)
Ok, start of list 1, things I would like to get fromDHCP:
IP/prefix
subnet-mask
lease-time
routers
domain-name-server
domain-name
next-server for PXE boot
DDNS updates connecting IP and name

List 2, things I want to be available, somehow:
netbios-node-type required for this network
ntp-servers
Servers / proxies for things blocked by the firewall

This is the start of MY list, please fill out with your preferences. :-)

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 17 Oct 2013 00:50:00 +0000

>The basic philosophy is that DHCP should be used for getting a DEVICE (client)
>connectivity to a network and network resources needed for connectivity, not
>to configure all of the services a USER might want to use.

Agree.

Now, the question will be whether all configuration can be clearly categorized into network connectivities or user services. I guess, there may be controversy for some network connectivities that may open for specific services.

Sheng

>Looking back through the thread, I agree with Ted - we have options for
>things that it doesn't make sense for DHCP to configure. IMO I can see no use
>case for configuring IMAP like services - those are user-centric (or more
>importantly, user-account centric - there is a difference) and in the general
>case not connected to network location.
>
>SMTP is similarly (IMO) generally user-account specific. When I'm sending
>mail, I will normally expect to use my "home" server for the account - which is
>the one server in the world that I can authenticate to and know that it will
>pass my outbound mail (not reject or block it because the email address isn't
>one accepted by whatever random SMTP server the DHCP config might
>supply).
>As an aside, I believe Exchange client config is done initially by DNS - the client
>does a lookup for autoconfigure.<domain name> and requests the config
>from it. In a large corporate environment, it's possible that they simply setup
>difference autoconfig servers (I assume this is an integral part of Exchange
>but that's not something I've worked with) and configure the local DNS
>accordingly. Which leads on to ...
>
>DNS. This is not as location agnostic as Ted makes out in his first post. IME it's
>far from rare to have different views of the DNS in different locations - so
>accessing web.mycompanyname.com in one office may well take you to a
>server close (in network terms) to the user. Move to a different office and this
>same FQDN may well resolve to a different IP. Anycast addressing could well
>achieve the same thing, but fiddling with the DNS is easier (and more
>understandable for a lot of people).
>
>For a "public" account then the config is again user-account specific -
>wherever I am I'll need to connect back to the same registrar. If the telephony
>provider has multiple SIP registrar servers then I may well be best connecting
>to whichever one is closest (in network terms) to me - but that's not
>something some random DHCP admin will have any knowledge of when
>setting up his server.
>But there may well be corporate SIP implementations where DHCP is currently
>the best (or least bad ?) way of configuring things. For devices that are only
>intended to work within the corporate network, the various administrators
>could would out which SIP options to pass to a device depending on network
>location. But again, I think that such a config system would be better if
>separate from DHCP.
>
>
>To finish, as has already been pointed out - much of this is "if we were starting
>from here we wouldn't do ..." - not because the original decisions were wrong
>in the context in which they were taken, but simply because things have
>changed dramatically over the years.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Oct 2013 23:35:41 -0400

> Now, the question will be whether all configuration can be clearly categorized into network connectivities or user services. I guess, there may be controversy for some network connectivities that m…

If there is no controversy in _this_ working group, that answers the question I was requested to ask.   We are trying to figure out what the DHC working group's position is on this question, not what the IETF as a whole's position is on it.   The Option Guidelines document is essentially advice from the DHC working group to the IETF, and that's something the IESG seems happy with (the reception of this document was pretty enthusiastically positive).

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 17 Oct 2013 03:55:27 +0000

>> Now, the question will be whether all configuration can be clearly
>categorized into network connectivities or user services. I guess, there may
>be controversy for some network connectivities that may open for specific
>services.
>
>If there is no controversy in _this_ working group, that answers the question I
>was requested to ask.   We are trying to figure out what the DHC working
>group's position is on this question, not what the IETF as a whole's position is
>on it.   The Option Guidelines document is essentially advice from the DHC
>working group to the IETF, and that's something the IESG seems happy with
>(the reception of this document was pretty enthusiastically positive).

My concern is for DHC WG, too.

Taking a more specific example, "Distributing Address Selection Policy using DHCPv6", draft-ietf-6man-addr-select-opt. For now, this draft only propagates generic address selection policy. It is little controversy to be DHCPv6 configuration, in my eyes.

However, it is very likely this would develop further in the future, to become "if you want to connect to Service/Application X, choose source address A". For that, I am not sure it falls into network connectivities or user services.

Regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Oct 2013 00:00:19 -0400

> Taking a more specific example, "Distributing Address Selection Policy using DHCPv6", draft-ietf-6man-addr-select-opt. For now, this draft only propagates generic address selection policy. It is li…

It's pretty clear to me that this option is not a very good idea in most cases.   I don't think the DHC working group is in a position to say no to it, but we are certainly in a position to say "this isn't a good general solution to the source address selection problem."

Of course, there are constrained environments where it may make sense—e.g., in a PE router<->CE router situation.  But this is not something that ought to be enabled on all DHCP clients.

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 17 Oct 2013 05:42:12 +0000

>It's pretty clear to me that this option is not a very good idea in most cases.
>I don't think the DHC working group is in a position to say no to it, but we are
>certainly in a position to say "this isn't a good general solution to X"

Why DHC WG cannot say no to what should not be in DHC? If that's the case, we have no points to discuss here what should or should not be configured using DHC protocol. People will keep to "borrow" DHCP for their unsuitable purposes as long as they do not have another suitable protocol.

Regards,

Sheng

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Oct 2013 08:59:46 +0200

Le 17/10/2013 02:39, Sten Carlsen a écrit :
>> On Oct 16, 2013, at 11:50 AM, Sten Carlsen<[email-masked]>  wrote:

and IPv6 and IPv4 delegated prefix/length.

> routers

and router preferred lifetime, and valid lifetime, or some conversion 
rule to lease-time.

> This is the start of MY list, please fill out with your preferences. :-)

and minimal MTU of the link.

Alex

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 17 Oct 2013 12:35:30 +0000

On 10/16/13 10:42 PM, "Sheng Jiang" <[email-masked]> wrote:

>Why DHC WG cannot say no to what should not be in DHC? If that's the
>case, we have no points to discuss here what should or should not be
>configured using DHC protocol. People will keep to "borrow" DHCP for
>their unsuitable purposes as long as they do not have another suitable
>protocol.

Agree. I'm a little puzzled by the first referenced paragraph as well. Why
all this exercise?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Oct 2013 09:54:15 -0400

> Why DHC WG cannot say no to what should not be in DHC? If that's the case, we have no points to discuss here what should or should not be configured using DHC protocol. People will keep to "borrow"…

The DHCP Directorate, when I get around to making it happen (Bernie and Tomek have already done the hard work) will in fact do reviews of this sort.   But we really can't say "don't do this" to things that don't change the DHCP protocol itself, and even then it has to be a consensus process, not a veto.   What we can say is "that's usually going to be a bad idea, and shouldn't be done except in restricted cases, because of these security risks."

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Oct 2013 10:19:06 -0400

> Agree. I'm a little puzzled by the first referenced paragraph as well. Why

The IESG wanted to know if the DHC working group agreed that the primary focus of DHCP is to configure network-specific parameters and network-specific services, or whether the DHC working group thinks that configuring application services in general using DHCP is also a priority.

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Oct 2013 21:01:22 +0700

Date:        Thu, 17 Oct 2013 05:42:12 +0000
    From:        Sheng Jiang <[email-masked]>
    Message-ID:  <[email-masked]>

  | Why DHC WG cannot say no to what should not be in DHC? 

Would you ask the same question if it were the TCP working group attempting
to stop some application protocol because the TCP people didn't like it?

The DHCP working group's job is to make DHCP work - improving as much
as possible the efficiency, reliability, and security - as with any other
protocol.

It isn't to dictate how others use the result.   If some other WG has a
use for some data, and having that deliver delivered by DHCP looks to be
the best way (to them) then provided the idea survives IETF last call,
it really is no-one else's business.

Of course this WG (and anyone else) can suggest alternatives, or describe
problems, and suggest better ways - but no-one gets (unilaterally) to
impose road blocks.    Ted was right in what he said - if the proposal in
question isn't a good idea, by all means say so, but don't start believing
that this group has any right to tell any other what they can or cannot do.

kre

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 18 Oct 2013 01:57:37 +0000

>Sheng>  | Why DHC WG cannot say no to what should not be in DHC?
>

The question is different here. The application protocol use TCP as a transparent deliver tool. They does not request anything from TCP resource. The DHC WG cannot stop people to use DHC protocol as a platform. But the DHC WG should have the right to say: you can do whatever you want over DHCP platform for any purposes, but you CANNOT get official DHCP Option code assigned by IANA if that does not approved by DHC Directorate. In another word, DHC Option code is a resource, controlled by DHC Directorate and should only be assigned to these correct usages.

Sheng

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Oct 2013 18:56:38 +0200

Ted,

> It's pretty clear to me that this option is not a very good idea in most cases.   I don't think the DHC working group is in a position to say no to it, but we are certainly in a position to say "th…

are you sure you don't mean to say, "building networks this way is not a very good idea in most cases"?
because if you suspend enough disbelief, then the requirement for the network to be able to give hosts
information about the SAS/DAS policy table is hard to get around.

a good general solution to the source address selection problem? we don't have one, and I think it
unlikely that we will ever get one. active probing, aka multi-prefix Happy Eyeballs is the only thing that may work everywhere, and even that as a set of problems associated with it.

> Of course, there are constrained environments where it may make sense—e.g., in a PE router<->CE router situation.  But this is not something that ought to be enabled on all DHCP clients.

to solve the use case described in:
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05

then that does exactly that, recommend it to be enabled on all DHCP clients.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 17:32:29 +0000

> information about the SAS/DAS policy table is hard to get around.

I'm deeply conflicted on the SAS option, as you may recall from my IESG review of it.  It does solve the problem, and in that sense it's good, but the security model makes me uncomfortable.   I would be a lot happier if SAS were somehow accomplished using ND options, probably for the same reason that people tend to be uncomfortable with default routes coming from DHCPv6 servers.  

"It's not a good idea" represents my most pessimistic view of the option; my optimistic view of the option is that it's useful and will make things work better in general.   But I'm waiting for reality to clue me in as to which view is more realistic.

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Oct 2013 21:01:15 +0200

Ted,

> "It's not a good idea" represents my most pessimistic view of the option; my optimistic view of the option is that it's useful and will make things work better in general.   But I'm waiting for rea…

agree.
you could, I believe generalise those concerns to most of the unauthenticated ND and DHCP provisioning options.
perhaps I want my host to use the searchlist when provided when I'm located in my home network (host owner equals network "operator"), but I probably wouldn't when connecting at my local cafe, or at my employers.

I would at least have liked that my host implementation provided more policy with regards to what DHCP options that it applied, based on what network it was connected to. that said, perhaps a lot of what we use DHCP for should better be done with service discovery.

cheers,
Ole