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

"Bernie Volz (volz)" <volz@cisco.com> Wed, 16 October 2013 15:01 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B92711E8138 for <dhcwg@ietfa.amsl.com>; Wed, 16 Oct 2013 08:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obb0ykrj7Pwc for <dhcwg@ietfa.amsl.com>; Wed, 16 Oct 2013 08:01:20 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 11BDD11E81DE for <dhcwg@ietf.org>; Wed, 16 Oct 2013 08:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26198; q=dns/txt; s=iport; t=1381935680; x=1383145280; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=4iP9bdfTqgy+8QBv/jXn8Lh6DQYMOzWJ3ArkF1bA4kg=; b=IDtsGVyIHSJpSulpE2DUe3/2cj59SfgBZgKttGfnledfu8fQUDudrue4 18CIPojBkh8kP5hyHiuUBTmk0mLsqiEbEUQ7ej3APAiy0MjuGXC1yTnbo kwpg9GWUIeOldL+1MxZtxf3HScTBIBwKMyX1zGMhNazSLl3RMjo1Rnanh U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAEypXlKtJXG//2dsb2JhbABagkNEOFLCD4EdFnSCJQEBAQMBAQEBKkEQBwQCAQgRBAEBCwsLBwcnCxQJCAIEARIIh3gGDL8bjX4KCgYBgQctCgEGBIMVgQYDlCeVX4MkgWcJFyI
X-IronPort-AV: E=Sophos; i="4.93,508,1378857600"; d="scan'208,217"; a="272794266"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 16 Oct 2013 15:01:18 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9GF1IrH002818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 15:01:18 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 10:01:18 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Sten Carlsen <stenc@s-carlsen.dk>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] What sorts of services does DHCP configure?
Thread-Index: AQHOynEYwYMFemNcIUSUMhuRl4LgSpn3W33ggABhAwD//645oA==
Date: Wed, 16 Oct 2013 15:01:17 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD1E5A1@xmb-rcd-x04.cisco.com>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <525EA740.7000902@s-carlsen.dk>
In-Reply-To: <525EA740.7000902@s-carlsen.dk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.255.77]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AD1E5A1xmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: Re: [dhcwg] What sorts of services does DHCP configure?
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 15:01:25 -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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Sten Carlsen
Sent: Wednesday, October 16, 2013 10:49 AM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] What sorts of services does DHCP configure?


On 16/10/13 16:15, Bernie Volz (volz) wrote:

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.



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.
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.






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: dhcwg-bounces@ietf.org<mailto:dhcwg-bounces@ietf.org> [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simon Hobson

Sent: Wednesday, October 16, 2013 9:10 AM

To: dhcwg@ietf.org<mailto:dhcwg@ietf.org> WG

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



"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.

_______________________________________________

dhcwg mailing list

dhcwg@ietf.org<mailto:dhcwg@ietf.org>

https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________

dhcwg mailing list

dhcwg@ietf.org<mailto:dhcwg@ietf.org>

https://www.ietf.org/mailman/listinfo/dhcwg



--

Best regards



Sten Carlsen



No improvements come from shouting:



       "MALE BOVINE MANURE!!!"