From leaf.yeh.sdo@gmail.com Tue Oct 1 08:40:44 2013 Return-Path: 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 248FF21E8153 for ; Tue, 1 Oct 2013 08:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_219128=1.666] 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 zmSSzJI0qC2z for ; Tue, 1 Oct 2013 08:40:42 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E024521F9AB4 for ; Tue, 1 Oct 2013 08:40:06 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so7400293pdi.19 for ; Tue, 01 Oct 2013 08:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=/F6vqzfmryl7cz5+3oxlDVN5mqnva9eBtcTjCQWEb1g=; b=d86Y1L+MsGWQgo+DCn68r1GntmoN6X1BrPaspe3db6Tn8qnhOJGmI5FznrtmNyZJo0 Hz9MivNc2tiomhZn2aChXKDqu5fKHqcYEJBcAgkqKny2rSfNUdUnUeyOAOXY6obOnedD L1jHuOpCxlC2jE76oOSAuWv+4E95/e7qyLiVGNbWuSKMtmSSmg5bkyjKpKxUtddSu2fz I9isSGZVQ2U6t9cCd8q0vi6OkKwn7oCtBRULUQ7f7ZaHb+EGd33drGdpGaOg6i6R4pLK rZ0uQWh9pVlvD2z6cSurhZJBIMMeaIIiTmwGTCYPsVuYY2tifYxgdE0/DzxLdhHR9Ecz nQsA== X-Received: by 10.66.190.198 with SMTP id gs6mr34011130pac.49.1380642005346; Tue, 01 Oct 2013 08:40:05 -0700 (PDT) Received: from PC ([219.133.129.162]) by mx.google.com with ESMTPSA id nj9sm7507387pbc.13.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 01 Oct 2013 08:40:04 -0700 (PDT) From: "Leaf Yeh" To: "'Ralph Droms'" , "'Alexandru Petrescu'" References: <489D13FBFA9B3E41812EA89F188F018E18654EE6@xmb-rcd-x04.cisco.com> <5212694A.6000807@gmail.com> <52305986.2010503@gmail.com>, <52306010.4090001@gmail.com> <5E91E9B8-6E22-46DD-A687-B4983BD0B508@gmail.com> <523f2fa3.c9ed440a.55a9.ffffc38e@mx.google.com> <52402AF3.8010407@gmail.com> <5240486E.20501@gmail.com> <52405701.9070506@gmail.com> <2CC893E4-7C48-4345-A40E-E2B3822C14ED@gmail.com> <5241951B.2070606@gmail.com> <6690AA2A-BB92-45BE-A66C-8BFFE5A441F2@gmail.com> <5242CADB.5040000@gmail.com> In-Reply-To: Date: Tue, 1 Oct 2013 23:39:57 +0800 Message-ID: <524aecd4.69d4440a.25d9.ffffba0c@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac66I+8y/eP7hllhTIam59Q8Pw+/WAASJ+nw Content-Language: zh-cn Cc: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 3633 to Internet Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 15:40:44 -0000 Ralph - How does the Access Router know the route through the RR to the = PC? I thought that was the information that needs to be installed on the = Access Router. I guess Ole's answer in the thread of 'Re: [dhcwg] Advancing RFC 3315 = and RFC 3633 to Internet Standard' was '...everyone does this with snooping today...' Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ralph Droms Sent: Thursday, September 26, 2013 3:18 AM To: Alexandru Petrescu Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] RFC 3633 to Internet Standard On Sep 25, 2013, at 12:36 PM 9/25/13, Alexandru Petrescu wrote: > Le 24/09/2013 22:43, Ralph Droms a =E9crit : >>=20 >> On Sep 24, 2013, at 2:35 PM 9/24/13, Alexandru Petrescu wrote: >>=20 >>> Le 24/09/2013 10:32, Ralph Droms a =E9crit : >>>>=20 >>>> On Sep 23, 2013, at 3:58 PM 9/23/13, Alexandru Petrescu=20 >>>> wrote: >>>>=20 >>>>> Le 23/09/2013 15:55, Tomek Mrugalski a =E9crit : >>>>>> On 23.09.2013 13:50, Alexandru Petrescu wrote: >>>>>>> Le 22/09/2013 19:57, Leaf Yeh a =E9crit : >>>>>>>> Ralph > The piece of network equipment that implements the=20 >>>>>>>> relay agent routes, and that network equipment *might* also=20 >>>>>>>> need a route. >>>>>>>>=20 >>>>>>>> On the PE router implementing relay for DHCPv6-PD, it always=20 >>>>>>>> needs add the associated route for the CE's network of=20 >>>>>>>> delegated prefix. I can't see *might* here. >>>>>>>=20 >>>>>>> I agree with the doubt. I don't see a might, but rather a must. = >>>>>>> Otherwise it doesn't work. >>>>>>>=20 >>>>>>> But maybe I dont understand the word 'might' as a native speaker = >>>>>>> could hear it. >>>>>> Relay agent is functionality that can be provided by a piece of=20 >>>>>> software. You can run it on any box that is connected to more=20 >>>>>> than one network. Although typically such a box serves as a=20 >>>>>> router, it doesn't have to. >>>>>=20 >>>>> You mean a Relay agent which runs on a pure Host (single real=20 >>>>> interface, no additional virtual/real interfaces)? >>>>>=20 >>>>> Even in that case it (or the Router on the same link which is=20 >>>>> connected to the Internet) will need to install a route towards=20 >>>>> the Requesting Router's interface for the delegated prefix. >>>>=20 >>>> And there's the exact point of the discussion - if the relay agent=20 >>>> is not implemented on the router that needs the route, passing the=20 >>>> route in the DHCPv6 message exchange through the relay agent won't=20 >>>> get the route to the appropriate router. >>>>=20 >>>>>=20 >>>>> In all cases, the Relay and other routers on that link MUST=20 >>>>> install a route. >>>>=20 >>>> And how does that route get to the other routers? >>>=20 >>> They are all on the same link, and one mechanism used to install=20 >>> routes dynamically is during ICMP Redirect. >>=20 >> According to RFC 4861, sec. 8.2, routers ignore ICMPv6 Redirect = messages: >>=20 >> A router MUST NOT update its routing tables upon receipt of a >> Redirect. >>=20 >> I don't recall if that text is updated by subsequent RFCs. >=20 > I don't know either whether subsequent RFCs update it, or whether = linux has knobs allowing that - one should check. >=20 > And, what I meant is not a necessarily a Router but maybe a Host DHCPRelay: > ________ ---------- > | |DHCPServer| > ... ---------- > | > ---------- --------- > | Host | | Access | > | DHCPRelay| | Router | > ---------- --------- > | | > ----+--------------+ > | > ---------- ---- > |Requesting| | PC | > | Router | | | > ---------- ---- > | | > ----+------------+-- >=20 > After the PD phase, and after the assumed route insertion in Access Router, the Host DHCPRelay would get an ICMPRedirect from the Access = Router whenever wanting to talk to PC. The route it installs is for the = Delegated Prefix. The "Host DHCPRelay" has to be on the same link with the PC. How does the Access Router know the route through the RR to the PC? I thought that was the information that needs to be installed on the = Access Router. - Ralph >=20 > (the topology above has some advantages in terms of rapid deployment = of DHCPv6 in a hostpot network). >=20 > Alex >=20 >>=20 >>>=20 >>>>> Whether they do it at allocation time, at ICMP Redirect time, or=20 >>>>> at manual config time - is another matter. >>>>=20 >>>> I'm not saying the route installation can't be accomplished through = >>>> DHCPv6. I think you'll need to address the specific issues I=20 >>>> raised in previous e-mail to publish a specification for passing=20 >>>> routing information to the appropriate router through a DHCPv6=20 >>>> message exchange with a host. >>>=20 >>> Ok, my point is whether or not we could formulate a problem=20 >>> statement for this: there is a need for a route in the concerned=20 >>> routers, after the PD operation. Without that route the=20 >>> communication can't be established between Hosts configured with an=20 >>> address prefixed by the delegated prefix. >>=20 >> I agree that there is a need for the route to exist and an = appropriate problem statement could be formulated. >>=20 >> - Ralph >>=20 >>>=20 >>> Alex >>>=20 >>>>=20 >>>> - Ralph >>>>=20 >>>>>=20 >>>>> Without that route the whole schmillblick doesn't work. >>>>>=20 >>>>> Alex >>>>>=20 >>>>>=20 >>>>> _______________________________________________ dhcwg mailing list = >>>>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Tue Oct 1 08:40:54 2013 Return-Path: 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 88FBF21E8226 for ; Tue, 1 Oct 2013 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_219128=1.666] 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 wTnMnY0UbutI for ; Tue, 1 Oct 2013 08:40:53 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id C179321E805F for ; Tue, 1 Oct 2013 08:40:10 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo5so7303729pbc.37 for ; Tue, 01 Oct 2013 08:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=AL1ZAYKFsnONgTs4xj22FQPGWbALNNDZSlO6TddzIzE=; b=f76Y/DyagRt8X+f36FoC9HVp0i8LSUstf+77pSo7XhkTHre9kDFCwaiyihUFmb/wbM FxGmnZa4RmsbKVqUmvsfJeEmwTAWpa5LxN400OKBWLMa2X64Ew68jDExGEm4dx6ULJxW olgt2JLn2F4G7gdWcgeB5j/7LB68VJE3Au2RUEVIITUlnmm6pC2tZDc9nfLPcyVV3VSX /nS8FceenbPEv7ZN9VASJ6APx8SJRtnVGWG5XL3YtUdaWcxf1hzlnICQyxVeQHwdohyn IRPAIWnPk6IoX6vnVIozyLesvRC/yp8QOwLTEoqc/Bx6RKr44nTdHWVkmunyZ1VX+Ubl pTdg== X-Received: by 10.66.136.71 with SMTP id py7mr34314770pab.2.1380642009910; Tue, 01 Oct 2013 08:40:09 -0700 (PDT) Received: from PC ([219.133.129.162]) by mx.google.com with ESMTPSA id nj9sm7507387pbc.13.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 01 Oct 2013 08:40:09 -0700 (PDT) From: "Leaf Yeh" To: , , , , , References: <20130925114309.5568A8E016@rfc-editor.org> In-Reply-To: <20130925114309.5568A8E016@rfc-editor.org> Date: Tue, 1 Oct 2013 23:39:57 +0800 Message-ID: <524aecd9.69d4440a.25d9.ffffba17@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac655WHQ37xNcEnsQKOEhd5I+BQ0SwAL54XA Content-Language: zh-cn Cc: dhcwg@ietf.org, alexandru.petrescu@gmail.com Subject: Re: [dhcwg] [Editorial Errata Reported] RFC3633 (3736) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 15:40:54 -0000 Frankly speaking, I prefer the original text. This copy revision sound unnecessary. I suppose only the 1st router (called the Provider Edge router) in the provider network needs to add the routing information (or routes) for delegated prefixes, the other routers (through which the requesting router may forward traffic) could get these routes from the routing protocol employed in the ISP network. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Wednesday, September 25, 2013 7:43 PM To: ot@cisco.com; rdroms@cisco.com; brian@innovationslab.net; ted.lemon@nominum.com; volz@cisco.com; tomasz.mrugalski@gmail.com Cc: dhcwg@ietf.org; alexandru.petrescu@gmail.com; rfc-editor@rfc-editor.org Subject: [dhcwg] [Editorial Errata Reported] RFC3633 (3736) The following errata report has been submitted for RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3633&eid=3736 -------------------------------------- Type: Editorial Reported by: Alexandru Petrescu (w/ text from R. Droms) Section: 14 Original Text ------------- If a delegating router communicates with a requesting router through a relay agent, the delegating router may need a protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router. Corrected Text -------------- If a delegating router communicates with a requesting router through a relay agent, the delegating router may need a protocol or other out-of-band communication to add routing information for delegated prefixes into any router through which the requesting router may forward traffic. Notes ----- This is a terminology correction. See discussion on the email list DHCWG of the DHC WG of IETF, 24 September 2013, http://www.ietf.org/mail-archive/web/dhcwg/current/msg14709.html Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3633 (draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05) -------------------------------------- Title : IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 Publication Date : December 2003 Author(s) : O. Troan, R. Droms Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From rdroms.ietf@gmail.com Wed Oct 2 05:16:29 2013 Return-Path: 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 0082011E826C for ; Wed, 2 Oct 2013 05:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 p4B-tevsCyMr for ; Wed, 2 Oct 2013 05:16:09 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2667A11E81B4 for ; Wed, 2 Oct 2013 05:15:58 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 3so450127qeb.3 for ; Wed, 02 Oct 2013 05:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aoBssm/9eQt0s8B4zAOT824FURpmQSwt/rwET7PIISs=; b=ueyZcJJJ+W5xyURr1C8G84HllIxkbSaA+R+Fr8goM4vYRtAMfgHVkMvIVMDBVeE+by gd1bLJBksqYKxB0/YFYv3HrFQSuHsuRicPLkprq8RIrcGXUcbSoT6/sXvwXGFRp96NY4 9xZEpJA28b8etna1NdTnWvYyfqLvcf1BtxC668981s8mfXpy+Jkt85TlVjexmNWwN0aG ucJulwQmS6EyK0xMisMi4DoQJKaqrVIN/6k0WRE3wn3hVXBPEjOZKQRGavUdeq7vZLHs fjIeEtRGri+A3p+LPf9FK3jTrQfUuirImorTSWHuBY2ZopGq8f9adC0qDhm/j4VW/4nu TOXw== X-Received: by 10.49.109.170 with SMTP id ht10mr2224940qeb.27.1380716156921; Wed, 02 Oct 2013 05:15:56 -0700 (PDT) Received: from rtp-rdroms-89110.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id l2sm4381512qad.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Oct 2013 05:15:56 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ralph Droms In-Reply-To: <524aecd4.69d4440a.25d9.ffffba0c@mx.google.com> Date: Wed, 2 Oct 2013 08:15:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <489D13FBFA9B3E41812EA89F188F018E18654EE6@xmb-rcd-x04.cisco.com> <5212694A.6000807@gmail.com> <52305986.2010503@gmail.com>, <52306010.4090001@gmail.com> <5E91E9B8-6E22-46DD-A687-B4983BD0B508@gmail.com> <523f2fa3.c9ed440a.55a9.ffffc38e@mx.google.com> <52402AF3.8010407@gmail.com> <5240486E.20501@gmail.com> <52405701.9070506@gmail.com> <2CC893E4-7C48-4345-A40E-E2B3822C14ED@gmail.com> <5241951B.2070606@gmail.com> <6690AA2A-BB92-45BE-A66C-8BFFE5A441F2@gmail.com> <5242CADB.5040000@gmail.com> <524aecd4.69d4440a.25d9.ffffba0c@mx.google.com> To: Leaf Yeh X-Mailer: Apple Mail (2.1508) Cc: "dhcwg@ietf.org WG" , Alexandru Petrescu Subject: Re: [dhcwg] RFC 3633 to Internet Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 12:16:30 -0000 On Oct 1, 2013, at 11:39 AM 10/1/13, Leaf Yeh = wrote: > Ralph - How does the Access Router know the route through the RR to = the PC? > I thought that was the information that needs to be installed on the = Access > Router. >=20 > I guess Ole's answer in the thread of 'Re: [dhcwg] Advancing RFC 3315 = and > RFC 3633 to Internet Standard' was '...everyone does this with = snooping > today...' But that's snooping on the device on which the relay agent runs. In the = diagram we're discussing, the Access Router doesn't have a relay agent = and wouldn't snoop. - Ralph >=20 >=20 > Best Regards, > Leaf >=20 >=20 >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of > Ralph Droms > Sent: Thursday, September 26, 2013 3:18 AM > To: Alexandru Petrescu > Cc: dhcwg@ietf.org WG > Subject: Re: [dhcwg] RFC 3633 to Internet Standard >=20 >=20 > On Sep 25, 2013, at 12:36 PM 9/25/13, Alexandru Petrescu > wrote: >=20 >> Le 24/09/2013 22:43, Ralph Droms a =E9crit : >>>=20 >>> On Sep 24, 2013, at 2:35 PM 9/24/13, Alexandru Petrescu > wrote: >>>=20 >>>> Le 24/09/2013 10:32, Ralph Droms a =E9crit : >>>>>=20 >>>>> On Sep 23, 2013, at 3:58 PM 9/23/13, Alexandru Petrescu=20 >>>>> wrote: >>>>>=20 >>>>>> Le 23/09/2013 15:55, Tomek Mrugalski a =E9crit : >>>>>>> On 23.09.2013 13:50, Alexandru Petrescu wrote: >>>>>>>> Le 22/09/2013 19:57, Leaf Yeh a =E9crit : >>>>>>>>> Ralph > The piece of network equipment that implements the=20 >>>>>>>>> relay agent routes, and that network equipment *might* also=20 >>>>>>>>> need a route. >>>>>>>>>=20 >>>>>>>>> On the PE router implementing relay for DHCPv6-PD, it always=20= >>>>>>>>> needs add the associated route for the CE's network of=20 >>>>>>>>> delegated prefix. I can't see *might* here. >>>>>>>>=20 >>>>>>>> I agree with the doubt. I don't see a might, but rather a = must.=20 >>>>>>>> Otherwise it doesn't work. >>>>>>>>=20 >>>>>>>> But maybe I dont understand the word 'might' as a native = speaker=20 >>>>>>>> could hear it. >>>>>>> Relay agent is functionality that can be provided by a piece of=20= >>>>>>> software. You can run it on any box that is connected to more=20 >>>>>>> than one network. Although typically such a box serves as a=20 >>>>>>> router, it doesn't have to. >>>>>>=20 >>>>>> You mean a Relay agent which runs on a pure Host (single real=20 >>>>>> interface, no additional virtual/real interfaces)? >>>>>>=20 >>>>>> Even in that case it (or the Router on the same link which is=20 >>>>>> connected to the Internet) will need to install a route towards=20= >>>>>> the Requesting Router's interface for the delegated prefix. >>>>>=20 >>>>> And there's the exact point of the discussion - if the relay agent=20= >>>>> is not implemented on the router that needs the route, passing the=20= >>>>> route in the DHCPv6 message exchange through the relay agent won't=20= >>>>> get the route to the appropriate router. >>>>>=20 >>>>>>=20 >>>>>> In all cases, the Relay and other routers on that link MUST=20 >>>>>> install a route. >>>>>=20 >>>>> And how does that route get to the other routers? >>>>=20 >>>> They are all on the same link, and one mechanism used to install=20 >>>> routes dynamically is during ICMP Redirect. >>>=20 >>> According to RFC 4861, sec. 8.2, routers ignore ICMPv6 Redirect = messages: >>>=20 >>> A router MUST NOT update its routing tables upon receipt of a >>> Redirect. >>>=20 >>> I don't recall if that text is updated by subsequent RFCs. >>=20 >> I don't know either whether subsequent RFCs update it, or whether = linux > has knobs allowing that - one should check. >>=20 >> And, what I meant is not a necessarily a Router but maybe a Host > DHCPRelay: >> ________ ---------- >> | |DHCPServer| >> ... ---------- >> | >> ---------- --------- >> | Host | | Access | >> | DHCPRelay| | Router | >> ---------- --------- >> | | >> ----+--------------+ >> | >> ---------- ---- >> |Requesting| | PC | >> | Router | | | >> ---------- ---- >> | | >> ----+------------+-- >>=20 >> After the PD phase, and after the assumed route insertion in Access > Router, the Host DHCPRelay would get an ICMPRedirect from the Access = Router > whenever wanting to talk to PC. The route it installs is for the = Delegated > Prefix. >=20 > The "Host DHCPRelay" has to be on the same link with the PC. >=20 > How does the Access Router know the route through the RR to the PC? I > thought that was the information that needs to be installed on the = Access > Router. >=20 > - Ralph >=20 >>=20 >> (the topology above has some advantages in terms of rapid deployment = of > DHCPv6 in a hostpot network). >>=20 >> Alex >>=20 >>>=20 >>>>=20 >>>>>> Whether they do it at allocation time, at ICMP Redirect time, or=20= >>>>>> at manual config time - is another matter. >>>>>=20 >>>>> I'm not saying the route installation can't be accomplished = through=20 >>>>> DHCPv6. I think you'll need to address the specific issues I=20 >>>>> raised in previous e-mail to publish a specification for passing=20= >>>>> routing information to the appropriate router through a DHCPv6=20 >>>>> message exchange with a host. >>>>=20 >>>> Ok, my point is whether or not we could formulate a problem=20 >>>> statement for this: there is a need for a route in the concerned=20 >>>> routers, after the PD operation. Without that route the=20 >>>> communication can't be established between Hosts configured with an=20= >>>> address prefixed by the delegated prefix. >>>=20 >>> I agree that there is a need for the route to exist and an = appropriate > problem statement could be formulated. >>>=20 >>> - Ralph >>>=20 >>>>=20 >>>> Alex >>>>=20 >>>>>=20 >>>>> - Ralph >>>>>=20 >>>>>>=20 >>>>>> Without that route the whole schmillblick doesn't work. >>>>>>=20 >>>>>> Alex >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ dhcwg mailing = list=20 >>>>>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 From draghuva@cisco.com Fri Oct 4 23:51:49 2013 Return-Path: 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 F37EE21F9B58 for ; Fri, 4 Oct 2013 23:51:48 -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 QjH1mIKk+Kgw for ; Fri, 4 Oct 2013 23:51:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 123AA21F9396 for ; Fri, 4 Oct 2013 23:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2740; q=dns/txt; s=iport; t=1380955904; x=1382165504; h=from:to:subject:date:message-id:mime-version; bh=tx9LtP5GBvOMRyeiSjkmvcYw+ogBIC8kVOqPWnCmgx0=; b=ZGji7ivwh1NSqho2pG7E/q9WNfCK7P0CmBN2gS6qj7dahgJgk79YC7Lc LreSmAQutPKLcsOK5OjnVg3D2iorQP73DtT8m3p5lOzxKzhjLFm5VOky/ CLvnG7xIm+FFmpRMyu0HtkhxVzbOWD7Rjhqjj3pfeNPS3VJWoFHZnsLxE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcGAC22T1KtJV2Y/2dsb2JhbABZgwc4UrhXiEOBGBZtB4InAQSBCwEMAR1WJwQbh34MmyWhKY8gg1eBBAOZMJBRgySCKg X-IronPort-AV: E=Sophos;i="4.90,1038,1371081600"; d="scan'208,217";a="265392268" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 05 Oct 2013 06:51:43 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r956phRb009616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 5 Oct 2013 06:51:43 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.78]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Sat, 5 Oct 2013 01:51:42 -0500 From: "Dushyant Raghuvanshi (draghuva)" To: "dhcwg@ietf.org" Thread-Topic: draft-raghuvanshi-dhc-dhcpv6-active-leasequery-00 Thread-Index: AQHOwZdZj4s2sbkfSEKNcz6IK1CaGQ== Date: Sat, 5 Oct 2013 06:51:41 +0000 Message-ID: <0A2ED610A80E7B4DBCC8E63B8E7EE4302712D549@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.47.61] Content-Type: multipart/alternative; boundary="_000_0A2ED610A80E7B4DBCC8E63B8E7EE4302712D549xmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] draft-raghuvanshi-dhc-dhcpv6-active-leasequery-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 06:51:49 -0000 --_000_0A2ED610A80E7B4DBCC8E63B8E7EE4302712D549xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have posted a new document for the working group that describes the mecha= nism using which an entity can receive real-time binding updates from DHCP = server. We have UDP and Bulk Leasequery feature available for DHCPv6. But using the= se, a requester can only receive binding updates until the time of the requ= est. So to keep it's binding information up-to-date, requestor needs to sen= d the request again and again. This document also extends to RFC 5460 by providing new options query-start= -time and query-end-time. Using these option, requestor can make query for = selective binding updates instead of getting all the binding data from DHCP= server. Please spend some time to review the document and provide your comments. Thanks, Dushyant. http://tools.ietf.org/html/draft-raghuvanshi-dhc-dhcpv6-active-leasequery-0= 0 --_000_0A2ED610A80E7B4DBCC8E63B8E7EE4302712D549xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

I have posted a new document for the working group that describes the = mechanism using which an entity can receive real-time binding updates from = DHCP server. 

We have UDP and Bulk Leasequery feature available for DHCPv6. But usin= g these, a requester can only receive binding updates until the time of the= request. So to keep it's binding information up-to-date, requestor needs t= o send the request again and again.

This document also extends to RFC 5460 by providing new options query-= start-time and query-end-time. Using these option, requestor can make query= for selective binding updates instead of getting all the binding data from= DHCP server. 

Please spend some time to review the document and provide your comment= s.

Thanks,
Dushyant.  

--_000_0A2ED610A80E7B4DBCC8E63B8E7EE4302712D549xmbrcdx02ciscoc_-- From josyular@Brocade.com Fri Oct 4 11:19:25 2013 Return-Path: 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 A573D21F9DB4 for ; Fri, 4 Oct 2013 11:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] 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 Zfy33ESFjxVt for ; Fri, 4 Oct 2013 11:19:12 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id A8CB921F9CB1 for ; Fri, 4 Oct 2013 11:18:54 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r94IGmf7024549 for ; Fri, 4 Oct 2013 11:18:51 -0700 Received: from brmwp-exchub01.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1f9ekmrkw1-10 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 04 Oct 2013 11:18:51 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.187.49) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Oct 2013 12:18:50 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.1.246]) by brm-excashub-2.corp.brocade.com ([172.16.187.74]) with mapi; Fri, 4 Oct 2013 12:18:06 -0600 From: Ramakanth Josyula To: "dhcwg@ietf.org" Date: Fri, 4 Oct 2013 12:16:59 -0600 Thread-Topic: Review request - draft-josyula-dhc-multicast - DHCP Option for IPTV source addresses Thread-Index: Ac7BLeqHiH5ACY0nSAGWxdD2LqW7wA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E61DC611A57B2B45B14FC8EDBC5FB178251172C86CBRMEXCH3corpb_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-04_04:2013-10-04, 2013-10-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310040093 X-Mailman-Approved-At: Sat, 05 Oct 2013 10:51:19 -0700 Subject: [dhcwg] Review request - draft-josyula-dhc-multicast - DHCP Option for IPTV source addresses X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 19:01:17 -0000 --_000_E61DC611A57B2B45B14FC8EDBC5FB178251172C86CBRMEXCH3corpb_ Content-Type: text/plain; charset="us-ascii" Hi, I have submitted the below internet draft proposing a new DHCP option for IPTV source addresses. http://www.ietf.org/internet-drafts/draft-josyula-dhc-multicast-02.txt I would request you to review this document and provide the comments on standardizing the same. Please guide me through the process if I miss anything with respect to the process of the review. Thanks and regards, Ramakanth. Below is the brief introduction about the background and the benefits of the proposed option : Back ground : IPTV Solution is widely integrated as part of the broadband networks in triple/multi play solutions. In many cases this service is run by delivering multicast streams to the IP hosts/Set top boxes connected to the home gateways. IGMP protocol in IPv4 networks and MLD protocol in IPv6 networks are commonly used for requesting these multicast streams from the nearest router connected via an access network. By using the IGMP version-3 in IPv4 networks and MLD version-2 in IPv6 networks, the hosts can request multicast streams from the specific set of multicast sources. The proposed option is intended to supply all the available IPv4 or IPv6 source addresses from which the multicast hosts can request and receive the multicast streams. Benefits of implementing this option : - It provides an effective method for maintaining and updating the multicast source address information to every multicast host in the network as per their individual SLAs. - Intermediate access nodes can snoop this option from the DHCP messages to extend the its multicast services like : Authentication of multicast users, integrating non-source aware multicast clients etc. - Convergence of IPTV services from different users can be achieved at the user level irrespective of the multicast transmitting technologies used in the network. For example, any service provider who manages the aggregation and access networks can receive the multicast streams from different sources/networks (may not be under their own administration) and feed them to their access networks. - The subscribers can easily validate the quality of the service offered by different IPTV sources dynamically and switch to the interested source as per their own set of requirements. --_000_E61DC611A57B2B45B14FC8EDBC5FB178251172C86CBRMEXCH3corpb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have sub= mitted the below internet draft proposing a new DHCP option for IPTV source= addresses.

 

http://www.ietf.org/internet-drafts/draft-josyula= -dhc-multicast-02.txt

 =

I would request you to review this docume= nt and provide the comments on standardizing the same.

 

Please guide= me through the process if I miss anything with respect to the process of t= he review.

 

Thanks and regards,

Ramakanth.

 

 

Below is the= brief introduction about the background and the benefits of the proposed o= ption :

 

Back ground :

 

IPTV Solution is widely integr= ated as part of the broadband networks in triple/multi play solutions. In m= any cases this service is run by delivering multicast streams to the IP hos= ts/Set top boxes connected to the home gateways.  IGMP protocol in IPv= 4 networks and   MLD protocol in IPv6 networks are commonly used = for requesting these  multicast streams from the nearest router connec= ted via an access network. By using the IGMP version-3 in IPv4 networks and= MLD version-2 in IPv6 networks, the hosts can request multicast streams fr= om the specific set of multicast sources.

 

The proposed option is intende= d to supply all the available IPv4 or IPv6 source addresses from which the = multicast hosts can request and receive the multicast streams.

 

Bene= fits of implementing this option :

 

   - It provides an = effective method for maintaining and updating the multicast source address = information to every multicast host in the network as per their individual = SLAs.

 

   - Intermediate access nodes can snoop this option from= the DHCP messages to extend the its multicast services like : Authenticati= on of multicast users, integrating non-source aware multicast clients etc.<= o:p>

 

   - Convergence of IPTV services from different users can be a= chieved at the user level irrespective of the multicast transmitting techno= logies used in the network. For example, any service provider who manages t= he aggregation   

  =    and access networks can receive the multicast streams fro= m different sources/networks (may not be under their own administration) an= d feed them to their access networks. 

  

   - Th= e subscribers can easily validate the quality of the service offered by dif= ferent IPTV sources dynamically and switch to the interested source as per = their own set of requirements.

&nbs= p;

= --_000_E61DC611A57B2B45B14FC8EDBC5FB178251172C86CBRMEXCH3corpb_-- From volz@cisco.com Sun Oct 6 12:24:52 2013 Return-Path: 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 34FAE11E8132 for ; Sun, 6 Oct 2013 12:24:52 -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=[AWL=-0.000, 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 Gn1NA2k3QA9J for ; Sun, 6 Oct 2013 12:24:47 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2009021F83EF for ; Sun, 6 Oct 2013 12:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19306; q=dns/txt; s=iport; t=1381087483; x=1382297083; h=from:to:subject:date:message-id:mime-version; bh=l9kQuCKv0lF5PLhUR9ZEZXUu5AiXD4cnm0wgg7lG/Qw=; b=Stxv+vcNnlU4qCt/GDn+xWOM1tQ2AhvxQx9uCkMPMwZOdbwq6V9XYTgB Sij2avGEjuuER03KgTB+YTYyulOOAosjD3o7jbfmgVclSy/GIW8W4+UPJ vVSJe4GXaMkd1lbYbEWxHd5jrswSPYWqmS+kph5JoINJkF90i2H1n8OTN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAO23UVKtJXHA/2dsb2JhbABZgkNEOFLBGIETFm0HgicBBB0MBEEdAQIoFkAmAQQbAYd9DJk8oQCOE4ENLYMqgQQDlCSVXYMkgWlB X-IronPort-AV: E=Sophos;i="4.90,1045,1371081600"; d="scan'208,217";a="268723533" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 06 Oct 2013 19:24:42 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r96JOgJm007905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 6 Oct 2013 19:24:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.47]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Sun, 6 Oct 2013 14:24:41 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Call for Agenda Items for IETF-88 (Vancouver) Thread-Index: Ac7CyRRj2lhQNkosRiKfaagKYriJPw== Importance: high X-Priority: 1 Date: Sun, 6 Oct 2013 19:24:41 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1ACF6595@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.164] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1ACF6595xmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [dhcwg] Call for Agenda Items for IETF-88 (Vancouver) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 19:24:52 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1ACF6595xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: The Vancouver IETF is not that far off (Nov 3-8). See http://www.ietf.org/m= eeting/88/index.html for more details, including venue information and impo= rtant dates. The preliminary agenda has the DHC WG is scheduled for TUESDAY, November 5 = from 0900-1130 PST. Please also note: * 2013-10-07 (Monday): Working Group Chair approval for initial documen= t (Version -00) submissions appreciated by UTC 24:00. * 2013-10-11 (Friday): Final agenda to be published. * 2013-10-21 (Monday): Internet Draft submission cut-off (for all draft= s, including -00) by UTC 24:00, upload using IETF ID Submission Tool. We are starting the call for agenda items. The co-chairs will finalize the = agenda about two weeks before the meeting and will give priority to items a= s follows (in this order): 1. WG documents with active working group discussion or that are deem= ed critical (i.e., have upcoming milestones) 2. WG documents with little or no discussion (provided there is a str= ong reason for the discussion ... i.e., a higher bandwidth discussion is ne= eded) 3. Non WG documents with active working group discussion 4. Non WG documents with little or no discussion We will limit the number of presentations to reduce the chance that we don'= t get to them all. Please be sure to focus your presentations on issues that need discussion o= r input (new work can include an overview, but the focus should be on issue= s needing resolution). Status updates can be sent to the mailing list. If you would like time, please indicate: - Draft name or topic - Who will present - How much time is needed - Why is time needed (tell us why you can't get what you need by p= osting on the mailing list) and what will be covered Thanks. - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1ACF6595xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 =

The Vancouver IETF is not that far off (Nov 3-8). Se= e http://www.ietf.org/meeting/88/index.html<= /span> for more details, including venue information and important date= s.

 

The preliminary agenda has the DHC WG is scheduled f= or TUESDAY, November 5 from 0900-1130 PST.

 

Please also note:

  • 2013-10-07 (Monday): Working G= roup Chair approval for initial document (Version -00) submissions apprecia= ted by UTC 24:00.
  • 2013-10-11 (Friday): Final age= nda to be published.
  • 2013-10-21 (Monday): Internet = Draft submission cut-off (for all drafts, including -00) by UTC 24:00, uplo= ad using IETF ID Submission Tool.

We are starting the call for agenda items. The co-ch= airs will finalize the agenda about two weeks before the meeting and will g= ive priority to items as follows (in this order):

 =

1.&nbs= p;      WG documents wit= h active working group discussion or that are deemed critical (i.e., have u= pcoming milestones)

2.&nbs= p;      WG documents wit= h little or no discussion (provided there is a strong reason for the discus= sion … i.e., a higher bandwidth discussion is needed)

3.&nbs= p;      Non WG documents= with active working group discussion

4.&nbs= p;      Non WG documents= with little or no discussion

 =

We will limit the number= of presentations to reduce the chance that we don’t get to them all.=

 

Please be sure to focus your presentations on issues= that need discussion or input (new work can include an overview, but the f= ocus should be on issues needing resolution). Status updates can be sent to= the mailing list.

 =

If you would like time, = please indicate:

- = ;         Draft name or to= pic

- = ;         Who will present=

- = ;         How much time is= needed

- = ;         Why is time need= ed (tell us why you can’t get what you need by posting on the mailing= list) and what will be covered

 =

Thanks.

 =

- = ;         Tomek & Bern= ie

--_000_489D13FBFA9B3E41812EA89F188F018E1ACF6595xmbrcdx04ciscoc_-- From otroan@employees.org Mon Oct 7 02:55:31 2013 Return-Path: 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 38E6F21E81CD for ; Mon, 7 Oct 2013 02:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 k5LOcJntDcQb for ; Mon, 7 Oct 2013 02:55:30 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id F344421E81EE for ; Mon, 7 Oct 2013 02:55:24 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-194.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 9C1E6600F; Mon, 7 Oct 2013 02:55:19 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_97B3F092-9712-4156-95D5-C3B0026CB0AE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ole Troan In-Reply-To: <6A05E003-42A2-4659-9F23-6F5DFC6A88EF@gmx.com> Date: Mon, 7 Oct 2013 11:55:17 +0200 Message-Id: <2C4C5302-C2CA-4F85-B053-78D317FD7964@employees.org> References: <20130930140054.31558.95411.idtracker@ietfa.amsl.com> <6A05E003-42A2-4659-9F23-6F5DFC6A88EF@gmx.com> To: Ian Farrer X-Mailer: Apple Mail (2.1510) Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 09:55:31 -0000 --Apple-Mail=_97B3F092-9712-4156-95D5-C3B0026CB0AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii all, here are some comments on a first read of the document. I have to general comments. one is on fate-sharing (see below), the = other on address provisioning conflicts. MAP provides a data-link layer that supports transport of IPv4. given = that it uses embedded addresses from IPv6 to algorithmically determine an end-points IPv4 address, you can = say that IPv4 addressing is inherit=20 in the data-link layer. in this model the IPv4 address is tied to IPv6. = this document proposes to provision IPv4 addressing separately with DHCPv4. either this document needs to = describe how this is supposed to work, or I think make a larger separation between in which cases only = stateless DHCPv4 can be used, versus which data-links that also stateful DHCPv4 can be used. (I'm only aware = of Public 4over6 that can support full DHCPv4). Section 1.1 "2. Extend DHCPv6 with new options for IPv4 configuration, such as [I-D.ietf-softwire-map-dhcp] describes." I think that could be phrased better. MAP DHCP does give the CE enough information so that it can calculate it's own IPv4 address. Here it = reads as if we're adding DHCPv4 options to DHCPv6. I'm not even sure you should have MAP DHCP in this table, it is not a = solution for passing DHCPv4 options, nor is it a solution to replicate all = DHCPv4 options in DHCPv6. It is a solution for having the CE calculate it's own IPv4 = address, shared IPv4 address or prefix. Note that the last two are not even = supported in DHCPv4. It does not offer any other IPv4 configuration information. If you have it in the "approaches" list at all: 2. Depend on the setup of data-link (softwire) to offer enough = information to create IPv4 addressing. Require no other IPv4 configuration information. ** Reading section 1.3. If you want this approach to be "copy relevant = DHCPv4 options into DHCPv6", then I suggest removing all references to MAP-DHCP. Rename 3. to "stateless DHCPv4" or DHCPINFORM only. Section 2: Drop requirement 6, I can't see how you can evaluate that. 8 is empty I suggest you add a new requirement: x. Fate sharing. The provisioning of IPv4 addressing and other = configuration information should be logically tied to the data-link layer that is uses to provide IPv4 connectivity. Section 3: DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing. In the evaluation in section 3.x I suggest dropping the use of = "complex" and "simple". That appears very subjective. 3.4.2 bullet 3. applies to all approaches allowing DHCPv4 leases. bullet 4. please expand. bullet 5. change to "Restricted to a broadcast capable = link-layer." 3.5.1 bullet 3. DHCPv4 and DHCPv6 cannot really be separated from each = other since it=20 it is DHCPv6 that provides transport for DHCPv4. and support = for the new BOOTP messages are required in DHCPv6. Minor comments: Introduction: "A general trend here is to relocate NAT44 functionality and IPv4 address sharing from the centralized tunnel concentrator to the CPE in order to achieve better scalability. " I understand what you are trying to say, but unless the reader = understands that the starting point are mechanisms like NAT444 and DS-lite, he would find this strange. = As current deployments of IPv4 already use distributed NAT. cheers, Ole On Sep 30, 2013, at 16:14 , Ian Farrer wrote: > Hi, >=20 > I've just posted an update to the draft based on the discussions in = Berlin and Francis' review. >=20 > The contents of the conclusion remains unchanged. >=20 > Any comments etc. appreciated. >=20 > Cheers, > Ian >=20 >=20 > On 30 Sep 2013, at 16:00, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Dynamic Host Configuration Working = Group of the IETF. >>=20 >> Title : Provisioning IPv4 Configuration Over IPv6 Only = Networks >> Author(s) : Branimir Rajtar >> Ian Farrer >> Filename : draft-ietf-dhc-v4configuration-02.txt >> Pages : 17 >> Date : 2013-09-30 >>=20 >> Abstract: >> As IPv6 becomes more widely adopted, some service providers are >> taking the approach of deploying IPv6 only networks, without dual- >> stack functionality for IPv4. However, access to IPv4 based = services >> is still an ongoing requirement and approaches such as IPv4-in-IPv6 >> softwire tunnels are being developed to meet this need. >>=20 >> In order to provision end-user's hosts with the necessary IPv4 >> configuration, a number of different mechanisms have been proposed. >> This memo discusses the benefits and drawbacks of each, with the aim >> of recommending a single approach as the basis for future work. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-02 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-v4configuration-02 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_97B3F092-9712-4156-95D5-C3B0026CB0AE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSUoUFAAoJEFuJXizso86gCuwH/1pF7OU0kYh51A7rBQTF5YJ/ DLpueTzOuP6SLHq7twHt8yyqiBKS4ki4Jz/6NeS52Sq47yIsnCzzQbdkq9CV81wH GqDKKdSk1AZUWE688mUHhIb+bfwixk/5EBWthENwNh2gHepwcdQ/U1O/Iguu5Ohz 4SBIKAFvYnAh9Hv7IjjOJ7SALRRV/GlJzz1hhZG1ugddf7Mo8UMX3ca6lXjQi0hb BXUsI3eu7mqtJi0ZVXvWAujXpCJ9JWa1t0vxgsShni+dQ0SJ0VHNuPlHaZqP9VM5 FlgresHajVnK1e2WpGLjPZJs8ZRbOPI5QiB12nhfz4Zljy5YEicFiau5aWH8/+8= =EMqX -----END PGP SIGNATURE----- --Apple-Mail=_97B3F092-9712-4156-95D5-C3B0026CB0AE-- From ramakanthjosyula@gmail.com Mon Oct 7 05:03:53 2013 Return-Path: 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 E089221F9F21; Mon, 7 Oct 2013 05:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 rj6g7CVOLlr2; Mon, 7 Oct 2013 05:03:53 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB1B21E805F; Mon, 7 Oct 2013 05:03:48 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id gx14so5363979lab.23 for ; Mon, 07 Oct 2013 05:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=H0PLyHYk4hBVt/oh5ueQ+GhSvj9r9TPElKJa8TRYdjU=; b=Ea/VThEGRxGD/SIOHqTiUApVO0A3yjIbsGrnSH9nTIl86xCldfLcvDUg0s1HjmHJiG zQ84le4mt1uJId78uhMNRch3D723EA7kErPasAtrvdVluazw+oLEV8Fc9uNsQ/fFLhNI Qv1piRntARQxKWf/cDtv6ya1B/I5sMueCM5I0B6DQLWs449xNyXfBLIOedMaco29iJqs s1hHF7VJeInXlO4z7PouBsEjdOVJU1NweIcGlsW5Hy1EUXBC6HrJfj9DrJIJTFm0umSB ctB/asrrYYILVG2XDauY5yAHpdFhw+aVfJnGmV/Ar/c833FmgRrDujtW7ECRlCfcQZjL 3D5w== MIME-Version: 1.0 X-Received: by 10.152.8.115 with SMTP id q19mr26604117laa.16.1381147427344; Mon, 07 Oct 2013 05:03:47 -0700 (PDT) Received: by 10.114.200.176 with HTTP; Mon, 7 Oct 2013 05:03:47 -0700 (PDT) Date: Mon, 7 Oct 2013 17:33:47 +0530 Message-ID: From: Ramakanth Josyula To: dhcwg@ietf.org, pim@ietf.org Content-Type: multipart/alternative; boundary=001a11c34f5cca181f04e825711a Cc: josyular@brocade.com Subject: [dhcwg] Review request - draft-josyula-dhc-multicast - DHCP Option for IPTV source addresses X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 12:03:54 -0000 --001a11c34f5cca181f04e825711a Content-Type: text/plain; charset=ISO-8859-1 Hi, I have submitted the below internet draft proposing a new DHCP option for IPTV source addresses. http://www.ietf.org/internet-drafts/draft-josyula-dhc-multicast-02.txt I would request you to review this document and provide the comments on standardizing the same. Please guide me through the process if I miss anything with respect to the process of the review. Thanks and regards, Ramakanth. *Below is the brief introduction about the background and the benefits of the proposed option :* *Back ground : * IPTV Solution is widely integrated as part of the broadband networks in triple/multi play solutions. In many cases this service is run by delivering multicast streams to the IP hosts/Set top boxes connected to the home gateways. IGMP protocol in IPv4 networks and MLD protocol in IPv6 networks are commonly used for requesting these multicast streams from the nearest router connected via an access network. By using the IGMP version-3 in IPv4 networks and MLD version-2 in IPv6 networks, the hosts can request multicast streams from the specific set of multicast sources. The proposed option is intended to supply all the available IPv4 or IPv6 source addresses from which the multicast hosts can request and receive the multicast streams. *Benefits of implementing this option :* - It provides an effective method for maintaining and updating the multicast source address information to every multicast host in the network as per their individual SLAs. - Intermediate access nodes can snoop this option from the DHCP messages to extend the its multicast services like : Authentication of multicast users, integrating non-source aware multicast clients etc. - Convergence of IPTV services from different users can be achieved at the user level irrespective of the multicast transmitting technologies used in the network. For example, any service provider who manages the aggregation and access networks can receive the multicast streams from different sources/networks (may not be under their own administration) and feed them to their access networks. - The subscribers can easily validate the quality of the service offered by different IPTV sources dynamically and switch to the interested source as per their own set of requirements. --001a11c34f5cca181f04e825711a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

I have submitted the below internet draft proposing a new DHCP option for IPTV source addresses.

http://www.ietf.org/internet-drafts/draft-josyula-dhc= -multicast-02.txt

I would request you to review this document and provide the comments on standardizing the same.

Please guide me through the process if I miss anything with respect to the process of the review.


Thanks and regards,

Ramakanth.


Below is the brief introduction about the background and the benefits of the proposed option :


Back ground :

=A0

IPTV Solution is widely integrated as part of the broadband networks in triple/multi play solutions. In many cases this service is run = by delivering multicast streams to the IP hosts/Set top boxes connected to the home gateways.=A0 IGMP protocol in IPv4 networks and=A0=A0 MLD protocol in IPv6 networks are commonly used for requesting these=A0 multicast streams from the nearest router connected via an access network. = By using the IGMP version-3 in IPv4 networks and MLD version-2 in IPv6 network= s, the hosts can request multicast streams from the specific set of multicast sources.

The proposed option is intended to supply all the available IPv4 or IPv6 source addresses from which the multicast hosts can request an= d receive the multicast streams.

=A0Benefits of implementing this option :

- It provides an effective method for maintaining and updating the multicast source address information to every multicast host in the network as per their individual SLAs.

- Intermediate access nodes can snoop this option from the DHCP messages to extend the its multicast services like : Authentication of multicast users, integrating non-source aware multicast clients etc.

- Convergence of IPTV services from different users can be achieved at the user level irrespective of the multicast transmitting technologies used in the network. For example, any service provider who manages the aggregation and access networks can receive the multicast streams from different sources/networks (may not be u= nder their own administration) and feed them to their access networks.=A0

- The subscribers can easily validate the quality of the service offered by different IPTV sources dynamically and sw= itch to the interested source as per their own set of requirements.

=A0

--001a11c34f5cca181f04e825711a-- From ramakanthjosyula@gmail.com Mon Oct 7 07:54:30 2013 Return-Path: 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 073B021F9FE7 for ; Mon, 7 Oct 2013 07:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 7Oz0E6T1LWtq for ; Mon, 7 Oct 2013 07:54:29 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7A62011E80EC for ; Mon, 7 Oct 2013 07:54:28 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id o14so5746349lbi.32 for ; Mon, 07 Oct 2013 07:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=qTG7fXrloiR0anzi9DjAnW3ud9Ngq2C2apDOfRM3jwg=; b=ba6qwKRqfBdCHAUiwpHV0dNClccVDIWP33F76C9d8SUSydqOVxG97v4OcN0Z7L06Mf Oib0vzIsGOZAMmTVicvWUmRNIGEFKs0NAAW0fd7ErzQZ8xP6PihAWzsm+e6IA6XJaz4X Bkmn9yhsvFhRExN6PjjmIftjcCVWVRFc3oNRYzykHLhLiwHUCQ286rpcSDlnivqF66XN ICmxwAL8htA2RD6zta9TPpaqndeLsF3GpP128O/xeDTXtmyTjl83B6IFzKbE5OPplv0A Je++yDZVAgd5t1w9Vwd2ffHHIcQua1bBbPI3RfUlnZJlKL3dAS8kFGuCaZIkc2LEuM6v MtZg== MIME-Version: 1.0 X-Received: by 10.112.72.229 with SMTP id g5mr26151748lbv.10.1381157666115; Mon, 07 Oct 2013 07:54:26 -0700 (PDT) Received: by 10.114.200.176 with HTTP; Mon, 7 Oct 2013 07:54:26 -0700 (PDT) Date: Mon, 7 Oct 2013 20:24:26 +0530 Message-ID: From: Ramakanth Josyula To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=001a11c238e81158b304e827d48c Cc: josyular@brocade.com Subject: [dhcwg] Review request - draft-josyula-dhc-multicast - DHCP Option for IPTV source addresses X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:54:30 -0000 --001a11c238e81158b304e827d48c Content-Type: text/plain; charset=ISO-8859-1 Hi, I have submitted the below internet draft proposing a new DHCP option for IPTV source addresses. http://www.ietf.org/internet-drafts/draft-josyula-dhc-multicast-02.txt I would request you to review this document and provide the comments on standardizing the same. Please guide me through the process if I miss anything with respect to the process of the review. Thanks and regards, Ramakanth. *Below is the brief introduction about the background and the benefits of the proposed option :* *Back ground : * IPTV Solution is widely integrated as part of the broadband networks in triple/multi play solutions. In many cases this service is run by delivering multicast streams to the IP hosts/Set top boxes connected to the home gateways. IGMP protocol in IPv4 networks and MLD protocol in IPv6 networks are commonly used for requesting these multicast streams from the nearest router connected via an access network. By using the IGMP version-3 in IPv4 networks and MLD version-2 in IPv6 networks, the hosts can request multicast streams from the specific set of multicast sources. The proposed option is intended to supply all the available IPv4 or IPv6 source addresses from which the multicast hosts can request and receive the multicast streams. *Benefits of implementing this option :* - It provides an effective method for maintaining and updating the multicast source address information to every multicast host in the network as per their individual SLAs. - Intermediate access nodes can snoop this option from the DHCP messages to extend the its multicast services like : Authentication of multicast users, integrating non-source aware multicast clients etc. - Convergence of IPTV services from different users can be achieved at the user level irrespective of the multicast transmitting technologies used in the network. For example, any service provider who manages the aggregation and access networks can receive the multicast streams from different sources/networks (may not be under their own administration) and feed them to their access networks. - The subscribers can easily validate the quality of the service offered by different IPTV sources dynamically and switch to the interested source as per their own set of requirements. --001a11c238e81158b304e827d48c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

I have submitted the below internet draft proposing a new DHCP option for IPT= V source addresses.

http://www.ietf.org/internet-drafts/draft-josyula-dhc= -multicast-02.txt

I would request you to review this document and provide the comments on standardizing the same.

Please guide me through the process if I miss anything with respect to the process= of the review.

=A0

Thanks and regards,

Ramakanth.

=A0

Below is the brief introduction about the background and the benefits of the prop= osed option :

=A0

Back ground :

=A0

IPTV Solution is widely integrated as part of the broadband networks in triple/m= ulti play solutions. In many cases this service is run by delivering multicast streams to the IP hosts/Set top boxes connected to the home gateways.=A0 IGMP protocol in IPv4 networks and=A0=A0 MLD protocol in IPv6 networks are commonly used for requesting these=A0 multicast streams from the neares= t router connected via an access network. By using the IGMP version-3 in IPv4 networks and MLD version-2 in IPv6 networks, the hosts can request multicas= t streams from the specific set of multicast sources.

The proposed option is intended to supply all the available IPv4 or IPv6 source addresses from which the multicast hosts can request and receive the multic= ast streams.

=A0Benefits of implementing this option :

- It provides an effective method for maintaining and updating the multicast source address information to every multicast host in the network as per th= eir individual SLAs.

- Intermediate access nodes can snoop this option from the DHCP messages to extend the its multicast services like : Authentication of multicast users, integrating non-source aware multicast clients etc.

- Convergence of IPTV services from different users can be achieved at the us= er level irrespective of the multicast transmitting technologies used in the network. For example, any service provider who manages the aggregation and access networks can receive the multicast streams from different sources/networks (may not be under their own administration) and feed them = to their access networks.=A0

- The subscribers can easily validate the quality of the service offered by different IPTV sources dynamically and switch to the interested source as p= er their own set of requirements.

=A0

--001a11c238e81158b304e827d48c-- From tomasz.mrugalski@gmail.com Mon Oct 7 10:34:53 2013 Return-Path: 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 2446611E8102 for ; Mon, 7 Oct 2013 10:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 g0LSt-qVlIbC for ; Mon, 7 Oct 2013 10:34:52 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7036E21F9F6F for ; Mon, 7 Oct 2013 10:34:52 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e53so3474598eek.27 for ; Mon, 07 Oct 2013 10:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4yaINN0prISoN75HPICMqYLjnpLbstuHf3UL+jwvjpA=; b=pu1TMiE8KH7Xa8645mD/joheup39XNe/S4MnGZ6bGi8b+OCpPYKhjw6iRq7Z3Nclbb TkPqIMSGNfPqBWNsJEMrAqwGAm26wetb/LbHAXPbNFS9D/d10TQV8B7wvlxPmjCyCUFM iQPlvxeimhOTdHEhtRjRCSP/lO8WbJgAPN81qvVphDtvQWzM5jW6ern8TXp30PZXpUqW 8JPgrcxNEgnOeURbuz4+CRylI8/6Bl/vhB57T87bs6Sc36CRuBAClepZ0IqVu6N76cid Q1P079ju8U7f0zQC1weBLQqnAAjjJUSePmeNVEW3R3V8HWABVoeP0VnpkjGIemRJcNpt RW0Q== X-Received: by 10.15.98.194 with SMTP id bj42mr51151598eeb.12.1381167291532; Mon, 07 Oct 2013 10:34:51 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id r48sm65709966eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Oct 2013 10:34:50 -0700 (PDT) Message-ID: <5252F0B3.5000101@gmail.com> Date: Mon, 07 Oct 2013 19:34:43 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Bernie Volz (volz)" , "dhcwg@ietf.org" References: <489D13FBFA9B3E41812EA89F188F018E1ACF6595@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ACF6595@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20131007193443943 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] Call for Agenda Items for IETF-88 (Vancouver) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 17:34:53 -0000 On 06.10.2013 21:24, Bernie Volz (volz) wrote: > We are starting the call for agenda items. The co-chairs will finalize > the agenda about two weeks before the meeting and will give priority to > items as follows (in this order): > If you would like time, please indicate: > - Draft name or topic > - Who will present > - How much time is needed > > - Why is time needed (tell us why you can’t get what you need > by posting on the mailing list) and what will be covered I'd like to request a 20 minutes slot for RFC3315bis work. There's no draft yet. I will be the presenter. This time is needed, because 3315bis is in the charter and advancement of the DHCPv6 protocol is one of primary goals of this WG. This will be more or less a follow-up discussion to the discussion that will happen soon on the mailing list (will send out an initial proposal in couple days). I'd like to discuss the following issues: - clarify the goal of the 3315bis work - scope of work: - coming up with a list of RFCs and drafts that we want to merge - coming up with a proposed list of changes + justifications why they are necessary - call for volunteers - work organisation (a "design" or "editors" team? where to store intermediate draft revisions?) Tomek From tom.taylor.stds@gmail.com Tue Oct 8 03:17:04 2013 Return-Path: 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 94ED711E819C for ; Tue, 8 Oct 2013 03:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599] 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 mTyoNBs7ox9c for ; Tue, 8 Oct 2013 03:17:04 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0A45911E819B for ; Tue, 8 Oct 2013 03:16:59 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id e14so19243731iej.34 for ; Tue, 08 Oct 2013 03:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Nq7k2/F7Z7OZKaYuS8tcuvfjpvXr5qB/AlxkB74M+vs=; b=RBzESvYkDMcS1DLDPb+AzLePihQMA4EGA51bYRCrDoBQWq61KMzqCG9geUW6KOriYq EQWw9x7myBXkqLTcJPqnm9l0E3Z29qNA7itzJEiGZ8X2O1aUy5RfbVmJrxMYyeMfR5V8 CqSXZje+iGX8MDwor3QD06lpVXG6qBBNWY6zef6RYX8Bt/B/UxS76q2HODS05dXBbG1W +sAhr9qG62Uw2kv9VSN14rUkM+dJQAv1D78YRSoDmCIkl0gnb9xj1q8tV5YvO+GCYqYK UkY4u5X4lWzhnOWpWxS7QbQc6wa7rvL/iEBhHnOwl6kj8TE+gdKGL1yisq3PIx+cBPMK 0UmA== X-Received: by 10.42.250.148 with SMTP id mo20mr528358icb.34.1381227419273; Tue, 08 Oct 2013 03:16:59 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id w4sm2011415igb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Oct 2013 03:16:58 -0700 (PDT) Message-ID: <5253DB98.7080409@gmail.com> Date: Tue, 08 Oct 2013 06:16:56 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ramakanth Josyula References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Review request - draft-josyula-dhc-multicast - DHCP Option for IPTV source addresses X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:17:04 -0000 Before I actually look at the document, could I suggest that you draw it to the attention of the MBONED Working Group? They have a related problem statement document draft-ietf-mboned-multrans-addr-acquisition-02 that might benefit from adding your ideas. Tom Taylor On 04/10/2013 2:16 PM, Ramakanth Josyula wrote: > Hi, > > I have submitted the below internet draft proposing a new DHCP option > for IPTV source addresses. > > http://www.ietf.org/internet-drafts/draft-josyula-dhc-multicast-02.txt > > I would request you to review this document and provide the comments on > standardizing the same. > > Please guide me through the process if I miss anything with respect to > the process of the review. > > Thanks and regards, > > Ramakanth. > > *Below is the brief introduction about the background and the benefits > of the proposed option :* > > *_Back ground : _* > > IPTV Solution is widely integrated as part of the broadband networks in > triple/multi play solutions. In many cases this service is run by > delivering multicast streams to the IP hosts/Set top boxes connected to > the home gateways. IGMP protocol in IPv4 networks and MLD protocol in > IPv6 networks are commonly used for requesting these multicast streams > from the nearest router connected via an access network. By using the > IGMP version-3 in IPv4 networks and MLD version-2 in IPv6 networks, the > hosts can request multicast streams from the specific set of multicast > sources. > > The proposed option is intended to supply all the available IPv4 or IPv6 > source addresses from which the multicast hosts can request and receive > the multicast streams. > > *_Benefits of implementing this option :_* > > - It provides an effective method for maintaining and updating the > multicast source address information to every multicast host in the > network as per their individual SLAs. > > - Intermediate access nodes can snoop this option from the DHCP > messages to extend the its multicast services like : Authentication of > multicast users, integrating non-source aware multicast clients etc. > > - Convergence of IPTV services from different users can be achieved > at the user level irrespective of the multicast transmitting > technologies used in the network. For example, any service provider who > manages the aggregation > > and access networks can receive the multicast streams from > different sources/networks (may not be under their own administration) > and feed them to their access networks. > > - The subscribers can easily validate the quality of the service > offered by different IPTV sources dynamically and switch to the > interested source as per their own set of requirements. > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From Ted.Lemon@nominum.com Tue Oct 8 14:38:27 2013 Return-Path: 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 D6D1621F9425; Tue, 8 Oct 2013 14:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 e8GjRvGWcHF6; Tue, 8 Oct 2013 14:38:21 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id D6A0A21F9E36; Tue, 8 Oct 2013 14:38:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUlR7QzyilopJqYkJl6Dx3Zbkv4gYEYJs@postini.com; Tue, 08 Oct 2013 14:38:12 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A82C21B82DF; Tue, 8 Oct 2013 14:38:11 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6630F190061; Tue, 8 Oct 2013 14:38:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Oct 2013 14:38:10 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: Date: Tue, 8 Oct 2013 17:38:08 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 21:38:28 -0000 On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy) = wrote: > Part of why you can't do this with DHCP is that clients are written so = that when an IP address fails to work for an application connection, the = application re does the DNS and gets the new address (assuming TTL had = been moved down during the move). Applications can not tell the OS to = redo DHCP when they fail an application level connection.=20 This use case is a good example of when to use an FQDN format for a DHCP = option. However, it's not a great example of when to use a DHCP = option=97configuring SIP servers with DHCP is generally a bad idea, = because if your device is connected to a new network, it will blindly = take the SIP server IP address or FQDN information from the DHCP server = and use it, and that SIP server might well perform an MitM attack or the = like. So it's only in the very restricted use case of a Cisco IP phone = permanently installed on a desktop and connected to a trusted network = that (a) configuring SIP via DHCP makes sense, and (b) using the FQDN is = a good idea. Of course it's possible that my limited understanding of = how SIP works is preventing me from seeing why it's safe to configure = SIP service using DHCP, but I'm assuming that that's not the case in = this argument; please feel free to correct me. We've actually been having this same conversation on the iesg mailing = list, and I asserted that SIP was something you ought not to configure = with DHCP; your use case is the one case where it sort of makes sense. = Can you think of similar use cases where it actually makes sense to = configure these parameters via DHCP? Possibly the right solution is to update the document to talk about this = sort of restricted use case as one where FQDNs actually do make sense. = The document certainly doesn't say you _can't_ use FQDNs, but we see = people wanting to use them a lot in cases where they really don't make = sense, hence the advice. Historically I don't think we bothered to = make this distinction when defining new DHCP options, but it seems like = a useful distinction to make. From fluffy@cisco.com Tue Oct 8 13:31:04 2013 Return-Path: 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 65FB521F99DD; Tue, 8 Oct 2013 13:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ZiLFae1wY0ib; Tue, 8 Oct 2013 13:30:57 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id CC84021F9E6A; Tue, 8 Oct 2013 13:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4502; q=dns/txt; s=iport; t=1381264238; x=1382473838; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O2Skf5ZXfSNfBnucdwDsvEcjTAv7fhWXJ41CeQKOtuI=; b=XPx5inqYFF+H2g07AgEvHiOPmLC2GTXlNCPHM8Re6AwchBV0wPMvmuwC yZXBYbVBdwhKjD7b2n8UAVW2IGxUNpypwpMEIvusEQzvq3aZOQLcqjC7R uEBo+UYLdwQODo5mGeJAVg/jxiwHT7tPpW5qHf48FiHI4O3o1GtOyYnoN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFABRrVFKtJV2c/2dsb2JhbABZgwc4UsEngSMWbQeCJQEBAQMBbgsQAgEIIhkLMhQRAgQOBQiHeAYMulSOCoEFAjEHgx+BBAOZMJBRgWaBPoIq X-IronPort-AV: E=Sophos;i="4.90,1058,1371081600"; d="scan'208";a="269694375" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 08 Oct 2013 20:30:37 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r98KUb12022768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Oct 2013 20:30:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 8 Oct 2013 15:30:36 -0500 From: "Cullen Jennings (fluffy)" To: "ietf@ietf.org" Thread-Topic: Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice Thread-Index: AQHOxGU+x36dkMJ3pkem9MOxfSCBUg== Date: Tue, 8 Oct 2013 20:30:36 +0000 Message-ID: References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> In-Reply-To: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5275A41775A20145A8667DA6B35F94CD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 08 Oct 2013 15:49:41 -0700 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 20:31:04 -0000 (Dear OPs ADs, please read =85 ) I disagree with the advice in section 8. Cisco IP phones have been deploye= d with DHCP options that use FQDN and with options that use IP addresses. F= or this type of use case the FQDM turned out to be much better from an oper= ational and administration point of view. IT departments are used to making= sure that changes of IP addresses on servers are well coordinated with cha= nges to the DNS - they are good at doing that and that and have good tools = for it. Conversely, they are not used to coordinating server changes with D= HCP changes and do not have good tools for that. Part of why you can't do t= his with DHCP is that clients are written so that when an IP address fails = to work for an application connection, the application re does the DNS and = gets the new address (assuming TTL had been moved down during the move). Ap= plications can not tell the OS to redo DHCP when they fail an application = level connection.=20 For nearly every case in the real world, the power and RTT and reliability = issues are simply not relevant - regardless of which way you do it, the a= pplication is unlikely to work if DNS is down, the extra RTT make no speed = difference the user can percieve and the power difference over a day of use= of the application is so small it is not measurable.=20 FQDN allow usage of things like DNS SRV for load balancing, happy eye balls= for v6 transition, and make it easier to get things to geographically clos= e servers.=20 I don't think it should come a a shock to anyone that the level of indirect= ion that FQDNs provides turns out to be a really useful tool. Lets use that= indirection tool where appropriate.=20 Related to this, the advice in section 12 seems a bit off to me. I understa= nd the issues - but keep in mind that many modern applications (browsers an= d SIP phones for example) do the DNS inside the application instead of usin= g the OS resolvers. Part of the reason for this is asynchronous resolution = but part of it is also control of which interface is used for DNS and if mu= ltiple interfaces are used, being able to keep the applications traffic on = the the appropriate interface for the DNS server that returned the address.= So while I agree that=20 "Existing nodes cannot be assumed to systematically segregate configuration information on the basis of its source;" Equally true is you can't assume the converse of that. So I think the state= ment that=20 As a consequence, DNS resolution done by the DHCP server is more likely to behave predictably than DNS resolution done on a multi-interface or multi- homed client. Is just plain wrong. I think it would be more accurate to say in these case= s the results are not always predictable. The issue is the DHCP server may = get an DNS answer that contains and server that can not even be reached by = the DHCP client.=20 As a general rule of thumb, using FQDN in the configuration of a DHCP serve= r is a really bad idea because IT admins assume that if they change the the= DNS information, the clients will get the new information. But they don't.= =20 Cullen On Sep 19, 2013, at 3:54 PM, The IESG wrote: >=20 > The IESG has received a request from the Dynamic Host Configuration WG > (dhc) to consider the following document: > - 'Guidelines for Creating New DHCPv6 Options' > as Best Current Practice >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-10-03. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document provides guidance to prospective DHCPv6 Option > developers to help them creating option formats that are easily > adoptable by existing DHCPv6 software. This document updates > RFC3315. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 From ianfarrer@gmx.com Wed Oct 9 00:29:14 2013 Return-Path: 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 2495C21E80DE for ; Wed, 9 Oct 2013 00:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] 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 o62tAgJRXHOc for ; Wed, 9 Oct 2013 00:29:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id C751C21E80DD for ; Wed, 9 Oct 2013 00:29:04 -0700 (PDT) Received: from [10.53.172.190] ([88.128.80.2]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LeMWL-1W8QGQ0uvF-00q8Ea for ; Wed, 09 Oct 2013 09:29:03 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ian Farrer In-Reply-To: <2C4C5302-C2CA-4F85-B053-78D317FD7964@employees.org> Date: Wed, 9 Oct 2013 09:29:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A7ED0DA-EE87-496C-AC7D-C4D3D937FB84@gmx.com> References: <20130930140054.31558.95411.idtracker@ietfa.amsl.com> <6A05E003-42A2-4659-9F23-6F5DFC6A88EF@gmx.com> <2C4C5302-C2CA-4F85-B053-78D317FD7964@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:RMIuiGSOwjB+mqJ30ankRzdBBY5Agj+iKYekKPgBqiizpoJy0Tf NDoOE3nV/4sFPYbQXZyFcYUQJGr1duACuTI9dTW/4U5MPZQisu0KDdWsiuDJMX0xK+9Sctv +YShuUocQedQ/6at248UYn1mX93dRpmTWFcaMKdWroru2wMR9bc0XcTWM2pqyYPvjrRWird 2/4bMSesee84r3tb32QXQ== Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 07:29:14 -0000 Hi Ole, Thanks for the review. Please see inline. Cheers, Ian On 7 Oct 2013, at 11:55, Ole Troan wrote: > all, >=20 > here are some comments on a first read of the document. >=20 > I have to general comments. one is on fate-sharing (see below), the = other on address provisioning conflicts. >=20 > MAP provides a data-link layer that supports transport of IPv4. given = that it uses embedded addresses from > IPv6 to algorithmically determine an end-points IPv4 address, you can = say that IPv4 addressing is inherit=20 > in the data-link layer. in this model the IPv4 address is tied to = IPv6. this document proposes to provision IPv4 > addressing separately with DHCPv4. either this document needs to = describe how this is supposed to work, > or I think make a larger separation between in which cases only = stateless DHCPv4 can be used, versus > which data-links that also stateful DHCPv4 can be used. (I'm only = aware of Public 4over6 that can support full DHCPv4). [ian] Could we clarify this by extending the introduction to scope the = document a little more? Something like: In the most basic case of IPv4 provisioning, where the client only needs = to receive a static IPv4 address and restricted port range assignment = (with no dynamic address leasing or additional IPv4 configuration), = DHCPv6 based approaches (such as the one proposed in = [I-D.ietf-softwire-map-dhcp] may provide a suitable solution. This = document is concerned with more complex IPv4 configurations scenarios, = to bring DHCPv4 configuration over IPv6 only networks in line with = DHCPv4 over IPv4 networks. >=20 >=20 > Section 1.1 > "2. Extend DHCPv6 with new options for IPv4 configuration, such as > [I-D.ietf-softwire-map-dhcp] describes." >=20 > I think that could be phrased better. MAP DHCP does give the CE = enough > information so that it can calculate it's own IPv4 address. Here it = reads as if > we're adding DHCPv4 options to DHCPv6. > I'm not even sure you should have MAP DHCP in this table, it is not a = solution > for passing DHCPv4 options, nor is it a solution to replicate all = DHCPv4 options > in DHCPv6. It is a solution for having the CE calculate it's own IPv4 = address, > shared IPv4 address or prefix. Note that the last two are not even = supported in DHCPv4. > It does not offer any other IPv4 configuration information. [ian] The text at the moment says that 'DHCPv6 has been extended to = convey the parameters necessary for IPv4 in IPv6 softwire configuration' = which is true. It doesn't say that MAP DHCP has, or will be, extended = any further with additional DHCPv4 options. So, as an example of extending DHCPv6 to carry IPv4 configuration, it's = accurate. However, if we go with the scoping clarification above then we = could remove the reference here. >=20 > If you have it in the "approaches" list at all: > 2. Depend on the setup of data-link (softwire) to offer enough = information to create IPv4 addressing. > Require no other IPv4 configuration information. >=20 > ** Reading section 1.3. If you want this approach to be "copy = relevant DHCPv4 options into DHCPv6", > then I suggest removing all references to MAP-DHCP. >=20 [ian] See above. > Rename 3. to "stateless DHCPv4" or DHCPINFORM only. >=20 [ian] You mean the approach that's currently called DHCPv6+DHCPv4oSW = (horrible name:-)? If so, are you proposing 'DHCPv6+stateless DHCPv4 = over SW' as the new name? I not sure that's much better... >=20 > Section 2: > Drop requirement 6, I can't see how you can evaluate that. [ian] You can evaluate it on the following basis: If the requirements = that are described in this document are not your requirements as an = operator, then you shouldn't be forced to use whatever the conclusion of = this document is. In practical terms, I see this as 'if MAP DHCP meets = your requirements, you don't need to bring in DHCPv4 over Foo or = whatever else'. > 8 is empty >=20 [ian] Will fix. > I suggest you add a new requirement: > x. Fate sharing. The provisioning of IPv4 addressing and other = configuration information should be logically tied > to the data-link layer that is uses to provide IPv4 connectivity. [ian] This one's going to be more of a problem, as it pretty much = directly conflicts with requirement 7, in that the two contradict each = other. You can only implement data link fate sharing if you've got a hub = and spoke architecture to locate the hub in (so that if it's not = available, then IPv4 provisioning also fails) In the case of a pure mesh network, with no hub and spoke, how could you = have fate sharing for the data-link layer? The proposed requirement = pre-supposes a specific underlying architecture.=20 Can we put this one to the workgroup to ask if this should be included = as a new req, as it' has not been previously discussed? >=20 > Section 3: > DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing. [ian] Why is it a 'no' for req 4? Section 8 of the DHCPv4 over DHCPv6 = draft: Additionally, the DHCPv6 relay agent MAY allow the configuration of dedicated DHCPv4 over DHCPv6 specific destination addresses, differing from the addresses of the DHCPv6 only server(s). To implement this function, the relay checks the received DHCPv6 message type and forwards according to the following logic: 1. If the message type is BOOTREQUESTV6, then the DHCPv6 request is relayed to the configured DHCPv4 aware 4o6 Server's address(es). 2. For any other DHCPv6 message type, forward according to section 20 of [RFC3315]. For the fate sharing req, as stated above. >=20 > In the evaluation in section 3.x I suggest dropping the use of = "complex" and "simple". > That appears very subjective. >=20 [ian] OK > 3.4.2 bullet 3. applies to all approaches allowing DHCPv4 leases. [ian] How so? If you have a 'wrapper' type of approach (where DHCPv4 is = being put into IPv6 or DHCPv6), then the DHCPv4 over xv6 client function = can be agnostic to what the physical interface is beyond 'it must = support multicast or unicast'. If the DHCPv4oSW mechanism is not linked = just to softwires and is essentially a 'vanilla' DHCPv4 client, then it = must have awareness of the link layer capabilities of the link on which = it is running and potentially adapt it's behaviour accordingly, such as = per-client l4 port-restrictions. > bullet 4. please expand. [ian] This was from a question I asked on the ML some time ago, but = wasn't answered. Does MAP-T support broadcasts through the translator = function? > bullet 5. change to "Restricted to a broadcast capable = link-layer." [ian] Is the hub-and-spoke restriction incorrect? As mentioned above, I = don't see how this approach can work in a mesh environment. The = 'broadcast capable' restriction is not correct as if a h&s softwire can = support broadcast, then a ptp mesh softwire can as well. You could = broadcast DHCPDISCOVERs to peers in a mesh group, but it's not going to = get you any response. >=20 > 3.5.1 bullet 3. DHCPv4 and DHCPv6 cannot really be separated from = each other since it=20 > it is DHCPv6 that provides transport for DHCPv4. and support = for the new BOOTP messages > are required in DHCPv6. [ian] But a dedicated DHCPv4 over DHCPv6 server could be deployed = separate from the DHCPv6 only server. What about changing to read?: 'DHCPv4 and DHCPv6 based provisioning infrastructure can be seperated' >=20 > Minor comments: > Introduction: > "A general trend here is to relocate NAT44 functionality and IPv4 > address sharing from the centralized tunnel concentrator to the CPE > in order to achieve better scalability. " >=20 > I understand what you are trying to say, but unless the reader = understands that the starting point > are mechanisms like NAT444 and DS-lite, he would find this strange. = As current deployments > of IPv4 already use distributed NAT. [ian] What about changing the wording to: 'A general trend here is to relocate the translation of privately = addressed IPv4 traffic to a shared, public external address from the = centralized tunnel concentrator to the CPE. The distribution of this = function allows for better scalability.' >=20 >=20 > cheers, > Ole >=20 >=20 > On Sep 30, 2013, at 16:14 , Ian Farrer wrote: >=20 >> Hi, >>=20 >> I've just posted an update to the draft based on the discussions in = Berlin and Francis' review. >>=20 >> The contents of the conclusion remains unchanged. >>=20 >> Any comments etc. appreciated. >>=20 >> Cheers, >> Ian >>=20 >>=20 >> On 30 Sep 2013, at 16:00, internet-drafts@ietf.org wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Dynamic Host Configuration Working = Group of the IETF. >>>=20 >>> Title : Provisioning IPv4 Configuration Over IPv6 Only = Networks >>> Author(s) : Branimir Rajtar >>> Ian Farrer >>> Filename : draft-ietf-dhc-v4configuration-02.txt >>> Pages : 17 >>> Date : 2013-09-30 >>>=20 >>> Abstract: >>> As IPv6 becomes more widely adopted, some service providers are >>> taking the approach of deploying IPv6 only networks, without dual- >>> stack functionality for IPv4. However, access to IPv4 based = services >>> is still an ongoing requirement and approaches such as IPv4-in-IPv6 >>> softwire tunnels are being developed to meet this need. >>>=20 >>> In order to provision end-user's hosts with the necessary IPv4 >>> configuration, a number of different mechanisms have been proposed. >>> This memo discusses the benefits and drawbacks of each, with the aim >>> of recommending a single approach as the basis for future work. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-02 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-v4configuration-02 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From jiangsheng@huawei.com Wed Oct 9 01:30:03 2013 Return-Path: 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 1761F21F9A05 for ; Wed, 9 Oct 2013 01:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hxp-LnX8FqVz for ; Wed, 9 Oct 2013 01:29:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8339221F9A78 for ; Wed, 9 Oct 2013 01:29:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWP33856; Wed, 09 Oct 2013 08:29:56 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 09:29:16 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 09:29:48 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 16:29:34 +0800 From: Sheng Jiang To: "" Thread-Topic: New Version Notification for draft-jiang-dhc-stateless-reconfiguration-00.txt Thread-Index: AQHOw9nQKCTG6gv4S0OORgUv/i3SN5nsBO9Q Date: Wed, 9 Oct 2013 08:29:33 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD4661C@nkgeml512-mbx.china.huawei.com> References: <20131008035221.3492.40090.idtracker@ietfa.amsl.com> In-Reply-To: <20131008035221.3492.40090.idtracker@ietfa.amsl.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] New Version Notification for draft-jiang-dhc-stateless-reconfiguration-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 08:30:03 -0000 SGksIERIQ2VycywNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQsIHdoaWNoIHRhcmdl dHMgdGhlIHByb2JsZW0gdGhhdCBzdGF0ZWxlc3MgREhDUHY2IGxhY2tzIGEgbWVjaGFuaXNtIHRv IGluZm9ybSB0aGVzZSBjb25maWd1cmVkIGNsaWVudHMgaWYgc29tZSBjb25maWd1cmF0aW9uIGlu Zm9ybWF0aW9uIGlzIGNoYW5nZWQuIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1lY2hhbmlzbSB0 byBwcm9wYWdhdGUgYSBuZXdseSBkZWZpbmVkIFN0YXRlbGVzcy1SZWNvbmZpZ3VyZSBtZXNzYWdl IHRvd2FyZHMgc3RhdGVsZXNzIGNvbmZpZ3VyZWQgREhDUHY2IGNsaWVudHMsIGFsc28gdGhlIHJl bGV2YW50IGJlaGF2aW9ycy4NCg0KVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byBnZXQgcmV2aWV3 cyBieSB0aGUgV0csIHBhcnRpY3VsYXJseSBvbiB3aGV0aGVyIHRoaXMgcHJvYmxlbSBhcmUgdmFs aWQuIFdlIGFyZSBhbHNvIG9wZW4gZm9yIGRpc2N1c3Npb24gcmVnYXJkaW5nIHRvIHNvbHV0aW9u IGRlc2lnbi4gU2V2ZXJhbCBkZXNpZ24gcXVlc3Rpb25zIGFyZSBsaXN0ZWQgaW4gdGhlIGRvY3Vt ZW50IGZvciBXRyB0byBkZWNpZGUuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcgKyBCaW5nDQoN Cj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj5TZW50OiBUdWVzZGF5LCBP Y3RvYmVyIDA4LCAyMDEzIDExOjUyIEFNDQo+VG86IExpdWJpbmcgKExlbyk7IFNoZW5nIEppYW5n DQo+U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPmRyYWZ0LWppYW5nLWRo Yy1zdGF0ZWxlc3MtcmVjb25maWd1cmF0aW9uLTAwLnR4dA0KPg0KPg0KPkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1qaWFuZy1kaGMtc3RhdGVsZXNzLXJlY29uZmlndXJhdGlvbi0wMC50eHQN Cj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNoZW5nIEppYW5nIGFuZCBwb3N0 ZWQgdG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0KPkZpbGVuYW1lOgkgZHJhZnQtamlhbmct ZGhjLXN0YXRlbGVzcy1yZWNvbmZpZ3VyYXRpb24NCj5SZXZpc2lvbjoJIDAwDQo+VGl0bGU6CQkg U3RhdGVsZXNzIFJlY29uZmlndXJhdGlvbiBpbiBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbg0K PlByb3RvY29sIGZvciBJUHY2IChESENQdjYpDQo+Q3JlYXRpb24gZGF0ZToJIDIwMTMtMTAtMDgN Cj5Hcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5OdW1iZXIgb2YgcGFnZXM6IDgNCj5V Ukw6DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamlhbmctZGhj LXN0YXRlbGVzcy1yZWNvbmZpZ3VyYXRpb24NCj4tMDAudHh0DQo+U3RhdHVzOg0KPmh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamlhbmctZGhjLXN0YXRlbGVzcy1yZWNvbmZp Z3VyYXRpb24NCj5IdG1saXplZDoNCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1q aWFuZy1kaGMtc3RhdGVsZXNzLXJlY29uZmlndXJhdGlvbi0wMA0KPg0KPg0KPkFic3RyYWN0Og0K PiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1lY2hhbmlzbSB0byBwcm9wYWdhdGUgcmVjb25m aWd1cmUgbWVzc2FnZXMNCj4gICB0b3dhcmRzIHN0YXRlbGVzcyBjb25maWd1cmVkIERIQ1B2NiBj bGllbnRzLg0KPg0KPg0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K Pg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From Ted.Lemon@nominum.com Wed Oct 9 08:48:07 2013 Return-Path: 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 AA1AD11E819A; Wed, 9 Oct 2013 08:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 UWDjX2-zqf07; Wed, 9 Oct 2013 08:48:01 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id ACDF611E81BF; Wed, 9 Oct 2013 08:47:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUlV6qWz2SHwhh8JD4oTjEwVHPyPYR5p+@postini.com; Wed, 09 Oct 2013 08:47:54 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F2B231B82E5; Wed, 9 Oct 2013 08:47:52 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EA09A190061; Wed, 9 Oct 2013 08:47:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Oct 2013 08:47:52 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: Date: Wed, 9 Oct 2013 11:47:51 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:48:07 -0000 On Oct 9, 2013, at 11:26 AM, Cullen Jennings (fluffy) = wrote: > Help educate me on this a bit - I don't see all the things that get = requested of DHCP. What are some examples of things where people are = request FQDN where IP would be better. I think having some real examples = that have come up would make it easier to see what advice is needed. DNS server IP address. NTP server IP address. Router IP address (not = in DHCPv6, of course). AFTR IP address. Basically, network = infrastructure IP addresses. Bear in mind that the set of services configured by DHCP ought to be = pretty small=97just things that really are local network infrastructure = services, not things that are specific to the host and not to the = network. It's not even clear to me that NTP ought to be configured by = DHCP, and indeed in most cases it is not, despite there being an RFC = describing how to do it. Considering the case of SIP, when you configure SIP I think that's = probably a configuration that shouldn't change as the phone moves from = network to network. So it shouldn't be configured by DHCP. In the = case where the phone happens not to be likely to move from network to = network, you could _get away_ with using DHCP. But a solution that = would work for phones that _do_ move from network to network would also = work for phones that do not, and that solution would therefore be = preferable, particularly as an MTI solution, since it addresses all use = cases. As I mentioned in the IESG discussion, it is a shame that aggsrv didn't = become a working group, since it was intended to address this specific = problem, at least as I understood it. From fluffy@cisco.com Wed Oct 9 08:27:50 2013 Return-Path: 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 BEBED11E81B0; Wed, 9 Oct 2013 08:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 3y5ZAqeIGv0t; Wed, 9 Oct 2013 08:27:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2426811E81A7; Wed, 9 Oct 2013 08:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2731; q=dns/txt; s=iport; t=1381332423; x=1382542023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jubzkgbSbqERMjtJAeztuR6yTTZVdoDs9f7hl0UjD7Q=; b=lXMUfdjK4b+TlYUqdVIeVLiTSN2xVAij4olj36oqyS6mu5iPB6NgokJI Ie++TiAQbDYudDsz5NGBdGuT0XjyXlCcTo7IyoWnQ5lkWjRmIThU/A8/S en4C7zXvTyeESMxzvedxjBWa+rQjEWZE7y/b0CJCJZwQVs9ARpcZlwkOC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAOZ0VVKtJXHB/2dsb2JhbABagweBCsE2gR0WdIIlAQEBAwFuCwULAgEIGAoZCzIlAgQOBQgTh2UGuSOOBoEMAjEHAoMdgQQDqgSBZoE+gWhC X-IronPort-AV: E=Sophos;i="4.90,1064,1371081600"; d="scan'208";a="267025528" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 09 Oct 2013 15:26:59 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r99FQwn7029704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 15:26:58 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 10:26:58 -0500 From: "Cullen Jennings (fluffy)" To: Ted Lemon Thread-Topic: Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice Thread-Index: AQHOxG6tx36dkMJ3pkem9MOxfSCBUpns0u+A Date: Wed, 9 Oct 2013 15:26:57 +0000 Message-ID: References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5603CDFB277C35468D0983C357766839@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 09 Oct 2013 10:46:31 -0700 Cc: "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:27:51 -0000 On Oct 8, 2013, at 3:38 PM, Ted Lemon wrote: > On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy) w= rote: >> Part of why you can't do this with DHCP is that clients are written so t= hat when an IP address fails to work for an application connection, the app= lication re does the DNS and gets the new address (assuming TTL had been mo= ved down during the move). Applications can not tell the OS to redo DHCP w= hen they fail an application level connection.=20 >=20 > This use case is a good example of when to use an FQDN format for a DHCP = option. However, it's not a great example of when to use a DHCP option=97= configuring SIP servers with DHCP is generally a bad idea, because if your = device is connected to a new network, it will blindly take the SIP server I= P address or FQDN information from the DHCP server and use it, and that SIP= server might well perform an MitM attack or the like. >=20 > So it's only in the very restricted use case of a Cisco IP phone permanen= tly installed on a desktop and connected to a trusted network that (a) conf= iguring SIP via DHCP makes sense, and (b) using the FQDN is a good idea. = Of course it's possible that my limited understanding of how SIP works is p= reventing me from seeing why it's safe to configure SIP service using DHCP,= but I'm assuming that that's not the case in this argument; please feel fr= ee to correct me. Nah, it's not quite like that - Long story how that it but the security mec= hanism make sure you authenticate both ends to stop that.=20 >=20 > We've actually been having this same conversation on the iesg mailing lis= t, and I asserted that SIP was something you ought not to configure with DH= CP; your use case is the one case where it sort of makes sense. Can you t= hink of similar use cases where it actually makes sense to configure these = parameters via DHCP? >=20 > Possibly the right solution is to update the document to talk about this = sort of restricted use case as one where FQDNs actually do make sense. Th= e document certainly doesn't say you _can't_ use FQDNs, but we see people w= anting to use them a lot in cases where they really don't make sense, hence= the advice. Historically I don't think we bothered to make this distinct= ion when defining new DHCP options, but it seems like a useful distinction = to make. Help educate me on this a bit - I don't see all the things that get request= ed of DHCP. What are some examples of things where people are request FQDN = where IP would be better. I think having some real examples that have come = up would make it easier to see what advice is needed.=20 From fluffy@iii.ca Wed Oct 9 10:33:11 2013 Return-Path: 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 A619821E811C; Wed, 9 Oct 2013 10:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 og7NnDy-2hbR; Wed, 9 Oct 2013 10:33:06 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8883B21E805F; Wed, 9 Oct 2013 10:33:06 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 50CE722E200; Wed, 9 Oct 2013 13:32:59 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> Date: Wed, 9 Oct 2013 11:32:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Wed, 09 Oct 2013 10:46:54 -0700 Cc: "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:33:11 -0000 On Oct 9, 2013, at 9:47 AM, Ted Lemon wrote: > On Oct 9, 2013, at 11:26 AM, Cullen Jennings (fluffy) = wrote: >> Help educate me on this a bit - I don't see all the things that get = requested of DHCP. What are some examples of things where people are = request FQDN where IP would be better. I think having some real examples = that have come up would make it easier to see what advice is needed. >=20 > DNS server IP address. NTP server IP address. Router IP address = (not in DHCPv6, of course). AFTR IP address. Basically, network = infrastructure IP addresses. Well DNS and Router obviously won't work with FQDN so lets talk about = NTP for a minute. (and sorry, I don't even know what AFTR IP is). I = design lots of devices that have to be plugged into a network and just = start working with no user interaction. Getting the correct time is = often really useful to have - particularly with synchronization = protocols.=20 One approach would be to hard code that NTP server name in the the = product. That is not my preferred approach because stuff goes wrong and = you end up with things like = http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse . Another = approach is for DHCP to provide the NTP server info. I would argue that = getting a FQDN of the NTP server pool is a better design for DHCP than = getting an IP address because this allow DNS load balancing across the = pool and allows the server IP to change over time and still not have = client failures.=20 You agree that FQDN is would be a better design than IP for NTP ? >=20 > Bear in mind that the set of services configured by DHCP ought to be = pretty small=97just things that really are local network infrastructure = services, not things that are specific to the host and not to the = network. It's not even clear to me that NTP ought to be configured by = DHCP, and indeed in most cases it is not, despite there being an RFC = describing how to do it. >=20 > Considering the case of SIP, when you configure SIP I think that's = probably a configuration that shouldn't change as the phone moves from = network to network. =20 Agree - it does not change as phones move network to network. It is uses = DHCP the first time the phone is plugged in. The whole design is around = making sure the phone can go from the manufacture to the end user = without ever being removed from the box or powered up be an admin. The = admin configures the call control system based on knowledge about the = phone and which user the phone is going to but the admin does not need = to touch the phone. When the phone first boots it imprint baby duck = style on a network to get the configuration information which is = encrypted with that phones public key. After that the phone use that = configuration information not the DHCP (unless the phone is factory = reset). It's actually a lot more complicated than that because security = relies on replacement of manufacture certificates with the service = provider certificates to make sure a comprise of the manufactures CA = only results in service provider not being able to enroll new phones but = does not compromise security of operational phone network.=20 However, the first time the phone boots, DHCP needs to let the phone = know who the likely service provider might be. If the phone gets the = wrong DHCP information from an attacker or wrong network, the phone = fails to configure but does not suffer MITM attacks. Using DHCP for = phones has been used by pretty much every IP phone manufactures and most = enterprise deployments and many residential providers including folks = ranging from vonage to AT&T take advantage of it. DHCP greatly reduce = the deployment costs of setting up VoIP networks.=20 We had a lot of learning from the phone deployments and I expect us to = use what we learned there for how we do IoT. (I presented a paper on = this at the IAB workshop on IoT). One of the things we learned the hard = way was names work better than numbers.=20 > So it shouldn't be configured by DHCP. In the case where the phone = happens not to be likely to move from network to network, you could _get = away_ with using DHCP. But a solution that would work for phones that = _do_ move from network to network would also work for phones that do = not, and that solution would therefore be preferable, particularly as an = MTI solution, since it addresses all use cases. >=20 > As I mentioned in the IESG discussion, it is a shame that aggsrv = didn't become a working group, since it was intended to address this = specific problem, at least as I understood it. >=20 From Ted.Lemon@nominum.com Wed Oct 9 10:53:35 2013 Return-Path: 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 6A97611E80E2; Wed, 9 Oct 2013 10:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.582 X-Spam-Level: X-Spam-Status: No, score=-107.582 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 9pDW2RT3iMge; Wed, 9 Oct 2013 10:53:29 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id E05E221F9FB6; Wed, 9 Oct 2013 10:53:25 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUlWYFVr9E7wT2rdblFrRe5XEEfQb5mFW@postini.com; Wed, 09 Oct 2013 10:53:25 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 655811B82CE; Wed, 9 Oct 2013 10:53:25 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5775B190061; Wed, 9 Oct 2013 10:53:25 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Oct 2013 10:53:25 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: Date: Wed, 9 Oct 2013 13:53:23 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:53:35 -0000 On Oct 9, 2013, at 1:32 PM, Cullen Jennings wrote: > Well DNS and Router obviously won't work with FQDN so lets talk about = NTP for a minute. (and sorry, I don't even know what AFTR IP is). I = design lots of devices that have to be plugged into a network and just = start working with no user interaction. Getting the correct time is = often really useful to have - particularly with synchronization = protocols.=20 An AFTR IP address is like a router IP address, but for a particular = IPv4 transition technology. Other transition technologies of this sort = are classic examples of services that make sense to configure with DHCP, = because they are part of the network infrastructure. > One approach would be to hard code that NTP server name in the the = product. That is not my preferred approach because stuff goes wrong and = you end up with things like = http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse . Apple hard-codes the FQDN of a set of NTP servers they control into all = their products. I think other OS vendors do as well, but am not clear = on the details. The advantage of doing this is that you can then = authenticate your communication with the NTP server. If you use DHCP = to configure your NTP server, you cannot validate your communication = with your NTP server. Of course there's a bit of a chicken-and-egg = problem here in terms of replay attacks and key repudiation, but in = principle you get more security if you hard code the FQDN of your NTP = server than if you use DHCP to configure it. Of course there are cases where this doesn't matter, and DHCP is just = fine, but I can't think of any other than perhaps a self-setting wall = clock. Of course, if a CPE vendor were to hard-code the FQDN of an NTP server = belonging to someone else into their devices, that would be disastrous. > Another approach is for DHCP to provide the NTP server info. I would = argue that getting a FQDN of the NTP server pool is a better design for = DHCP than getting an IP address because this allow DNS load balancing = across the pool and allows the server IP to change over time and still = not have client failures.=20 You'd get the same effect if the DHCP server did the lookup. I agree = that if you want to suddenly add an NTP server and need it to be adopted = in a time frame shorter than your typical lease time, and your DNS TTL = is shorter than your typical lease time, you will get better service = using DNS, but there's no clear win here=97this would be a pretty weird = requirement. > You agree that FQDN is would be a better design than IP for NTP ? No. I think the boxes that need NTP configuration via DHCP are most = likely constrained devices, and that requiring them to do a DNS lookup = in addition to the DHCP transaction is unnecessary. Probably not a = hugely bad thing, but that depends on the device. A device with severe = constraints probably isn't using DHCP anyway. > Agree - it does not change as phones move network to network. It is = uses DHCP the first time the phone is plugged in. The whole design is = around making sure the phone can go from the manufacture to the end user = without ever being removed from the box or powered up be an admin. The = admin configures the call control system based on knowledge about the = phone and which user the phone is going to but the admin does not need = to touch the phone. When the phone first boots it imprint baby duck = style on a network to get the configuration information which is = encrypted with that phones public key. After that the phone use that = configuration information not the DHCP (unless the phone is factory = reset). It's actually a lot more complicated than that because security = relies on replacement of manufacture certificates with the service = provider certificates to make sure a comprise of the manufactures CA = only results in service provider not being able to enroll new phones but = does not compromise security of operational phone network.=20 >=20 > However, the first time the phone boots, DHCP needs to let the phone = know who the likely service provider might be. If the phone gets the = wrong DHCP information from an attacker or wrong network, the phone = fails to configure but does not suffer MITM attacks. Using DHCP for = phones has been used by pretty much every IP phone manufactures and most = enterprise deployments and many residential providers including folks = ranging from vonage to AT&T take advantage of it. DHCP greatly reduce = the deployment costs of setting up VoIP networks.=20 >=20 > We had a lot of learning from the phone deployments and I expect us to = use what we learned there for how we do IoT. (I presented a paper on = this at the IAB workshop on IoT). One of the things we learned the hard = way was names work better than numbers.=20 So what you've done here is to invent a service configuration protocol = that leverages existing DHCP server infrastructure, uses packets that = look just like DHCP packets, but is not actually DHCP. A client that = behaves in the way you have described is not following RFC3315. It = might be following the letter of RFC2131, but that's because RFC2131 has = a known bug in that it doesn't _require_ clients to use new information = they get from DHCP servers during lease renewals. This is not an academic distinction: I've seen all sorts of support = calls and questions about IP phones from at least one manufacturer, = because these phones do not follow the DHCP protocol specification, and = their behavior is surprising to network administrators. I didn't = realize until now that this was by design, and not just a bug in the = implementation. From Ted.Lemon@nominum.com Wed Oct 9 11:11:37 2013 Return-Path: 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 6F78F21E805F; Wed, 9 Oct 2013 11:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.602 X-Spam-Level: X-Spam-Status: No, score=-106.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 mgq-QzsJeZxX; Wed, 9 Oct 2013 11:11:30 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 27B0E21F9A71; Wed, 9 Oct 2013 11:11:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUlWcRG13RmhvmCFbOTlsOspX8LOB6ZWm@postini.com; Wed, 09 Oct 2013 11:11:17 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9E4031B82D5; Wed, 9 Oct 2013 11:11:16 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 98716190061; Wed, 9 Oct 2013 11:11:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Oct 2013 11:11:16 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <0EF36A1D-8A3E-40DB-B2A3-C8D8A5D451D8@hopcount.ca> Date: Wed, 9 Oct 2013 14:11:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <0EF36A1D-8A3E-40DB-B2A3-C8D8A5D451D8@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org" , "ietf@ietf.org" , Cullen Jennings Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 18:11:37 -0000 On Oct 9, 2013, at 1:59 PM, Joe Abley wrote: > DNSSEC validation imposes a requirement for clock sync (to the = accuracy reasonably required to consider signature inception and expiry = times). There is a possible future in which such validation takes place = on end hosts, rather than intermediate resolvers. (We may wind up = somewhere else, but there are certainly people who think that is the = Right Way). Sure. Including me. > In that sense any device that needs to look up names in the DNS has a = potential requirement for time sync. Yes, definitely. > Of course even the wall clock you imagine might have a vendor who is = capable of running their own array of time servers as (e.g.) Apple does, = but it seems reasonable to imagine that there will be people who are not = in that position, and since I agree with you when you say: >=20 >> Of course, if a CPE vendor were to hard-code the FQDN of an NTP = server belonging to someone else into their devices, that would be = disastrous. >=20 > it seems to me that there's a plausible use case for a DHCP client to = receive direction on what servers to chime against. Yup. There's an equally plausible use case for distributing DNSSEC = root keys using DHCP, so that the DHCP client has a current copy of the = keys. This totally solves the key rollover problem! :) Of course, the situations are not precisely analogous, but the point is = that just because DHCP could be conveniently used to suit some purpose, = does not mean that it _should_ be used to suit that purpose. I think = reasonable people can differ about configuring NTP over DHCP, but it = really does depend on how you are using NTP. I think the main = justification for using DHCP to configure NTP is in fact that it is = expedient, even though it's not secure. From jabley@hopcount.ca Wed Oct 9 11:00:36 2013 Return-Path: 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 97EE821E8177 for ; Wed, 9 Oct 2013 11:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 UvhhAyCEW2Pj for ; Wed, 9 Oct 2013 11:00:33 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3600921E814B for ; Wed, 9 Oct 2013 11:00:01 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp2so1282600pbb.28 for ; Wed, 09 Oct 2013 11:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ijwhYAiyrBwWKq0mQTB/5PzwTsyn0aWjUbDqdU+0tpY=; b=opHDIugjhu7LIqsaxkwqRfK97f5uB3Pr2q0yqGWJs2Z3MU6cG+KtulyBS2iOhTDJ3N qa7/aoAwxZwWZRA8uE89wPUq7eUIncuR5wyqnycKDCjG6FP4bXEMiMxmLUd70CcztqYD 5u8K/yeoLPW4W2HQteE/sZ2dp6ywQHIkb3Z0Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ijwhYAiyrBwWKq0mQTB/5PzwTsyn0aWjUbDqdU+0tpY=; b=WF4jnijxRNg38STy7jz77cSNlEdQUh/+yWla7VZCPXLEbkfKzNxt2SzvjSMLX98XpR mdk00BxodyAaXGS1LDviGPOsDFehcX4ZxCLoY5pwhSdwQcF0fZBzBBqQIkHCGx8UGVbz B1MsmU+I3BsE0InfdeIcHaEqqcsnGKkxh0lthu3pzYx6ubxxVXXUL9ls+G66f/ajgdQ/ xAbObgKugSQLAa7s1ertXnHiqCCpr9Yrk4P0kwp8yp6AN6BmxAuHPVzbT3S+vp2Xqt3t u1TEVahYI7lvSLaozZYH99jraw5xpIJaZFR30SvoHPL2/uBhLLqH7aWe3hmHJ1WXAM41 DD9g== X-Gm-Message-State: ALoCoQl+XiZv5bdPJUJWqht6BOX45aJ9TYUgfRRuk30sqQpLq2V7Pe7zTBrilq/Rdhma2+zruDnj X-Received: by 10.66.170.168 with SMTP id an8mr11079387pac.58.1381341600303; Wed, 09 Oct 2013 11:00:00 -0700 (PDT) Received: from ?IPv6:2620::ce0:104:a8af:1749:23a8:ed08? ([2620:0:ce0:104:a8af:1749:23a8:ed08]) by mx.google.com with ESMTPSA id tz3sm47980277pbc.20.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 10:59:59 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Joe Abley In-Reply-To: Date: Wed, 9 Oct 2013 10:59:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0EF36A1D-8A3E-40DB-B2A3-C8D8A5D451D8@hopcount.ca> References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Wed, 09 Oct 2013 11:16:46 -0700 Cc: "dhcwg@ietf.org" , "ietf@ietf.org" , Cullen Jennings Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 18:00:36 -0000 On 2013-10-09, at 10:53, Ted Lemon wrote: > Of course there are cases where this doesn't matter, and DHCP is just = fine, but I can't think of any other than perhaps a self-setting wall = clock. DNSSEC validation imposes a requirement for clock sync (to the accuracy = reasonably required to consider signature inception and expiry times). = There is a possible future in which such validation takes place on end = hosts, rather than intermediate resolvers. (We may wind up somewhere = else, but there are certainly people who think that is the Right Way). In that sense any device that needs to look up names in the DNS has a = potential requirement for time sync. Of course even the wall clock you imagine might have a vendor who is = capable of running their own array of time servers as (e.g.) Apple does, = but it seems reasonable to imagine that there will be people who are not = in that position, and since I agree with you when you say: > Of course, if a CPE vendor were to hard-code the FQDN of an NTP server = belonging to someone else into their devices, that would be disastrous. it seems to me that there's a plausible use case for a DHCP client to = receive direction on what servers to chime against. Joe From fluffy@iii.ca Wed Oct 9 15:02:58 2013 Return-Path: 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 1FCA621E825E; Wed, 9 Oct 2013 15:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] 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 qWoiTpzCeuB2; Wed, 9 Oct 2013 15:02:53 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8F521E8238; Wed, 9 Oct 2013 15:02:47 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F2578509B5; Wed, 9 Oct 2013 18:02:45 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: Date: Wed, 9 Oct 2013 16:02:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Wed, 09 Oct 2013 15:30:51 -0700 Cc: "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 22:02:58 -0000 On Oct 9, 2013, at 11:53 AM, Ted Lemon wrote: > On Oct 9, 2013, at 1:32 PM, Cullen Jennings wrote: >> Well DNS and Router obviously won't work with FQDN so lets talk about = NTP for a minute. (and sorry, I don't even know what AFTR IP is). I = design lots of devices that have to be plugged into a network and just = start working with no user interaction. Getting the correct time is = often really useful to have - particularly with synchronization = protocols.=20 >=20 > An AFTR IP address is like a router IP address, but for a particular = IPv4 transition technology. Other transition technologies of this sort = are classic examples of services that make sense to configure with DHCP, = because they are part of the network infrastructure. >=20 >> One approach would be to hard code that NTP server name in the the = product. That is not my preferred approach because stuff goes wrong and = you end up with things like = http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse . >=20 > Apple hard-codes the FQDN of a set of NTP servers they control into = all their products. I think other OS vendors do as well, but am not = clear on the details. The advantage of doing this is that you can then = authenticate your communication with the NTP server. If you use DHCP = to configure your NTP server, you cannot validate your communication = with your NTP server. Of course there's a bit of a chicken-and-egg = problem here in terms of replay attacks and key repudiation, but in = principle you get more security if you hard code the FQDN of your NTP = server than if you use DHCP to configure it. Hard coding it means you can't make your device work if you are on a = network that behind a firewall that does not allow the traffic or is on = a networks that is not part of the internet or is being set up for use = in emergency communications where the the device is on a network say in = Hati that has become partitioned from rest of network after an disaster. = Obviously one can fallback to a hard coded option if no DHCP option is = found but it's pretty important to have a chance of being able to = configure things to work on networks with less than ideal connectivity.=20= >=20 > Of course there are cases where this doesn't matter, and DHCP is just = fine, but I can't think of any other than perhaps a self-setting wall = clock. >=20 > Of course, if a CPE vendor were to hard-code the FQDN of an NTP server = belonging to someone else into their devices, that would be disastrous. >=20 >> Another approach is for DHCP to provide the NTP server info. I would = argue that getting a FQDN of the NTP server pool is a better design for = DHCP than getting an IP address because this allow DNS load balancing = across the pool and allows the server IP to change over time and still = not have client failures.=20 >=20 > You'd get the same effect if the DHCP server did the lookup. I agree = that if you want to suddenly add an NTP server and need it to be adopted = in a time frame shorter than your typical lease time, and your DNS TTL = is shorter than your typical lease time, you will get better service = using DNS, but there's no clear win here=97this would be a pretty weird = requirement. I think this is the part where we disagree. I don't think you get the = same effect if the DHCP server did the lookup and returned a single IP = address. I realize you understand DNS better than me but DNS returns a = lot more than a single IP address. In the most simple case it can be = returning a list of IP so that if one server is down, the client can = contact another. I don't see how to do that with single IP returned from = DHCP. (yes, I realize that some people have requested DHCP options to = return a list of IP). But more impotently if someone wants to do = something like move the server from one data center to another, it is = well understood by admins how to do that when clients access the server = by FQDN. It's much harder when it's an IP address that has to be updated = in DHCP servers. Not to mention opening up the use DNS tools like SRV = and NAPTR.=20 >=20 >> You agree that FQDN is would be a better design than IP for NTP ? >=20 > No. I think the boxes that need NTP configuration via DHCP are most = likely constrained devices, and that requiring them to do a DNS lookup = in addition to the DHCP transaction is unnecessary. This is not really a constrained device issue - it has to do with hosts = that don't have an IT administrator and need to just work. They might be = constrained, but right now my house has devices doing DHCP, DNS, and = HTTP all fitting in 12 k of flash, 512 bytes of ram, and an 8 bit = processor at 16Mhz so don't think that DNS needs to be big - probably = not fully standards compliant but it works. My house also has things = like NAS, WiFI GW, TVs etc that have pretty powerful computers yet still = need to turn on and just work with no administration.=20 > Probably not a hugely bad thing, but that depends on the device. A = device with severe constraints probably isn't using DHCP anyway. Seriously ? How do you think IPv4 constrained devices get an IP address? >=20 >> Agree - it does not change as phones move network to network. It is = uses DHCP the first time the phone is plugged in. The whole design is = around making sure the phone can go from the manufacture to the end user = without ever being removed from the box or powered up be an admin. The = admin configures the call control system based on knowledge about the = phone and which user the phone is going to but the admin does not need = to touch the phone. When the phone first boots it imprint baby duck = style on a network to get the configuration information which is = encrypted with that phones public key. After that the phone use that = configuration information not the DHCP (unless the phone is factory = reset). It's actually a lot more complicated than that because security = relies on replacement of manufacture certificates with the service = provider certificates to make sure a comprise of the manufactures CA = only results in service provider not being able to enroll new phones but = does not compromise security of operational phone network.=20 >=20 >>=20 >> However, the first time the phone boots, DHCP needs to let the phone = know who the likely service provider might be. If the phone gets the = wrong DHCP information from an attacker or wrong network, the phone = fails to configure but does not suffer MITM attacks. Using DHCP for = phones has been used by pretty much every IP phone manufactures and most = enterprise deployments and many residential providers including folks = ranging from vonage to AT&T take advantage of it. DHCP greatly reduce = the deployment costs of setting up VoIP networks.=20 >>=20 >> We had a lot of learning from the phone deployments and I expect us = to use what we learned there for how we do IoT. (I presented a paper on = this at the IAB workshop on IoT). One of the things we learned the hard = way was names work better than numbers.=20 >=20 >=20 > So what you've done here is to invent a service configuration protocol = that leverages existing DHCP server infrastructure, uses packets that = look just like DHCP packets, but is not actually DHCP. A client that = behaves in the way you have described is not following RFC3315. It = might be following the letter of RFC2131, but that's because RFC2131 has = a known bug in that it doesn't _require_ clients to use new information = they get from DHCP servers during lease renewals. >=20 > This is not an academic distinction: I've seen all sorts of support = calls and questions about IP phones from at least one manufacturer, = because these phones do not follow the DHCP protocol specification, and = their behavior is surprising to network administrators. I didn't = realize until now that this was by design, and not just a bug in the = implementation. >=20 Hmm - this is much more interesting - help me understand what part it = does not follow 3315. When it boots, it uses DHCP to find the address of = a configuration server. If it needs a configuration, it downloads that = from the configuration server. If it does not need a configuration, it = does not download it. I would not be shocked to find out that this was = not following 3315 but I think I can speak for at least most the folks = doing this that they did not know it was not consistent with 3315 and = would be very interested in hearing why.=20 From jiangsheng@huawei.com Wed Oct 9 18:07:13 2013 Return-Path: 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 95BF321E823A for ; Wed, 9 Oct 2013 18:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TmyIlKefjuCw for ; Wed, 9 Oct 2013 18:07:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 38DEA21E81B2 for ; Wed, 9 Oct 2013 18:07:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYX66288; Thu, 10 Oct 2013 01:07:05 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 02:06:28 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 02:07:01 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Thu, 10 Oct 2013 09:06:56 +0800 From: Sheng Jiang To: "" Thread-Topic: New Version Notification for draft-jiang-dhc-sedhcpv6-01.txt Thread-Index: AQHOw/oxN5loSW/dEkauJe4nbHCE75ntHsBw Date: Thu, 10 Oct 2013 01:06:55 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD46C61@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [dhcwg] FW: New Version Notification for draft-jiang-dhc-sedhcpv6-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 01:07:13 -0000 SGksIERIQ2VycywNCg0KV2UgaGF2ZSBqdXN0IHN1Ym1pdHRlZCBhbiB1cGRhdGUgdmVyc2lvbiwg d2hpY2ggYWRkcmVzcyBtb3N0IG9mIGNvbW1lbnRzIHJhaXNlZCBieSBzZXZlcmFsIHJldmlld2Vy cy4gQ291bGQgeW91IHBsZWFzZSByZXZpZXcgdGhpcyBuZXcgdmVyc2lvbj8NCg0KRllJLCB0aGlz IGRyYWZ0IGlzIGEgcmVwbGFjZW1lbnQgb2YgZHJhZnQtaWV0Zi1kaGMtc2VjdXJlLWRoY3B2Niwg d2hpY2ggcmVhY2hlZCBJRVNHIGFuZCBkZWFkIGJlY2F1c2Ugb2YgY29uc2lkZXJhdGlvbiByZWdh cmRpbmcgdG8gQ0dBLiBUaGUgYXV0aG9ycyBmb2xsb3dlZCB0aGUgc3VnZ2VzdGlvbiBmcm9tIElF U0cgbWFraW5nIGEgZ2VuZXJhbCBwdWJsaWMga2V5IGJhc2VkIG1lY2hhbmlzbS4NCg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctZGhjLXNlZGhjcHY2LTAxDQoNCk1hbnkg dGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10NCj5TZW50OiBUdWVzZGF5LCBPY3RvYmVyIDA4LCAyMDEzIDM6NDQg UE0NCj5UbzogU2hlbmcgSmlhbmc7IFNlYW4gU2hlbg0KPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtamlhbmctZGhjLXNlZGhjcHY2LTAxLnR4dA0KPg0KPg0KPkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qaWFuZy1kaGMtc2VkaGNwdjYtMDEudHh0DQo+aGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTaGVuZyBKaWFuZyBhbmQgcG9zdGVkIHRv IHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5GaWxlbmFtZToJIGRyYWZ0LWppYW5nLWRoYy1z ZWRoY3B2Ng0KPlJldmlzaW9uOgkgMDENCj5UaXRsZToJCSBTZWN1cmUgREhDUHY2IHdpdGggUHVi bGljIEtleQ0KPkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTA4DQo+R3JvdXA6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+TnVtYmVyIG9mIHBhZ2VzOiAxNg0KPlVSTDoNCj5odHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qaWFuZy1kaGMtc2VkaGNwdjYtMDEudHh0DQo+ U3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpp YW5nLWRoYy1zZWRoY3B2Ng0KPkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtamlhbmctZGhjLXNlZGhjcHY2LTAxDQo+RGlmZjoNCj5odHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qaWFuZy1kaGMtc2VkaGNwdjYtMDENCj4NCj5BYnN0 cmFjdDoNCj4gICBUaGUgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgZm9yIElQ djYgKERIQ1B2NikgZW5hYmxlcw0KPiAgIERIQ1B2NiBzZXJ2ZXJzIHRvIHBhc3MgY29uZmlndXJh dGlvbiBwYXJhbWV0ZXJzLiAgSXQgb2ZmZXJzDQo+ICAgY29uZmlndXJhdGlvbiBmbGV4aWJpbGl0 eS4gIElmIG5vdCBzZWN1cmVkLCBESENQdjYgaXMgdnVsbmVyYWJsZSB0bw0KPiAgIHZhcmlvdXMg YXR0YWNrcywgcGFydGljdWxhcmx5IHNwb29maW5nIGF0dGFja3MuICBUaGlzIGRvY3VtZW50DQo+ ICAgYW5hbHl6ZXMgdGhlIHNlY3VyaXR5IGlzc3VlcyBvZiBESENQdjYgYW5kIHNwZWNpZmllcyBh IFNlY3VyZSBESENQdjYNCj4gICBtZWNoYW5pc20uICBUaGlzIG1lY2hhbmlzbSBpcyBiYXNlZCBv biBwdWJsaWMvcHJpdmF0ZSBrZXkgcGFpcnMuICBUaGUNCj4gICBhdXRob3JpdHkgb2YgdGhlIHNl bmRlciBtYXkgZGVwZW5kIG9uIGVpdGhlciBwcmUtY29uZmlndXJhdGlvbg0KPiAgIG1lY2hhbmlz bSBvciBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlLg0KPg0KPg0KPg0KPg0KPlBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From Ted.Lemon@nominum.com Wed Oct 9 18:15:55 2013 Return-Path: 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 1699E21E824F; Wed, 9 Oct 2013 18:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.602 X-Spam-Level: X-Spam-Status: No, score=-106.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 jg3tMYMjWrJQ; Wed, 9 Oct 2013 18:15:48 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5D35A21E823A; Wed, 9 Oct 2013 18:15:48 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUlX/xBtXI/wm2K6DTGIBUkA2Uwev7krT@postini.com; Wed, 09 Oct 2013 18:15:48 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C252D1B82CE; Wed, 9 Oct 2013 18:15:47 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 89C9119005C; Wed, 9 Oct 2013 18:15:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Oct 2013 18:15:46 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> Date: Wed, 9 Oct 2013 21:15:44 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 01:15:55 -0000 On Oct 9, 2013, at 6:02 PM, Cullen Jennings wrote: > Hard coding it means you can't make your device work if you are on a = network that behind a firewall that does not allow the traffic or is on = a networks that is not part of the internet or is being set up for use = in emergency communications where the the device is on a network say in = Hati that has become partitioned from rest of network after an disaster. = Obviously one can fallback to a hard coded option if no DHCP option is = found but it's pretty important to have a chance of being able to = configure things to work on networks with less than ideal connectivity.=20= If this argument were correct, we'd expect to see major O.S. vendors = supporting the NTP option, but we don't=97instead, it's something that = can be configured in the UI for situations like the one you describe, = and that otherwise is defaulted to the preconfigured value, which of = course can be updated when the operating system is updated. So where I would expect to see the NTP option used is in devices that = don't _have_ user interfaces. Your IP phone might be such a device. = I suspect the bias you have toward using a DHCP option has a lot to do = with where these devices are typically installed: in corporate = environments. I don't even know if I could get one to use at home, or = if it would work. So in this environment, it certainly makes sense to = use a DHCP option to do NTP service, as long as you are doing something = to validate the NTP server so that you can't be trivially attacked by = being fed false time information. A hardware RTC would help to sanity = check the result received from the DHCP-provided NTP server, for = example. >>> Another approach is for DHCP to provide the NTP server info. I would = argue that getting a FQDN of the NTP server pool is a better design for = DHCP than getting an IP address because this allow DNS load balancing = across the pool and allows the server IP to change over time and still = not have client failures.=20 >>=20 >> You'd get the same effect if the DHCP server did the lookup. I = agree that if you want to suddenly add an NTP server and need it to be = adopted in a time frame shorter than your typical lease time, and your = DNS TTL is shorter than your typical lease time, you will get better = service using DNS, but there's no clear win here=97this would be a = pretty weird requirement. >=20 > I think this is the part where we disagree. I don't think you get the = same effect if the DHCP server did the lookup and returned a single IP = address. I realize you understand DNS better than me but DNS returns a = lot more than a single IP address. In the most simple case it can be = returning a list of IP so that if one server is down, the client can = contact another. I don't see how to do that with single IP returned from = DHCP. (yes, I realize that some people have requested DHCP options to = return a list of IP). There's nothing to disagree about. This is in fact how it works with = most DHCP servers today: you do a DHCP transaction, the DHCP server = looks up the name in the DNS, stuffs whatever it gets back into the DHCP = option (hence the advice in the option guidelines draft to allow more = than one IP address in cases where it makes sense), and merrily sends it = to the DHCP client, which, if it only wanted one address, likely picks = the first, just as it would have done had it done the DNS lookup itself. It's true that it doesn't behave exactly the same as if the device = repeatedly queries the same name it got from the DHCP server, rather = than repeatedly using the list of IP addresses it got from the DHCP = server. > But more impotently if someone wants to do something like move the = server from one data center to another, it is well understood by admins = how to do that when clients access the server by FQDN. It's much harder = when it's an IP address that has to be updated in DHCP servers. This is a really brittle use case, even if you are using DNS. Whatever = TTL you are using, you will see outages for that duration. I can't = think of a single case where a service you'd sensibly configure with = DHCP would be moved this way, because servers of this type are typically = either related to network infrastructure, or are replicable. So you = don't just pick up your DNS cache and move it to a different data = center, not even if it's on an SDN. Instead, you launch a new DNS = cache in the new data center, and leave the old DNS cache running until = the DNS TTLs or DHCP leases have had time to expire. In either case, = you get the same behavior and the same outcome. > Not to mention opening up the use DNS tools like SRV and NAPTR.=20 Right, and SRV isn't something you'd use for a service that it makes = sense to configure using DHCP. Nor is NAPTR. I would argue that if = it makes any sense at all for there to be a SRV record, that's a strong = argument against using DHCP to configure that service. But yes, if you = can find an edge case where it does make sense to use DHCP, and a SRV = record would work and would be useful, then that option should deliver = an FQDN, not an IP address. >=20 >>=20 >>> You agree that FQDN is would be a better design than IP for NTP ? >>=20 >> No. I think the boxes that need NTP configuration via DHCP are most = likely constrained devices, and that requiring them to do a DNS lookup = in addition to the DHCP transaction is unnecessary. >=20 > This is not really a constrained device issue - it has to do with = hosts that don't have an IT administrator and need to just work. They = might be constrained, but right now my house has devices doing DHCP, = DNS, and HTTP all fitting in 12 k of flash, 512 bytes of ram, and an 8 = bit processor at 16Mhz so don't think that DNS needs to be big - = probably not fully standards compliant but it works. My house also has = things like NAS, WiFI GW, TVs etc that have pretty powerful computers = yet still need to turn on and just work with no administration.=20 Right, and at the moment they almost certainly have their NTP server = FQDNs hard-coded, and it works, and you don't even know it's working = this way, because it's a solid solution in a home network. The issue = with DNS on constrained devices is that it's another packet round trip, = and packets burn battery. And there are constrained devices where = adding another network protocol means less space for what the device = needs to be doing. But I tend to agree that if you can afford to put a = DHCP client in a device, there's probably room for a DNS resolver as = well. >> Probably not a hugely bad thing, but that depends on the device. A = device with severe constraints probably isn't using DHCP anyway. >=20 > Seriously ? How do you think IPv4 constrained devices get an IP = address? When I say "constrained device," I really mean 6lowpan device. = Remember that this document is specifically about DHCPv6. > Hmm - this is much more interesting - help me understand what part it = does not follow 3315. When it boots, it uses DHCP to find the address of = a configuration server. If it needs a configuration, it downloads that = from the configuration server. If it does not need a configuration, it = does not download it. I would not be shocked to find out that this was = not following 3315 but I think I can speak for at least most the folks = doing this that they did not know it was not consistent with 3315 and = would be very interested in hearing why.=20 If you are using DHCP to provide the location of a configuration server, = and you make a leap of faith with that server on first configuration, = and never talk to it again, then you probably are in compliance with = RFC3315. If you take the value of a DHCP option and retain it forever, = and do not take note of the fact that it has changed, then you are out = of spec. I was under the impression from reading your explanation that = you were doing the latter.= From fluffy@iii.ca Wed Oct 9 20:49:24 2013 Return-Path: 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 10D1221F9E9D; Wed, 9 Oct 2013 20:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] 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 DaxZTbOAqf4y; Wed, 9 Oct 2013 20:49:19 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B7A5621E823D; Wed, 9 Oct 2013 20:49:18 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2A55822E1F3; Wed, 9 Oct 2013 23:49:11 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> Date: Wed, 9 Oct 2013 21:49:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Wed, 09 Oct 2013 21:50:10 -0700 Cc: "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 03:49:24 -0000 Ted, I'm trying hard to get my head around the argument you are making = and obviously I am coming to the problem from a narrow point of view = from the VoIP domain and I realize the WG has dealt with DHCP solutions = for a wide range of solutions - but so far I'm not very convinced by = this power + extra RTT when the device boots outweighs the opertational = simplicity concerns of using names. I just can't think of a application = or device where that extra DNS query at boot accounted for more than = 0.1% of the power usage of the device. I've also received a couple = private emails that I would more or less summarize as the DHCP WG is = impossible on this topic, you will never convince them, just ignore the = spec, it's not a MUST so just don't worry and do whatever you need to = do. I really don't want to do that - if using FQDN really is the wrong = choice, it sure would be nice if this draft offered a compelling = argument of that. Few more comments inline=85. =20 On Oct 9, 2013, at 7:15 PM, Ted Lemon wrote: > On Oct 9, 2013, at 6:02 PM, Cullen Jennings wrote: >> Hard coding it means you can't make your device work if you are on a = network that behind a firewall that does not allow the traffic or is on = a networks that is not part of the internet or is being set up for use = in emergency communications where the the device is on a network say in = Hati that has become partitioned from rest of network after an disaster. = Obviously one can fallback to a hard coded option if no DHCP option is = found but it's pretty important to have a chance of being able to = configure things to work on networks with less than ideal connectivity.=20= >=20 > If this argument were correct, we'd expect to see major O.S. vendors = supporting the NTP option, but we don't=97instead, it's something that = can be configured in the UI for situations like the one you describe, = and that otherwise is defaulted to the preconfigured value, which of = course can be updated when the operating system is updated. Right - I am certainly more focused on the devices that don't have an = administrator that can configure them locally.=20 >=20 > So where I would expect to see the NTP option used is in devices that = don't _have_ user interfaces. Your IP phone might be such a device. = I suspect the bias you have toward using a DHCP option has a lot to do = with where these devices are typically installed: in corporate = environments. Agree I am focused on the VoIP stuff but it is both SP and enterprises.=20= > I don't even know if I could get one to use at home, or if it would = work. They work in residential deployments (which might be a bit different = than you mean by home) and DHCP can provide some very critical services = for them. For example rfc5223 is a DHCP options that provides the LOST = server that provides the mapping to locations that can be used for E911 = calls and is applicable to residential.=20 > So in this environment, it certainly makes sense to use a DHCP = option to do NTP service, as long as you are doing something to validate = the NTP server so that you can't be trivially attacked by being fed = false time information. A hardware RTC would help to sanity check the = result received from the DHCP-provided NTP server, for example. >=20 >>>> Another approach is for DHCP to provide the NTP server info. I = would argue that getting a FQDN of the NTP server pool is a better = design for DHCP than getting an IP address because this allow DNS load = balancing across the pool and allows the server IP to change over time = and still not have client failures.=20 >>>=20 >>> You'd get the same effect if the DHCP server did the lookup. I = agree that if you want to suddenly add an NTP server and need it to be = adopted in a time frame shorter than your typical lease time, and your = DNS TTL is shorter than your typical lease time, you will get better = service using DNS, but there's no clear win here=97this would be a = pretty weird requirement. >>=20 >> I think this is the part where we disagree. I don't think you get = the same effect if the DHCP server did the lookup and returned a single = IP address. I realize you understand DNS better than me but DNS returns = a lot more than a single IP address. In the most simple case it can be = returning a list of IP so that if one server is down, the client can = contact another. I don't see how to do that with single IP returned from = DHCP. (yes, I realize that some people have requested DHCP options to = return a list of IP). >=20 > There's nothing to disagree about. Sure I believe you about what DHCP servers are capable of doing (which I = will note might be different than how they are commonly deployed). I was = talking about the issue here of from a protocol design point of view, = one should prefer the use of an IP address or FQDN in the DHCP option = for a case like this.=20 > This is in fact how it works with most DHCP servers today: you do a = DHCP transaction, the DHCP server looks up the name in the DNS, stuffs = whatever it gets back into the DHCP option (hence the advice in the = option guidelines draft to allow more than one IP address in cases where = it makes sense), and merrily sends it to the DHCP client, which, if it = only wanted one address, likely picks the first, just as it would have = done had it done the DNS lookup itself. >=20 > It's true that it doesn't behave exactly the same as if the device = repeatedly queries the same name it got from the DHCP server, rather = than repeatedly using the list of IP addresses it got from the DHCP = server. >=20 >> But more impotently if someone wants to do something like move the = server from one data center to another, it is well understood by admins = how to do that when clients access the server by FQDN. It's much harder = when it's an IP address that has to be updated in DHCP servers. >=20 > This is a really brittle use case, even if you are using DNS. = Whatever TTL you are using, you will see outages for that duration. I = can't think of a single case where a service you'd sensibly configure = with DHCP would be moved this way, because servers of this type are = typically either related to network infrastructure, or are replicable. = So you don't just pick up your DNS cache and move it to a different data = center, not even if it's on an SDN. Instead, you launch a new DNS = cache in the new data center, and leave the old DNS cache running until = the DNS TTLs or DHCP leases have had time to expire. In either case, = you get the same behavior and the same outcome. When I said "move" I'm talking the roughly the same thing as you mean = here of bring up a new service. So lets take a VoIP provider like AT&T = or a large enterprise like GE. Let say that have a server called = time.ge.com in DNS. Figuring out the TTL for that is pretty easy. = Changing it to reduce down around the time of the move is pretty easy as = you can chance it one place and DNS sync it to the other DNS servers. = Now lets consider doing the same thing with DHCP. How many DHCP server = do you think either of theses have? Consistent tools to manage all them = from a central location? The admin know when they are moving servers = they need to deal with the DNS - but do they all even remember to update = the DHCP? The we have the issue of NATs that act as DHCP clients, get an option, = then re-advertise that option as a DHCP server on the private side. I = realize that if they advertise it for longer on the private side than = the lease was valid on the public side is just really broken, but none = the less I'm sure no one will be shocked to find out there are broken = NATs.=20 I've been involved with deployments bitten by every one of of the above. = That make me prefer FQDN unless it is a case where DNS might not be = supported or not operational, or a case where the time / power of the = DNS query makes a significant difference to the system.=20 >=20 >> Not to mention opening up the use DNS tools like SRV and NAPTR.=20 >=20 > Right, and SRV isn't something you'd use for a service that it makes = sense to configure using DHCP. Nor is NAPTR. I thought about what you wrote here for a long time. I suspect that is = part of the issue is that people such as myself that are not DHCP = experts don't know what services are not appropriate to use it for. We = see it as a hammer and we are off pounding nails, or screws. I view SRV = as an OK way to control load balancing across a set of servers that have = different capacity - often due to be deployed on faster computers over = time. Why would a service with that property not be someone one would = use DHCP for.=20 =20 > I would argue that if it makes any sense at all for there to be a = SRV record, that's a strong argument against using DHCP to configure = that service. =20 tell me more - this one I did not get.=20 > But yes, if you can find an edge case where it does make sense to use = DHCP, and a SRV record would work and would be useful, then that option = should deliver an FQDN, not an IP address. >=20 >>=20 >>>=20 >>>> You agree that FQDN is would be a better design than IP for NTP ? >>>=20 >>> No. I think the boxes that need NTP configuration via DHCP are = most likely constrained devices, and that requiring them to do a DNS = lookup in addition to the DHCP transaction is unnecessary. >>=20 >> This is not really a constrained device issue - it has to do with = hosts that don't have an IT administrator and need to just work. They = might be constrained, but right now my house has devices doing DHCP, = DNS, and HTTP all fitting in 12 k of flash, 512 bytes of ram, and an 8 = bit processor at 16Mhz so don't think that DNS needs to be big - = probably not fully standards compliant but it works. My house also has = things like NAS, WiFI GW, TVs etc that have pretty powerful computers = yet still need to turn on and just work with no administration.=20 >=20 > Right, and at the moment they almost certainly have their NTP server = FQDNs hard-coded, and it works, and you don't even know it's working = this way, because it's a solid solution in a home network. The issue = with DNS on constrained devices is that it's another packet round trip, = and packets burn battery. =20 Give me an example where that makes a difference. When I look at this as = the power to do a DNS query amortized over the lifetime of the lease or = uptime of the device I'm just having a hard time thinking of the right = example to motivate this.=20 > And there are constrained devices where adding another network = protocol means less space for what the device needs to be doing. But I = tend to agree that if you can afford to put a DHCP client in a device, = there's probably room for a DNS resolver as well. Space always seems to be an issue on embedded device so I sort of buy = that for that very narrow case but this draft is about v6 in general.=20 >=20 >>> Probably not a hugely bad thing, but that depends on the device. A = device with severe constraints probably isn't using DHCP anyway. >>=20 >> Seriously ? How do you think IPv4 constrained devices get an IP = address? >=20 > When I say "constrained device," I really mean 6lowpan device. = Remember that this document is specifically about DHCPv6. Given 6lowpan is a subset of even just the wireless devices and does not = include the wired devices, I had a much broader view of the word = "constrained" device but point well taken that this is the DHCPv6. I had = sort of assume the same arguments would apply about the IP vs FQDN for = v4 options.=20 >=20 >> Hmm - this is much more interesting - help me understand what part it = does not follow 3315. When it boots, it uses DHCP to find the address of = a configuration server. If it needs a configuration, it downloads that = from the configuration server. If it does not need a configuration, it = does not download it. I would not be shocked to find out that this was = not following 3315 but I think I can speak for at least most the folks = doing this that they did not know it was not consistent with 3315 and = would be very interested in hearing why.=20 >=20 > If you are using DHCP to provide the location of a configuration = server, and you make a leap of faith with that server on first = configuration, and never talk to it again, then you probably are in = compliance with RFC3315. If you take the value of a DHCP option and = retain it forever, and do not take note of the fact that it has changed, = then you are out of spec. I was under the impression from reading your = explanation that you were doing the latter. Sorry for my overly brief description leading to confusion.=20 From jiangsheng@huawei.com Thu Oct 10 02:03:27 2013 Return-Path: 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 A16DD11E8136 for ; Thu, 10 Oct 2013 02:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 TMb0VnRF+q+Q for ; Thu, 10 Oct 2013 02:03:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6EA11E812B for ; Thu, 10 Oct 2013 02:03:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWR09193; Thu, 10 Oct 2013 09:03:20 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 10:02:29 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 10:02:54 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0146.000; Thu, 10 Oct 2013 17:02:47 +0800 From: Sheng Jiang To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: Call for Agenda Items for IETF-88 (Vancouver) Thread-Index: Ac7CyRRj2lhQNkosRiKfaagKYriJPwCzcWAA Date: Thu, 10 Oct 2013 09:02:45 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD46EAF@nkgeml512-mbx.china.huawei.com> References: <489D13FBFA9B3E41812EA89F188F018E1ACF6595@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ACF6595@xmb-rcd-x04.cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AD46EAFnkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] Call for Agenda Items for IETF-88 (Vancouver) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 09:03:27 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AD46EAFnkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJZiB5b3Ugd291bGQgbGlrZSB0aW1lLCBwbGVhc2UgaW5kaWNhdGU6DQoNCj4gLSAgICAgICAg ICBEcmFmdCBuYW1lIG9yIHRvcGljDQoNCj4gLSAgICAgICAgICBXaG8gd2lsbCBwcmVzZW50DQoN Cj4gLSAgICAgICAgICBIb3cgbXVjaCB0aW1lIGlzIG5lZWRlZA0KDQo+DQoNCj4gLSAgICAgICAg ICBXaHkgaXMgdGltZSBuZWVkZWQgKHRlbGwgdXMgd2h5IHlvdSBjYW7igJl0IGdldCB3aGF0IHlv dSBuZWVkDQoNCj4gYnkgcG9zdGluZyBvbiB0aGUgbWFpbGluZyBsaXN0KSBhbmQgd2hhdCB3aWxs IGJlIGNvdmVyZWQNCg0KDQoNCkknZCBsaWtlIHRvIHJlcXVlc3QgYSAxNSBtaW51dGVzIHNsb3Qg Zm9yIHJlY29uZmlndXJhdGlvbiBpbiBzdGF0ZWxlc3MgREhDUHY2IHdvcmssIGFzIFVSSSBiZWxv dy4gSSB3aWxsIGJlIHRoZSBwcmVzZW50ZXIuIFRoaXMgdGltZSBpcyBuZWVkZWQsIGJlY2F1c2Ug dGhpcyBpcyBhbiB1bi1zdXBwb3J0IGlzc3VlIGluIGN1cnJlbnQgc3RhdGVsZXNzIERIQ1B2Ni4g SXQgaXMgZGVmaW5pdGVseSBpbiB0aGUgc2NvcGUgb2YgREhDIFdHLg0KDQoNCg0KaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamlhbmctZGhjLXN0YXRlbGVzcy1yZWNv bmZpZ3VyYXRpb24tMDAudHh0DQoNCg0KDQpUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIGdldCBy ZXZpZXdzIGJ5IHRoZSBXRywgcGFydGljdWxhcmx5IG9uIHdoZXRoZXIgdGhpcyBwcm9ibGVtIGFy ZSB2YWxpZC4gV2UgYXJlIGFsc28gb3BlbiBmb3IgZGlzY3Vzc2lvbiByZWdhcmRpbmcgdG8gc29s dXRpb24gZGVzaWduLiBTZXZlcmFsIGRlc2lnbiBxdWVzdGlvbnMgYXJlIGxpc3RlZCBpbiB0aGUg ZG9jdW1lbnQgZm9yIFdHIHRvIGRlY2lkZS4NCg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KDQoNClNo ZW5nICsgQmluZw0KDQpGcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ct Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlcm5pZSBWb2x6ICh2b2x6KQ0KU2VudDog TW9uZGF5LCBPY3RvYmVyIDA3LCAyMDEzIDM6MjUgQU0NClRvOiBkaGN3Z0BpZXRmLm9yZw0KU3Vi amVjdDogW2RoY3dnXSBDYWxsIGZvciBBZ2VuZGEgSXRlbXMgZm9yIElFVEYtODggKFZhbmNvdXZl cikNCkltcG9ydGFuY2U6IEhpZ2gNCg0KSGk6DQoNClRoZSBWYW5jb3V2ZXIgSUVURiBpcyBub3Qg dGhhdCBmYXIgb2ZmIChOb3YgMy04KS4gU2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy84 OC9pbmRleC5odG1sIGZvciBtb3JlIGRldGFpbHMsIGluY2x1ZGluZyB2ZW51ZSBpbmZvcm1hdGlv biBhbmQgaW1wb3J0YW50IGRhdGVzLg0KDQpUaGUgcHJlbGltaW5hcnkgYWdlbmRhIGhhcyB0aGUg REhDIFdHIGlzIHNjaGVkdWxlZCBmb3IgVFVFU0RBWSwgTm92ZW1iZXIgNSBmcm9tIDA5MDAtMTEz MCBQU1QuDQoNClBsZWFzZSBhbHNvIG5vdGU6DQoNCiAgKiAgIDIwMTMtMTAtMDcgKE1vbmRheSk6 IFdvcmtpbmcgR3JvdXAgQ2hhaXIgYXBwcm92YWwgZm9yIGluaXRpYWwgZG9jdW1lbnQgKFZlcnNp b24gLTAwKSBzdWJtaXNzaW9ucyBhcHByZWNpYXRlZCBieSBVVEMgMjQ6MDAuDQogICogICAyMDEz LTEwLTExIChGcmlkYXkpOiBGaW5hbCBhZ2VuZGEgdG8gYmUgcHVibGlzaGVkLg0KICAqICAgMjAx My0xMC0yMSAoTW9uZGF5KTogSW50ZXJuZXQgRHJhZnQgc3VibWlzc2lvbiBjdXQtb2ZmIChmb3Ig YWxsIGRyYWZ0cywgaW5jbHVkaW5nIC0wMCkgYnkgVVRDIDI0OjAwLCB1cGxvYWQgdXNpbmcgSUVU RiBJRCBTdWJtaXNzaW9uIFRvb2w8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9zdWJtaXQv Pi4NCldlIGFyZSBzdGFydGluZyB0aGUgY2FsbCBmb3IgYWdlbmRhIGl0ZW1zLiBUaGUgY28tY2hh aXJzIHdpbGwgZmluYWxpemUgdGhlIGFnZW5kYSBhYm91dCB0d28gd2Vla3MgYmVmb3JlIHRoZSBt ZWV0aW5nIGFuZCB3aWxsIGdpdmUgcHJpb3JpdHkgdG8gaXRlbXMgYXMgZm9sbG93cyAoaW4gdGhp cyBvcmRlcik6DQoNCg0KMS4gICAgICBXRyBkb2N1bWVudHMgd2l0aCBhY3RpdmUgd29ya2luZyBn cm91cCBkaXNjdXNzaW9uIG9yIHRoYXQgYXJlIGRlZW1lZCBjcml0aWNhbCAoaS5lLiwgaGF2ZSB1 cGNvbWluZyBtaWxlc3RvbmVzKQ0KDQoyLiAgICAgIFdHIGRvY3VtZW50cyB3aXRoIGxpdHRsZSBv ciBubyBkaXNjdXNzaW9uIChwcm92aWRlZCB0aGVyZSBpcyBhIHN0cm9uZyByZWFzb24gZm9yIHRo ZSBkaXNjdXNzaW9uIOKApiBpLmUuLCBhIGhpZ2hlciBiYW5kd2lkdGggZGlzY3Vzc2lvbiBpcyBu ZWVkZWQpDQoNCjMuICAgICAgTm9uIFdHIGRvY3VtZW50cyB3aXRoIGFjdGl2ZSB3b3JraW5nIGdy b3VwIGRpc2N1c3Npb24NCg0KNC4gICAgICBOb24gV0cgZG9jdW1lbnRzIHdpdGggbGl0dGxlIG9y IG5vIGRpc2N1c3Npb24NCg0KV2Ugd2lsbCBsaW1pdCB0aGUgbnVtYmVyIG9mIHByZXNlbnRhdGlv bnMgdG8gcmVkdWNlIHRoZSBjaGFuY2UgdGhhdCB3ZSBkb27igJl0IGdldCB0byB0aGVtIGFsbC4N Cg0KUGxlYXNlIGJlIHN1cmUgdG8gZm9jdXMgeW91ciBwcmVzZW50YXRpb25zIG9uIGlzc3VlcyB0 aGF0IG5lZWQgZGlzY3Vzc2lvbiBvciBpbnB1dCAobmV3IHdvcmsgY2FuIGluY2x1ZGUgYW4gb3Zl cnZpZXcsIGJ1dCB0aGUgZm9jdXMgc2hvdWxkIGJlIG9uIGlzc3VlcyBuZWVkaW5nIHJlc29sdXRp b24pLiBTdGF0dXMgdXBkYXRlcyBjYW4gYmUgc2VudCB0byB0aGUgbWFpbGluZyBsaXN0Lg0KDQpJ ZiB5b3Ugd291bGQgbGlrZSB0aW1lLCBwbGVhc2UgaW5kaWNhdGU6DQoNCi0gICAgICAgIERyYWZ0 IG5hbWUgb3IgdG9waWMNCg0KLSAgICAgICAgV2hvIHdpbGwgcHJlc2VudA0KDQotICAgICAgICBI b3cgbXVjaCB0aW1lIGlzIG5lZWRlZA0KDQotICAgICAgICBXaHkgaXMgdGltZSBuZWVkZWQgKHRl bGwgdXMgd2h5IHlvdSBjYW7igJl0IGdldCB3aGF0IHlvdSBuZWVkIGJ5IHBvc3Rpbmcgb24gdGhl IG1haWxpbmcgbGlzdCkgYW5kIHdoYXQgd2lsbCBiZSBjb3ZlcmVkDQoNClRoYW5rcy4NCg0KDQot ICAgICAgICBUb21layAmIEJlcm5pZQ0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AD46EAFnkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxh aW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiXDdFQUZcNjU4N1w2NzJDIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJn aW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1h cmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxl LW5hbWU6Ilw3RUFGXDY1ODdcNjcyQyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6XDdFQUZcNjU4N1w2NzJDOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU0NTk0NjQ1MDsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTY2MjEzNDI4NiAtMTM1NjE3MTg1MCA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYw QTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjY0ODg5ODcyNTsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTk2NjM5MjI3NCA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNDc2 NDg5NzA0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjU0NTc5MzIyO30NCkBsaXN0IGwyOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYw QTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs Mw0KCXttc28tbGlzdC1pZDoxNjU5MjY4ODM0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoyMDEzNTc3NDI4IDE4MDg2ODU4MDQgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNA0K CXttc28tbGlzdC1pZDoxOTc1OTE0ODcxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTY5NTUz MjcwO30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDsgSWYgeW91IHdvdWxkIGxpa2UgdGltZSwgcGxlYXNlIGluZGljYXRlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7IC0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRHJhZnQgbmFtZSBvciB0b3BpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IC0mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2hvIHdpbGwgcHJlc2Vu dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7IC0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSG93IG11Y2ggdGltZSBpcyBuZWVkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyAtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFdoeSBpcyB0aW1lIG5lZWRlZCAodGVsbCB1cyB3aHkgeW91IGNhbjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij7igJk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPnQgZ2V0IHdoYXQgeW91IG5lZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyBieSBwb3N0aW5nIG9uIHRoZSBtYWlsaW5nIGxpc3QpIGFuZCB3aGF0IHdpbGwg YmUgY292ZXJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSdkIGxpa2UgdG8gcmVxdWVzdCBh IDE1IG1pbnV0ZXMgc2xvdCBmb3IgcmVjb25maWd1cmF0aW9uIGluIHN0YXRlbGVzcyBESENQdjYg d29yaywgYXMgVVJJIGJlbG93LiBJIHdpbGwgYmUgdGhlIHByZXNlbnRlci4gVGhpcyB0aW1lIGlz IG5lZWRlZCwgYmVjYXVzZSB0aGlzIGlzIGFuIHVuLXN1cHBvcnQgaXNzdWUgaW4gY3VycmVudCBz dGF0ZWxlc3MgREhDUHY2LiBJdCBpcw0KIGRlZmluaXRlbHkgaW4gdGhlIHNjb3BlIG9mIERIQyBX Ry48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWppYW5nLWRoYy1zdGF0ZWxlc3MtcmVjb25maWd1cmF0aW9u LTAwLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamlhbmct ZGhjLXN0YXRlbGVzcy1yZWNvbmZpZ3VyYXRpb24tMDAudHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+VGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byBnZXQgcmV2aWV3cyBieSB0aGUgV0cs IHBhcnRpY3VsYXJseSBvbiB3aGV0aGVyIHRoaXMgcHJvYmxlbSBhcmUgdmFsaWQuIFdlIGFyZSBh bHNvIG9wZW4gZm9yIGRpc2N1c3Npb24gcmVnYXJkaW5nIHRvIHNvbHV0aW9uIGRlc2lnbi4gU2V2 ZXJhbCBkZXNpZ24gcXVlc3Rpb25zIGFyZSBsaXN0ZWQgaW4gdGhlIGRvY3VtZW50IGZvcg0KIFdH IHRvIGRlY2lkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QgcmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlNoZW5nICYjNDM7IEJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVybmllIFZvbHogKHZvbHopPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgT2N0b2JlciAwNywgMjAxMyAzOjI1IEFNPGJyPg0KPGI+VG86PC9iPiBk aGN3Z0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbZGhjd2ddIENhbGwgZm9yIEFnZW5k YSBJdGVtcyBmb3IgSUVURi04OCAoVmFuY291dmVyKTxicj4NCjxiPkltcG9ydGFuY2U6PC9iPiBI aWdoPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5IaTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIFZhbmNvdXZl ciBJRVRGIGlzIG5vdCB0aGF0IGZhciBvZmYgKE5vdiAzLTgpLiBTZWUNCjxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWVldGluZy84OC9pbmRleC5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzg4L2luZGV4Lmh0bWw8L3Nw YW4+PC9hPiBmb3IgbW9yZSBkZXRhaWxzLCBpbmNsdWRpbmcgdmVudWUgaW5mb3JtYXRpb24gYW5k IGltcG9ydGFudCBkYXRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBwcmVsaW1pbmFyeSBhZ2Vu ZGEgaGFzIHRoZSBESEMgV0cgaXMgc2NoZWR1bGVkIGZvciBUVUVTREFZLCBOb3ZlbWJlciA1IGZy b20gMDkwMC0xMTMwIFBTVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBhbHNvIG5vdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIwMTMtMTAt MDcgKE1vbmRheSk6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDtXb3JraW5nIEdyb3VwIENoYWlyIGFwcHJvdmFsIGZvciBpbml0aWFsIGRv Y3VtZW50IChWZXJzaW9uIC0wMCkNCiBzdWJtaXNzaW9ucyBhcHByZWNpYXRlZCBieSBVVEMgMjQ6 MDAuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNv bG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8zO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MjAxMy0xMC0xMSAoRnJpZGF5KTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw O0ZpbmFsIGFnZW5kYSB0byBiZSBwdWJsaXNoZWQuPG86cD48L286cD48L3NwYW4+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8zO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+MjAxMy0xMC0yMSAoTW9uZGF5KTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO0ludGVybmV0IERyYWZ0IHN1Ym1pc3Npb24gY3V0 LW9mZiAoZm9yIGFsbCBkcmFmdHMsIGluY2x1ZGluZyAtMDApDQogYnkgVVRDIDI0OjAwLCB1cGxv YWQgdXNpbmcmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3N1Ym1p dC8iPklFVEYgSUQgU3VibWlzc2lvbiBUb29sPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2UgYXJlIHN0YXJ0 aW5nIHRoZSBjYWxsIGZvciBhZ2VuZGEgaXRlbXMuIFRoZSBjby1jaGFpcnMgd2lsbCBmaW5hbGl6 ZSB0aGUgYWdlbmRhIGFib3V0IHR3byB3ZWVrcyBiZWZvcmUgdGhlIG1lZXRpbmcgYW5kIHdpbGwg Z2l2ZSBwcmlvcml0eSB0byBpdGVtcyBhcyBmb2xsb3dzIChpbiB0aGlzIG9yZGVyKTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzUiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5XRyBkb2N1bWVudHMgd2l0aCBhY3Rp dmUgd29ya2luZyBncm91cCBkaXNjdXNzaW9uIG9yIHRoYXQgYXJlIGRlZW1lZCBjcml0aWNhbCAo aS5lLiwgaGF2ZSB1cGNvbWluZyBtaWxlc3RvbmVzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t bGlzdDpsMSBsZXZlbDEgbGZvNSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPldHIGRvY3VtZW50cyB3aXRo IGxpdHRsZSBvciBubyBkaXNjdXNzaW9uIChwcm92aWRlZCB0aGVyZSBpcyBhIHN0cm9uZyByZWFz b24gZm9yIHRoZSBkaXNjdXNzaW9uIOKApiBpLmUuLCBhIGhpZ2hlciBiYW5kd2lkdGggZGlzY3Vz c2lvbiBpcyBuZWVkZWQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBs Zm81Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Tm9uIFdHIGRvY3VtZW50cyB3aXRoIGFjdGl2ZSB3b3Jr aW5nIGdyb3VwIGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzUiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Ob24gV0cgZG9jdW1lbnRzIHdpdGggbGl0dGxl IG9yIG5vIGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj5XZSB3aWxsIGxpbWl0IHRoZSBudW1iZXIgb2YgcHJlc2VudGF0 aW9ucyB0byByZWR1Y2UgdGhlIGNoYW5jZSB0aGF0IHdlIGRvbuKAmXQgZ2V0IHRvIHRoZW0gYWxs LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+UGxlYXNlIGJlIHN1cmUgdG8gZm9jdXMgeW91ciBwcmVzZW50 YXRpb25zIG9uIGlzc3VlcyB0aGF0IG5lZWQgZGlzY3Vzc2lvbiBvciBpbnB1dCAobmV3IHdvcmsg Y2FuIGluY2x1ZGUgYW4gb3ZlcnZpZXcsIGJ1dCB0aGUgZm9jdXMgc2hvdWxkIGJlIG9uIGlzc3Vl cyBuZWVkaW5nIHJlc29sdXRpb24pLiBTdGF0dXMgdXBkYXRlcyBjYW4gYmUgc2VudCB0byB0aGUg bWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPklmIHlvdSB3b3VsZCBsaWtlIHRpbWUsIHBsZWFzZSBpbmRpY2F0ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzciPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPkRyYWZ0IG5hbWUgb3IgdG9waWM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzciPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PldobyB3aWxsIHByZXNlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzciPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkhvdyBtdWNoIHRpbWUgaXMgbmVl ZGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm83Ij48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5XaHkgaXMgdGltZSBuZWVkZWQgKHRlbGwgdXMgd2h5IHlv dSBjYW7igJl0IGdldCB3aGF0IHlvdSBuZWVkIGJ5IHBvc3Rpbmcgb24gdGhlIG1haWxpbmcgbGlz dCkgYW5kIHdoYXQgd2lsbCBiZSBjb3ZlcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMyBsZXZlbDEgbGZv OSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VG9tZWsgJmFtcDsgQmVybmllPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B923AD46EAFnkgeml512mbxchi_-- From Ted.Lemon@nominum.com Thu Oct 10 06:42:01 2013 Return-Path: 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 62DF921F9E68; Thu, 10 Oct 2013 06:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.602 X-Spam-Level: X-Spam-Status: No, score=-106.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 wIZmW3Cz40Ee; Thu, 10 Oct 2013 06:41:55 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 55D1621F90DC; Thu, 10 Oct 2013 06:41:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUlaumqZmL9ruZ8euLOmmrIdyUITiTpk8@postini.com; Thu, 10 Oct 2013 06:41:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B64491B80A0; Thu, 10 Oct 2013 06:41:45 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 96B0B19005C; Thu, 10 Oct 2013 06:41:45 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Oct 2013 06:41:45 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: Date: Thu, 10 Oct 2013 09:41:42 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 13:42:01 -0000 On Oct 9, 2013, at 11:49 PM, Cullen Jennings wrote: >> If this argument were correct, we'd expect to see major O.S. vendors = supporting the NTP option, but we don't=97instead, it's something that = can be configured in the UI for situations like the one you describe, = and that otherwise is defaulted to the preconfigured value, which of = course can be updated when the operating system is updated. >=20 > Right - I am certainly more focused on the devices that don't have an = administrator that can configure them locally.=20 This is great, but that's not all devices. And devices of this type = often wind up being very vulnerable to attack precisely because no = usable escape mechanism is offered. DHCP may be your only choice for = configuring such a device, but it's a really lousy choice. >> So where I would expect to see the NTP option used is in devices that = don't _have_ user interfaces. Your IP phone might be such a device. = I suspect the bias you have toward using a DHCP option has a lot to do = with where these devices are typically installed: in corporate = environments. >=20 > Agree I am focused on the VoIP stuff but it is both SP and = enterprises.=20 >=20 >> I don't even know if I could get one to use at home, or if it would = work. >=20 > They work in residential deployments (which might be a bit different = than you mean by home) and DHCP can provide some very critical services = for them. For example rfc5223 is a DHCP options that provides the LOST = server that provides the mapping to locations that can be used for E911 = calls and is applicable to residential.=20 I challenge you to find a single commonly-used home gateway that = supports this RFC, and that is not VoIP-specific. If one does, it's = hard to see any reason why it matters whether the IP address of the E911 = location service protocol is delivered directly or through an FQDN. > Sure I believe you about what DHCP servers are capable of doing (which = I will note might be different than how they are commonly deployed). I = was talking about the issue here of from a protocol design point of = view, one should prefer the use of an IP address or FQDN in the DHCP = option for a case like this.=20 Commonly deployed by whom? The ISC DHCP server supported the = functionality that I'm describing in 1997. Nominum's DHCP server = supported it on first release. Cisco's server supported it back when = it was still a separate company called American Internet, at least as = early as 1997. The only commonly-used server that I think does not = support this functionality is Microsoft's. I suppose some enterprise = environments might use this server, which might explain why you are = assuming that behavior, but we shouldn't decide how to do things based = on a single implementation that, if it operates in the way you describe, = is IMHO broken. > When I said "move" I'm talking the roughly the same thing as you mean = here of bring up a new service. So lets take a VoIP provider like AT&T = or a large enterprise like GE. Let say that have a server called = time.ge.com in DNS. Figuring out the TTL for that is pretty easy. = Changing it to reduce down around the time of the move is pretty easy as = you can chance it one place and DNS sync it to the other DNS servers. = Now lets consider doing the same thing with DHCP. How many DHCP server = do you think either of theses have? Consistent tools to manage all them = from a central location? The admin know when they are moving servers = they need to deal with the DNS - but do they all even remember to update = the DHCP? >=20 > The we have the issue of NATs that act as DHCP clients, get an option, = then re-advertise that option as a DHCP server on the private side. I = realize that if they advertise it for longer on the private side than = the lease was valid on the public side is just really broken, but none = the less I'm sure no one will be shocked to find out there are broken = NATs.=20 >=20 > I've been involved with deployments bitten by every one of of the = above. That make me prefer FQDN unless it is a case where DNS might not = be supported or not operational, or a case where the time / power of the = DNS query makes a significant difference to the system.=20 Right, and I think I already said that (a) SIP is a bad example of a use = case for DHCP, because it's a node-specific service, not a = network-specific service, and (b) it's probably fine, if you must use = DHCP to configure SIP, to use an FQDN, as I already said several = messages back. > I thought about what you wrote here for a long time. I suspect that is = part of the issue is that people such as myself that are not DHCP = experts don't know what services are not appropriate to use it for. We = see it as a hammer and we are off pounding nails, or screws. I view SRV = as an OK way to control load balancing across a set of servers that have = different capacity - often due to be deployed on faster computers over = time. Why would a service with that property not be someone one would = use DHCP for.=20 Well, for example, would you use SRV records to do load balancing on a = DNS server? An NTP server? A router (which in the context of DHCPv6 = probably means an AFTR)? I think you would not. >> I would argue that if it makes any sense at all for there to be a = SRV record, that's a strong argument against using DHCP to configure = that service. =20 >=20 > tell me more - this one I did not get.=20 SRV records are normally used for application-layer services, like SIP, = which I don't think should be configured with DHCP. Similarly, would = you use DHCP to configure the address of an HTTP server? :) >> Right, and at the moment they almost certainly have their NTP server = FQDNs hard-coded, and it works, and you don't even know it's working = this way, because it's a solid solution in a home network. The issue = with DNS on constrained devices is that it's another packet round trip, = and packets burn battery. =20 >=20 > Give me an example where that makes a difference. When I look at this = as the power to do a DNS query amortized over the lifetime of the lease = or uptime of the device I'm just having a hard time thinking of the = right example to motivate this.=20 Any device that has a battery and needs to run unattended for a long = period of time will pay a penalty for doing DNS queries over and over = again; requiring it to do so is a bad practice. If such a device does = use DHCP, it almost certainly wants to use very long information refresh = timers. Using a short TTL in DNS for a service used by such a device = either will not work, or will cause the device to prematurely drain its = battery. These devices are real, likely represent a very significant area of IP = service growth in the coming decade or two, and need to be supported. = If such a device uses a service discovery protocol, and that service = discovery protocol probably were to deliver information via FQDNs, the = device would have to query the DNS multiple times, at least one for each = service, in order to resolve those FQDNs, each time it does a service = discovery refresh. It would also be well advised to query those FQDNs = again anytime the TTL on the record returned in the previous query = expired. DHCP does all the queries for you at the same time and hands you a = single packet with all the information you need to contact all the = services offered by DHCP. This can be expected to result in many fewer = packet round trips, and consequently much less power spent. This is a = significant feature; getting rid of it in order to make life a little = more convenient for operators who do not have to deal with these = constraints is a poor value proposition for the protocol as a whole. BTW, another example of a constrained device is a network booted device, = where despite the fact that the node itself is quite capable once it's = booted, the boot prom is quite constrained. I think this was a primary = motivation for the choice of address versus FQDN back in DHCPv4 days; I = suspect relevant in fewer cases now, but still relevant in some. (I will note, by the way, that you have yet to raise a point that was = not considered and addressed by the working group. I think this = discussion is useful, because it points to clarifications that should be = made to the document, but I don't yet see anything that would suggest to = me that the consensus call went the wrong way.)= From stenc@s-carlsen.dk Thu Oct 10 07:20:55 2013 Return-Path: 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 3F96421E805D for ; Thu, 10 Oct 2013 07:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 uvtxeGotfpRY for ; Thu, 10 Oct 2013 07:20:54 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 13F1021F9DD5 for ; Thu, 10 Oct 2013 07:20:53 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id EF7A42A53 for ; Thu, 10 Oct 2013 16:20:49 +0200 (CEST) Message-ID: <5256B7C1.8060402@s-carlsen.dk> Date: Thu, 10 Oct 2013 16:20:49 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> In-Reply-To: <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------070605000202080905000104" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:20:55 -0000 This is a multi-part message in MIME format. --------------070605000202080905000104 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit One question for my information, pls. see below: On 10/10/13 15:41, Ted Lemon wrote: > DHCP does all the queries for you at the same time and hands you a > single packet with all the information you need to contact all the > services offered by DHCP. This can be expected to result in many fewer > packet round trips, and consequently much less power spent. This is a > significant feature; getting rid of it in order to make life a little > more convenient for operators who do not have to deal with these > constraints is a poor value proposition for the protocol as a whole. Would the DHCP-server do a fresh lookup for every request and every renewal? If it does, it will allow the device to follow changes in the network though with a delay of a lease time. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------070605000202080905000104 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit One question for my information, pls. see below:

On 10/10/13 15:41, Ted Lemon wrote:
DHCP does all the queries for you at the same time and hands you a single packet with all the information you need to contact all the services offered by DHCP. This can be expected to result in many fewer packet round trips, and consequently much less power spent. This is a significant feature; getting rid of it in order to make life a little more convenient for operators who do not have to deal with these constraints is a poor value proposition for the protocol as a whole.
Would the DHCP-server do a fresh lookup for every request and every renewal? If it does, it will allow the device to follow changes in the network though with a delay of a lease time.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------070605000202080905000104-- From Ted.Lemon@nominum.com Thu Oct 10 07:23:20 2013 Return-Path: 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 C7D8211E8169 for ; Thu, 10 Oct 2013 07:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.602 X-Spam-Level: X-Spam-Status: No, score=-106.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 TYvHT+gS7e1h for ; Thu, 10 Oct 2013 07:23:14 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id E7C2A11E8172 for ; Thu, 10 Oct 2013 07:22:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUla4QRD8EvhlfY7QAgn4oAhNSBZ0XXlp@postini.com; Thu, 10 Oct 2013 07:23:01 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0CE041B82E3 for ; Thu, 10 Oct 2013 07:22:57 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E674619005C; Thu, 10 Oct 2013 07:22:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Oct 2013 07:22:56 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <5256B7C1.8060402@s-carlsen.dk> Date: Thu, 10 Oct 2013 10:22:53 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:23:20 -0000 On Oct 10, 2013, at 10:20 AM, Sten Carlsen wrote: > Would the DHCP-server do a fresh lookup for every request and every = renewal? If it does, it will allow the device to follow changes in the = network though with a delay of a lease time. This isn't required by the protocol spec, but it's what most DHCP = servers currently do. From stenc@s-carlsen.dk Thu Oct 10 07:29:28 2013 Return-Path: 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 79B6321F9B28 for ; Thu, 10 Oct 2013 07:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 sCyTM4hnzGf7 for ; Thu, 10 Oct 2013 07:29:24 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 8A59E11E8177 for ; Thu, 10 Oct 2013 07:29:14 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 85C24124; Thu, 10 Oct 2013 16:29:09 +0200 (CEST) Message-ID: <5256B9B5.4050206@s-carlsen.dk> Date: Thu, 10 Oct 2013 16:29:09 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ted Lemon References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------060609040207090801090505" Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:29:28 -0000 This is a multi-part message in MIME format. --------------060609040207090801090505 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/10/13 16:22, Ted Lemon wrote: > On Oct 10, 2013, at 10:20 AM, Sten Carlsen wrote: >> Would the DHCP-server do a fresh lookup for every request and every renewal? If it does, it will allow the device to follow changes in the network though with a delay of a lease time. > This isn't required by the protocol spec, but it's what most DHCP servers currently do. Thanks, I then assume the ISC server does. Would such a requirement be a way to settle the differences here? > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------060609040207090801090505 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 10/10/13 16:22, Ted Lemon wrote:
On Oct 10, 2013, at 10:20 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

Would the DHCP-server do a fresh lookup for every request and every renewal? If it does, it will allow the device to follow changes in the network though with a delay of a lease time.

This isn't required by the protocol spec, but it's what most DHCP servers currently do.
Thanks, I then assume the ISC server does. Would such a requirement be a way to settle the differences here?



-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------060609040207090801090505-- From Ted.Lemon@nominum.com Thu Oct 10 07:39:44 2013 Return-Path: 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 963AE21E805D for ; Thu, 10 Oct 2013 07:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.602 X-Spam-Level: X-Spam-Status: No, score=-106.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 iiMt+bIe5t7k for ; Thu, 10 Oct 2013 07:39:32 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id B532721E8089 for ; Thu, 10 Oct 2013 07:39:31 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUla8I0+wOPDNBgYROmwRpPQpDPWJO2ff@postini.com; Thu, 10 Oct 2013 07:39:31 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5BC841B82DF for ; Thu, 10 Oct 2013 07:39:31 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 55C9319005C; Thu, 10 Oct 2013 07:39:31 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Oct 2013 07:39:25 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <5256B9B5.4050206@s-carlsen.dk> Date: Thu, 10 Oct 2013 10:39:22 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> <5256B9B5.4050206@s-carlsen.dk> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:39:44 -0000 On Oct 10, 2013, at 10:29 AM, Sten Carlsen wrote: > Thanks, I then assume the ISC server does. Would such a requirement be = a way to settle the differences here? I don't think it should be done in this document, because this is really = documenting best practices for protocol spec writers, not DHCP server = implementors. However, I think this behavior is worth recommending (indeed, there's a = document I submitted a while back that could probably be turned to this = purpose) but I don't think it can be required, because a really minimal = DHCP server might not even do DNS resolution, and that ought to be = allowed. From Ted.Lemon@nominum.com Thu Oct 10 07:44:32 2013 Return-Path: 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 B223321F9AF8 for ; Thu, 10 Oct 2013 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.601 X-Spam-Level: X-Spam-Status: No, score=-106.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 R+GeI3v27YiS for ; Thu, 10 Oct 2013 07:44:26 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id DEF6021F9634 for ; Thu, 10 Oct 2013 07:44:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUla9QQXT6fKUWZQJpzCMRs2wSwnDPxGS@postini.com; Thu, 10 Oct 2013 07:44:22 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D98E91B82DF for ; Thu, 10 Oct 2013 07:44:16 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D310219005C; Thu, 10 Oct 2013 07:44:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Oct 2013 07:44:16 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> Date: Thu, 10 Oct 2013 10:44:14 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <4DFF82FC-1F25-4143-ABA7-071B745D8785@nominum.com> References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> <5256B9B5.4050206@s-carlsen.dk> <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:44:32 -0000 On Oct 10, 2013, at 10:39 AM, Ted Lemon wrote: > However, I think this behavior is worth recommending (indeed, there's = a document I submitted a while back that could probably be turned to = this purpose) but I don't think it can be required, because a really = minimal DHCP server might not even do DNS resolution, and that ought to = be allowed. BTW, the document in question is this one: = http://tools.ietf.org/html/draft-lemon-dhc-topo-conf-01 Section 5 talks about this very issue. The document could really use a = non-AD author=97the chances of me advancing it to standard in the near = future are slim indeed. From stenc@s-carlsen.dk Thu Oct 10 07:45:22 2013 Return-Path: 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 610D921F9AF8 for ; Thu, 10 Oct 2013 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 2l4ZNhLOUqUT for ; Thu, 10 Oct 2013 07:45:21 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 02E0F21F9C99 for ; Thu, 10 Oct 2013 07:45:12 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 74DB82A53; Thu, 10 Oct 2013 16:45:06 +0200 (CEST) Message-ID: <5256BD72.8020809@s-carlsen.dk> Date: Thu, 10 Oct 2013 16:45:06 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ted Lemon References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> <5256B9B5.4050206@s-carlsen.dk> <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> In-Reply-To: <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------060506080505030809090407" Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:45:22 -0000 This is a multi-part message in MIME format. --------------060506080505030809090407 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/10/13 16:39, Ted Lemon wrote: > On Oct 10, 2013, at 10:29 AM, Sten Carlsen wrote: >> Thanks, I then assume the ISC server does. Would such a requirement be a way to settle the differences here? > I don't think it should be done in this document, because this is really documenting best practices for protocol spec writers, not DHCP server implementors. Right, it just occurred to me in this discussion. > > However, I think this behavior is worth recommending (indeed, there's a document I submitted a while back that could probably be turned to this purpose) but I don't think it can be required, because a really minimal DHCP server might not even do DNS resolution, and that ought to be allowed. What about requiring that it does a fresh lookup, IF it has the server specified as an FQDN? If it is only specified as an IP, obviously there is no option for lookup. As for the place to put it, I have no preference. > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------060506080505030809090407 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 10/10/13 16:39, Ted Lemon wrote:
On Oct 10, 2013, at 10:29 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

Thanks, I then assume the ISC server does. Would such a requirement be a way to settle the differences here?

I don't think it should be done in this document, because this is really documenting best practices for protocol spec writers, not DHCP server implementors.
Right, it just occurred to me in this discussion.

However, I think this behavior is worth recommending (indeed, there's a document I submitted a while back that could probably be turned to this purpose) but I don't think it can be required, because a really minimal DHCP server might not even do DNS resolution, and that ought to be allowed.
What about requiring that it does a fresh lookup, IF it has the server specified as an FQDN? If it is only specified as an IP, obviously there is no option for lookup.
As for the place to put it, I have no preference.



-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------060506080505030809090407-- From Ted.Lemon@nominum.com Thu Oct 10 07:47:10 2013 Return-Path: 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 AD5F921F9A1C for ; Thu, 10 Oct 2013 07:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.601 X-Spam-Level: X-Spam-Status: No, score=-106.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 GsDdvEwoUqDD for ; Thu, 10 Oct 2013 07:46:47 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4245B21E8083 for ; Thu, 10 Oct 2013 07:46:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUla9u9O22hfpV3lTeztMp5YL2hE962Wf@postini.com; Thu, 10 Oct 2013 07:46:30 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D0E651B82E3 for ; Thu, 10 Oct 2013 07:46:18 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C9E9419005C; Thu, 10 Oct 2013 07:46:18 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Oct 2013 07:46:18 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <5256BD72.8020809@s-carlsen.dk> Date: Thu, 10 Oct 2013 10:46:16 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <02019EED-9776-4F34-8B4A-CBA59B3009FC@nominum.com> References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> <5256B9B5.4050206@s-carlsen.dk> <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> <5256BD72.8020809@s-carlsen.dk> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:47:16 -0000 On Oct 10, 2013, at 10:45 AM, Sten Carlsen wrote: > What about requiring that it does a fresh lookup, IF it has the server = specified as an FQDN? If it is only specified as an IP, obviously there = is no option for lookup. I think you just answered your own question. :) From Ted.Lemon@nominum.com Thu Oct 10 07:52:30 2013 Return-Path: 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 395C321E80ED for ; Thu, 10 Oct 2013 07:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.601 X-Spam-Level: X-Spam-Status: No, score=-106.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Pc1rSCv9c4Mq for ; Thu, 10 Oct 2013 07:52:13 -0700 (PDT) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5A09121E809F for ; Thu, 10 Oct 2013 07:52:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUla/Fl5egyYjOHbvfVXUux2Sc5Fta8jJ@postini.com; Thu, 10 Oct 2013 07:52:07 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C723B1B82DF for ; Thu, 10 Oct 2013 07:52:06 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C07CF19005C; Thu, 10 Oct 2013 07:52:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Oct 2013 07:52:06 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <02019EED-9776-4F34-8B4A-CBA59B3009FC@nominum.com> Date: Thu, 10 Oct 2013 10:52:03 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <34405136-69DE-46C3-AC25-870029698C10@nominum.com> References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> <5256B9B5.4050206@s-carlsen.dk> <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> <5256BD72.8020809@s-carlsen.dk> <02019EED-9776-4F34-8B4A-CBA59B3009FC@nominum.com> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:52:31 -0000 On Oct 10, 2013, at 10:46 AM, Ted Lemon wrote: > On Oct 10, 2013, at 10:45 AM, Sten Carlsen wrote: >> What about requiring that it does a fresh lookup, IF it has the = server specified as an FQDN? If it is only specified as an IP, obviously = there is no option for lookup. >=20 > I think you just answered your own question. :) No, actually I just realized that I misunderstood your point. I think = you are right=97if a name is entered into the UI, it needs to be = resolved by the DHCP server at least as frequently as the TTL for the = record that's returned when it's queried. From stenc@s-carlsen.dk Thu Oct 10 08:20:52 2013 Return-Path: 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 1F0E011E817E for ; Thu, 10 Oct 2013 08:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 XFwjay+3cjF4 for ; Thu, 10 Oct 2013 08:20:50 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 401D511E817F for ; Thu, 10 Oct 2013 08:20:47 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 13946124; Thu, 10 Oct 2013 17:20:44 +0200 (CEST) Message-ID: <5256C5CB.9070709@s-carlsen.dk> Date: Thu, 10 Oct 2013 17:20:43 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ted Lemon References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> <5256B9B5.4050206@s-carlsen.dk> <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> <5256BD72.8020809@s-carlsen.dk> <02019EED-9776-4F34-8B4A-CBA59B3009FC@nominum.com> <34405136-69DE-46C3-AC25-870029698C10@nominum.com> In-Reply-To: <34405136-69DE-46C3-AC25-870029698C10@nominum.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------060901060301010803000609" Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:20:52 -0000 This is a multi-part message in MIME format. --------------060901060301010803000609 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 10/10/13 16:52, Ted Lemon wrote: > On Oct 10, 2013, at 10:46 AM, Ted Lemon wrote: >> On Oct 10, 2013, at 10:45 AM, Sten Carlsen wrote: >>> What about requiring that it does a fresh lookup, IF it has the server specified as an FQDN? If it is only specified as an IP, obviously there is no option for lookup. >> I think you just answered your own question. :) > No, actually I just realized that I misunderstood your point. I think you are right—if a name is entered into the UI, it needs to be resolved by the DHCP server at least as frequently as the TTL for the record that's returned when it's queried. Just my point, that way any change would be picked up by devices even if only IPs are sent in the option. I did read your document, I think it would be good to get that finished and made a standard. I do not quite see that it would be the place to put the above requirement though since it states very clearly that it places no new requirements on DHCP servers. It might be good to keep it as a "Best practices of use" document. > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------060901060301010803000609 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/10/13 16:52, Ted Lemon wrote:
On Oct 10, 2013, at 10:46 AM, Ted Lemon <ted.lemon@nominum.com> wrote:

On Oct 10, 2013, at 10:45 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

What about requiring that it does a fresh lookup, IF it has the server specified as an FQDN? If it is only specified as an IP, obviously there is no option for lookup.

I think you just answered your own question. :)

No, actually I just realized that I misunderstood your point.   I think you are right—if a name is entered into the UI, it needs to be resolved by the DHCP server at least as frequently as the TTL for the record that's returned when it's queried.
Just my point, that way any change would be picked up by devices even if only IPs are sent in the option.

I did read your document, I think it would be good to get that finished and made a standard. I do not quite see that it would be the place to put the above requirement though since it states very clearly that it places no new requirements on DHCP servers. It might be good to keep it as a "Best practices of use" document.



-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------060901060301010803000609-- From Ted.Lemon@nominum.com Thu Oct 10 08:28:08 2013 Return-Path: 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 5032211E817D for ; Thu, 10 Oct 2013 08:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.601 X-Spam-Level: X-Spam-Status: No, score=-106.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 TN5A5G4mjFej for ; Thu, 10 Oct 2013 08:28:01 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C5DFC11E81C8 for ; Thu, 10 Oct 2013 08:26:15 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUlbHEEf8VmWWUTiQ/QtvPdSzfxSN0DYa@postini.com; Thu, 10 Oct 2013 08:26:16 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1356B1B82EA for ; Thu, 10 Oct 2013 08:26:08 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0CC8619005C; Thu, 10 Oct 2013 08:26:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Oct 2013 08:26:07 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <5256C5CB.9070709@s-carlsen.dk> Date: Thu, 10 Oct 2013 11:26:04 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> <5256B9B5.4050206@s-carlsen.dk> <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> <5256BD72.8020809@s-carlsen.dk> <02019EED-9776-4F34-8B4A-CBA59B3009FC@nominum.com> <34405136-69DE-46C3-AC25-870029698C10@nominum.com> <5256C5CB.9070709@s-carlsen.dk> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:28:08 -0000 On Oct 10, 2013, at 11:20 AM, Sten Carlsen wrote: > I did read your document, I think it would be good to get that = finished and made a standard. I do not quite see that it would be the = place to put the above requirement though since it states very clearly = that it places no new requirements on DHCP servers. It might be good to = keep it as a "Best practices of use" document. Yeah, after reviewing it I tend to think you are right. From volz@cisco.com Sat Oct 12 07:26:24 2013 Return-Path: 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 6975F21E8176 for ; Sat, 12 Oct 2013 07:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 r5MBD3tUg1Ro for ; Sat, 12 Oct 2013 07:26:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6021F9DCA for ; Sat, 12 Oct 2013 07:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1791; q=dns/txt; s=iport; t=1381587974; x=1382797574; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MOsa+Lr7Z9OTxVZXcievaNHkHucTt9gVjwXTNefmlnc=; b=nA8r1foNsQTZM4ZYyUI/JjXxmxzyOeUmfPabwbaxgEjHebUhbe5mxZcx BvDECYu72Ns+cKGTrtXTe9qSq6VZhbroe8O7BaP+500tZIUrN/HGi/yYu +yRnMkWiX5cpPxC0SG/uV8qqdOEeuaeOn9oakmFIbtrjEy/Pw31ga37IZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAJBbWVKtJV2c/2dsb2JhbABZgwc4UsFjgRkWdIIlAQEBBAEBATc0CwwEAgEIEQQBAQEKFAUEBycLFAkIAgQBDQUIh34MvUEEjyExBwaDGYEEA6oHgWaBPoIp X-IronPort-AV: E=Sophos;i="4.93,480,1378857600"; d="scan'208";a="271347886" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 12 Oct 2013 14:26:13 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9CEQDVP015170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 12 Oct 2013 14:26:13 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Sat, 12 Oct 2013 09:26:13 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Sten Carlsen Thread-Topic: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice Thread-Index: AQHOxceyuxa/dNkayUijisysRf57GpnxICNA Date: Sat, 12 Oct 2013 14:26:12 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD17415@xmb-rcd-x04.cisco.com> References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> <5256B9B5.4050206@s-carlsen.dk> <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> <5256BD72.8020809@s-carlsen.dk> <02019EED-9776-4F34-8B4A-CBA59B3009FC@nominum.com> In-Reply-To: <02019EED-9776-4F34-8B4A-CBA59B3009FC@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 14:26:24 -0000 WG CO-CHAIR HAT OFF. Two points: 1. A server should NOT be required to do a "fresh" lookup if the TTL for th= e DNS information has not expired [or it not close to expiring]. 2. This doesn't solve all of the issues since the DNS TTL, as Ted has point= ed out in some discussions, is not generally related to the lease (or renew= al) time. Thus, it really depends on when the client is expected to use thi= s information which could be long after the TTL for the original DNS query = has expired. Hence, depending on when a client is expected to use this information shoul= d greatly influence the decision as to whether to define an option as an FQ= DN or address(es). For example, for a next step bootstrap loader (or config= uration file such as for DOCSIS), an address is fine as this is expected to= be used by the client almost immediately. Something that may be used hours= or days later when a user requests a particular application really SHOULD = use an FQDN. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, October 10, 2013 10:46 AM To: Sten Carlsen Cc: dhcwg@ietf.org WG Subject: Re: [dhcwg] Last Call: (= Guidelines for Creating New DHCPv6 Options) to Best Current Practice On Oct 10, 2013, at 10:45 AM, Sten Carlsen wrote: > What about requiring that it does a fresh lookup, IF it has the server sp= ecified as an FQDN? If it is only specified as an IP, obviously there is no= option for lookup. I think you just answered your own question. :) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From stenc@s-carlsen.dk Sat Oct 12 11:02:52 2013 Return-Path: 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 68F0321E8108 for ; Sat, 12 Oct 2013 11:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 6i16GDBW4Cli for ; Sat, 12 Oct 2013 11:02:50 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id B237B21E8063 for ; Sat, 12 Oct 2013 11:02:46 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (silver4-wire.s-carlsen.dk [192.168.16.130]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 0A62241B5; Sat, 12 Oct 2013 20:02:44 +0200 (CEST) Message-ID: <52598EC3.3060404@s-carlsen.dk> Date: Sat, 12 Oct 2013 20:02:43 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <5256B7C1.8060402@s-carlsen.dk> <5256B9B5.4050206@s-carlsen.dk> <1753F064-4940-49DE-96B7-50A42BFD6FF7@nominum.com> <5256BD72.8020809@s-carlsen.dk> <02019EED-9776-4F34-8B4A-CBA59B3009FC@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AD17415@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD17415@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------020009020804060800030704" Cc: "dhcwg@ietf.org WG" , Ted Lemon Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 18:02:52 -0000 This is a multi-part message in MIME format. --------------020009020804060800030704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit My 0.02EUR/$ On 12/10/13 16:26, Bernie Volz (volz) wrote: > WG CO-CHAIR HAT OFF. > > Two points: > > 1. A server should NOT be required to do a "fresh" lookup if the TTL for the DNS information has not expired [or it not close to expiring]. This is ok, we *should* expect that change in e.g. ntp servers coincide with a change in DNS, hence new information should appear at a time "natural" lookup time. > > 2. This doesn't solve all of the issues since the DNS TTL, as Ted has pointed out in some discussions, is not generally related to the lease (or renewal) time. Thus, it really depends on when the client is expected to use this information which could be long after the TTL for the original DNS query has expired. It clearly does not solve the issue but makes it possible to manage the world so it does partly solve the issue. -> make sure your DHCP renewal period is short enough that a renewal will pick up the change soon enough, coordinated with DNS TTLs. I know it is not too pretty, so any better ideas are welcome. > > Hence, depending on when a client is expected to use this information should greatly influence the decision as to whether to define an option as an FQDN or address(es). For example, for a next step bootstrap loader (or configuration file such as for DOCSIS), an address is fine as this is expected to be used by the client almost immediately. Something that may be used hours or days later when a user requests a particular application really SHOULD use an FQDN. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Thursday, October 10, 2013 10:46 AM > To: Sten Carlsen > Cc: dhcwg@ietf.org WG > Subject: Re: [dhcwg] Last Call: (Guidelines for Creating New DHCPv6 Options) to Best Current Practice > > On Oct 10, 2013, at 10:45 AM, Sten Carlsen wrote: >> What about requiring that it does a fresh lookup, IF it has the server specified as an FQDN? If it is only specified as an IP, obviously there is no option for lookup. > I think you just answered your own question. :) > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------020009020804060800030704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit My 0.02€/$

On 12/10/13 16:26, Bernie Volz (volz) wrote:
WG CO-CHAIR HAT OFF.

Two points:

1. A server should NOT be required to do a "fresh" lookup if the TTL for the DNS information has not expired [or it not close to expiring].
This is ok, we *should* expect that change in e.g. ntp servers coincide with a change in DNS, hence new information should appear at a time "natural" lookup time.

2. This doesn't solve all of the issues since the DNS TTL, as Ted has pointed out in some discussions, is not generally related to the lease (or renewal) time. Thus, it really depends on when the client is expected to use this information which could be long after the TTL for the original DNS query has expired.
It clearly does not solve the issue but makes it possible to manage the world so it does partly solve the issue. -> make sure your DHCP renewal period is short enough that a renewal will pick up the change soon enough, coordinated with DNS TTLs.

I know it is not too pretty, so any better ideas are welcome.

Hence, depending on when a client is expected to use this information should greatly influence the decision as to whether to define an option as an FQDN or address(es). For example, for a next step bootstrap loader (or configuration file such as for DOCSIS), an address is fine as this is expected to be used by the client almost immediately. Something that may be used hours or days later when a user requests a particular application really SHOULD use an FQDN.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Thursday, October 10, 2013 10:46 AM
To: Sten Carlsen
Cc: dhcwg@ietf.org WG
Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

On Oct 10, 2013, at 10:45 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

What about requiring that it does a fresh lookup, IF it has the server specified as an FQDN? If it is only specified as an IP, obviously there is no option for lookup.

I think you just answered your own question. :)

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


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------020009020804060800030704-- From mellon@fugue.com Mon Oct 14 11:26:09 2013 Return-Path: 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 4253121E80EA for ; Mon, 14 Oct 2013 11:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Dbv5SMKKY0+5 for ; Mon, 14 Oct 2013 11:25:56 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id CF2B921E80CD for ; Mon, 14 Oct 2013 11:25:41 -0700 (PDT) Received: from [IPv6:2001:470:88a3::b5e5:37d4:74de:f011] (unknown [IPv6:2001:470:88a3:0:b5e5:37d4:74de:f011]) by toccata.fugue.com (Postfix) with ESMTPSA id BB34B238033F for ; Mon, 14 Oct 2013 14:25:37 -0400 (EDT) From: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> Date: Mon, 14 Oct 2013 14:25:35 -0400 To: "dhcwg@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) X-Mailer: Apple Mail (2.1812) Subject: [dhcwg] What sorts of services does DHCP configure? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 18:26:09 -0000 During the IESG review of the DHCP Option Guidelines document, a number = of issues came up, but the most contentious had to do with the question = of exactly what services it makes sense to configure with DHCP. This = is an issue because the use model for one class of such services is = quite different from the use model for the other class, and prospective = users of DHCP to configure services of the other class therefore = disputed the option document's advice on when to use FQDNs. The dichotomy that I would like us to discuss is between = network-specific services and node-specific services. To illustrate what I mean, consider DNS. DNS is the same everywhere = (at least in principle). If I ask a question of a DNS server on = network A, and ask the same question on network B, I should get an = equivalent answer; at the very least, the answer should come from the = same data, and should validate with DNSSEC. So it doesn't matter which = DNS resolver I use, and indeed this matches how we use DNS. So DNS is = a network-specific service: the DNS server you use probably should be = the one closest to you. Now, consider IMAP. If you use IMAP, you probably have one or more = IMAP servers. These servers are fixed in location. You do not check = a different IMAP server when you are at Starbucks than you do when you = are at home, or at work. So IMAP is a node-specific service=97your = IMAP configuration stays with your laptop or tablet, and does not change = as you move from network to network. If you look at the list of DHCPv4 options, you can find lots of = IMAP-like services, and lots of DNS-like services. I think that the = DHCPv4 options for configuring node-specific services are a mistake=97they= are a throwback to a time when nodes didn't move around, so we weren't = aware that we had a problem with the use model for DHCPv4 in configuring = things like SMTP and IMAP. At the same time, during the discussion about the Option Guidelines = draft, several people raised the idea of services that are configured = via DHCP, even though they are node-specific, because in certain cases = that's the only option, and it makes sense to configure them that way in = those cases. For instance, a desktop SIP phone might get its initial = SIP configuration over DHCP, and then not use DHCP to get SIP = configuration anymore. I am going to make a claim, and I would like the working group to tell = me whether they agree with or disagree with this claim. My claim is = that DHCP doesn't make sense for configuring node-specific services. = There may be edge cases where a node-specific service can be configured = using DHCP, but DHCP isn't the right service to be used in this = case=97it's used in this case because there is no better alternative, = not because DHCP is a good alternative. And while there may be edge = cases where configuring a particular node-specific service using DHCP = makes sense, there will be many more cases where using DHCP to configure = that same service would not only not work, but would probably create = serious security vulnerabilities. Thoughts?= From stenc@s-carlsen.dk Mon Oct 14 12:02:58 2013 Return-Path: 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 5B78D21E80B7 for ; Mon, 14 Oct 2013 12:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 WFCR5Hj7OUJH for ; Mon, 14 Oct 2013 12:02:53 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7311E81B0 for ; Mon, 14 Oct 2013 12:02:07 -0700 (PDT) Received: from silver3wired.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fefe:16ca]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 109052B24 for ; Mon, 14 Oct 2013 21:01:52 +0200 (CEST) Message-ID: <525C3FA0.5010003@s-carlsen.dk> Date: Mon, 14 Oct 2013 21:01:52 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> In-Reply-To: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> Content-Type: multipart/alternative; boundary="------------000000010708000000090602" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 19:02:58 -0000 This is a multi-part message in MIME format. --------------000000010708000000090602 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit My 0.02€/$ I don't agree, certain node specific services are being set by DHCP and should continue to be so. Examples are routers and DNS servers. The system that really knows where in the world your laptop is at this moment is DHCP and of course to a small degree the router itself, though it only offers you a prefix and a gateway (in case stateless operation is allowed). Who else would know where you are and therefore which server would make sense to use here? IMAP servers are different as you normally have an account on them and they are not the same for all users on this network segment, SMTP servers may be the same. I agree that there is a dividing line, just not there. And of course which other service should take the task of telling me those things? Which other server will know my whereabouts so precisely that it can hand out those informations? On 14/10/13 20.25, Ted Lemon wrote: > During the IESG review of the DHCP Option Guidelines document, a number of issues came up, but the most contentious had to do with the question of exactly what services it makes sense to configure with DHCP. This is an issue because the use model for one class of such services is quite different from the use model for the other class, and prospective users of DHCP to configure services of the other class therefore disputed the option document's advice on when to use FQDNs. > > The dichotomy that I would like us to discuss is between network-specific services and node-specific services. > > To illustrate what I mean, consider DNS. DNS is the same everywhere (at least in principle). If I ask a question of a DNS server on network A, and ask the same question on network B, I should get an equivalent answer; at the very least, the answer should come from the same data, and should validate with DNSSEC. So it doesn't matter which DNS resolver I use, and indeed this matches how we use DNS. So DNS is a network-specific service: the DNS server you use probably should be the one closest to you. > > Now, consider IMAP. If you use IMAP, you probably have one or more IMAP servers. These servers are fixed in location. You do not check a different IMAP server when you are at Starbucks than you do when you are at home, or at work. So IMAP is a node-specific service—your IMAP configuration stays with your laptop or tablet, and does not change as you move from network to network. > > If you look at the list of DHCPv4 options, you can find lots of IMAP-like services, and lots of DNS-like services. I think that the DHCPv4 options for configuring node-specific services are a mistake—they are a throwback to a time when nodes didn't move around, so we weren't aware that we had a problem with the use model for DHCPv4 in configuring things like SMTP and IMAP. > > At the same time, during the discussion about the Option Guidelines draft, several people raised the idea of services that are configured via DHCP, even though they are node-specific, because in certain cases that's the only option, and it makes sense to configure them that way in those cases. For instance, a desktop SIP phone might get its initial SIP configuration over DHCP, and then not use DHCP to get SIP configuration anymore. > > I am going to make a claim, and I would like the working group to tell me whether they agree with or disagree with this claim. My claim is that DHCP doesn't make sense for configuring node-specific services. There may be edge cases where a node-specific service can be configured using DHCP, but DHCP isn't the right service to be used in this case—it's used in this case because there is no better alternative, not because DHCP is a good alternative. And while there may be edge cases where configuring a particular node-specific service using DHCP makes sense, there will be many more cases where using DHCP to configure that same service would not only not work, but would probably create serious security vulnerabilities. > > Thoughts? > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------000000010708000000090602 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit My 0.02€/$

I don't agree, certain node specific services are being set by DHCP and should continue to be so. Examples are routers and DNS servers.

The system that really knows where in the world your laptop is at this moment is DHCP and of course to a small degree the router itself, though it only offers you a prefix and a gateway (in case stateless operation is allowed). Who else would know where you are and therefore which server would make sense to use here?

IMAP servers are different as you normally have an account on them and they are not the same for all users on this network segment, SMTP servers may be the same.

I agree that there is a dividing line, just not there.

And of course which other service should take the task of telling me those things? Which other server will know my whereabouts so precisely that it can hand out those informations?


On 14/10/13 20.25, Ted Lemon wrote:
During the IESG review of the DHCP Option Guidelines document, a number of issues came up, but the most contentious had to do with the question of exactly what services it makes sense to configure with DHCP.   This is an issue because the use model for one class of such services is quite different from the use model for the other class, and prospective users of DHCP to configure services of the other class therefore disputed the option document's advice on when to use FQDNs.

The dichotomy that I would like us to discuss is between network-specific services and node-specific services.

To illustrate what I mean, consider DNS.   DNS is the same everywhere (at least in principle).   If I ask a question of a DNS server on network A, and ask the same question on network B, I should get an equivalent answer; at the very least, the answer should come from the same data, and should validate with DNSSEC.   So it doesn't matter which DNS resolver I use, and indeed this matches how we use DNS.   So DNS is a network-specific service: the DNS server you use probably should be the one closest to you.

Now, consider IMAP.   If you use IMAP, you probably have one or more IMAP servers.   These servers are fixed in location.   You do not check a different IMAP server when you are at Starbucks than you do when you are at home, or at work.   So IMAP is a node-specific service—your IMAP configuration stays with your laptop or tablet, and does not change as you move from network to network.

If you look at the list of DHCPv4 options, you can find lots of IMAP-like services, and lots of DNS-like services.   I think that the DHCPv4 options for configuring node-specific services are a mistake—they are a throwback to a time when nodes didn't move around, so we weren't aware that we had a problem with the use model for DHCPv4 in configuring things like SMTP and IMAP.

At the same time, during the discussion about the Option Guidelines draft, several people raised the idea of services that are configured via DHCP, even though they are node-specific, because in certain cases that's the only option, and it makes sense to configure them that way in those cases.   For instance, a desktop SIP phone might get its initial SIP configuration over DHCP, and then not use DHCP to get SIP configuration anymore.

I am going to make a claim, and I would like the working group to tell me whether they agree with or disagree with this claim.   My claim is that DHCP doesn't make sense for configuring node-specific services.   There may be edge cases where a node-specific service can be configured using DHCP, but DHCP isn't the right service to be used in this case—it's used in this case because there is no better alternative, not because DHCP is a good alternative.   And while there may be edge cases where configuring a particular node-specific service using DHCP makes sense, there will be many more cases where using DHCP to configure that same service would not only not work, but would probably create serious security vulnerabilities.

Thoughts?
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------000000010708000000090602-- From Ted.Lemon@nominum.com Mon Oct 14 12:10:17 2013 Return-Path: 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 26BCC21F9B0D for ; Mon, 14 Oct 2013 12:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 lcoFZLVVLHZp for ; Mon, 14 Oct 2013 12:10:10 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 248A911E816D for ; Mon, 14 Oct 2013 12:10:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUlxBke3kYF6Xv0qP2BSX9D/INo/DTNbc@postini.com; Mon, 14 Oct 2013 12:10:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 848A61B82DE for ; Mon, 14 Oct 2013 12:10:09 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 64BD4190043; Mon, 14 Oct 2013 12:10:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Oct 2013 12:10:09 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <525C3FA0.5010003@s-carlsen.dk> Date: Mon, 14 Oct 2013 15:10:07 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> <525C3FA0.5010003@s-carlsen.dk> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 19:10:17 -0000 On Oct 14, 2013, at 3:01 PM, Sten Carlsen wrote: > I don't agree, certain node specific services are being set by DHCP = and should continue to be so. Examples are routers and DNS servers. Sten, could you go back and re-read what I wrote, because I said those = are network-specific, not node-specific, so if you think I was arguing = the opposite, either I expressed myself poorly, or you misread what I = said. DNS and routers are network-specific, not node-specific. IMAP and SMTP = are node-specific, not network-specific. From stenc@s-carlsen.dk Mon Oct 14 17:23:42 2013 Return-Path: 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 A9D6921E8137 for ; Mon, 14 Oct 2013 17:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 bmto0YZmx26s for ; Mon, 14 Oct 2013 17:23:41 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6BC21F9DFB for ; Mon, 14 Oct 2013 17:23:39 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (silver3AirPort.s-carlsen.dk [192.168.16.203]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 60C5C31DC for ; Tue, 15 Oct 2013 02:23:37 +0200 (CEST) Message-ID: <525C8B08.5010109@s-carlsen.dk> Date: Tue, 15 Oct 2013 02:23:36 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> In-Reply-To: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> Content-Type: multipart/alternative; boundary="------------010709080603060308090600" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 00:23:42 -0000 This is a multi-part message in MIME format. --------------010709080603060308090600 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Another 0.02$/€ I have been thinking a bit longer. I still don't quite agree. I see it this way: Whatever information is depending on your location at the time of its use needs to be handed out by the ONE service that actually knows your location in the network, the service that actively hands out your address. Examples: DNS, resolvers are in most cases restricted to the local users, so you need the local copy but it will give equivalent answers wherever you are. IMAP, you have an account, so you need access to the one server that keeps your data. (simplified a bit). SIP is also very node specific, but there are two ways to look at this service: - a SIP phone that will always connect to the same service, so wherever you may be, you will always use the same service. Works sort of like a mobile phone. Example: skype. - a SIP phone that will connect via the local serivice. Works like bringing your own phone and plugging it into any outlet and using the phone service of your host. I have experienced both ways of operating. The most common example, though it does not fit the bill, is WIFI. If you get access, it will do the same wherever you are -> mostly network specific. OTOH you normally have a subscription so only the paying customer may access the node -> node specific. I may think that IF DHCP is the only way to distribute information for geographical reasons, it should be used. OR "somebody" should suggest a new set of protocols and servers - including how "it" would get the information about the client's network location from DHCP. On 14/10/13 20.25, Ted Lemon wrote: > During the IESG review of the DHCP Option Guidelines document, a number of issues came up, but the most contentious had to do with the question of exactly what services it makes sense to configure with DHCP. This is an issue because the use model for one class of such services is quite different from the use model for the other class, and prospective users of DHCP to configure services of the other class therefore disputed the option document's advice on when to use FQDNs. > > The dichotomy that I would like us to discuss is between network-specific services and node-specific services. > > To illustrate what I mean, consider DNS. DNS is the same everywhere (at least in principle). If I ask a question of a DNS server on network A, and ask the same question on network B, I should get an equivalent answer; at the very least, the answer should come from the same data, and should validate with DNSSEC. So it doesn't matter which DNS resolver I use, and indeed this matches how we use DNS. So DNS is a network-specific service: the DNS server you use probably should be the one closest to you. > > Now, consider IMAP. If you use IMAP, you probably have one or more IMAP servers. These servers are fixed in location. You do not check a different IMAP server when you are at Starbucks than you do when you are at home, or at work. So IMAP is a node-specific service—your IMAP configuration stays with your laptop or tablet, and does not change as you move from network to network. > > If you look at the list of DHCPv4 options, you can find lots of IMAP-like services, and lots of DNS-like services. I think that the DHCPv4 options for configuring node-specific services are a mistake—they are a throwback to a time when nodes didn't move around, so we weren't aware that we had a problem with the use model for DHCPv4 in configuring things like SMTP and IMAP. > > At the same time, during the discussion about the Option Guidelines draft, several people raised the idea of services that are configured via DHCP, even though they are node-specific, because in certain cases that's the only option, and it makes sense to configure them that way in those cases. For instance, a desktop SIP phone might get its initial SIP configuration over DHCP, and then not use DHCP to get SIP configuration anymore. > > I am going to make a claim, and I would like the working group to tell me whether they agree with or disagree with this claim. My claim is that DHCP doesn't make sense for configuring node-specific services. There may be edge cases where a node-specific service can be configured using DHCP, but DHCP isn't the right service to be used in this case—it's used in this case because there is no better alternative, not because DHCP is a good alternative. And while there may be edge cases where configuring a particular node-specific service using DHCP makes sense, there will be many more cases where using DHCP to configure that same service would not only not work, but would probably create serious security vulnerabilities. > > Thoughts? > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------010709080603060308090600 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Another 0.02$/€

I have been thinking a bit longer. I still don't quite agree.

I see it this way:
Whatever information is depending on your location at the time of its use needs to be handed out by the ONE service that actually knows your location in the network, the service that actively hands out your address.

Examples:
DNS, resolvers are in most cases restricted to the local users, so you need the local copy but it will give equivalent answers wherever you are.

IMAP, you have an account, so you need access to the one server that keeps your data. (simplified a bit).

SIP is also very node specific, but there are two ways to look at this service:
- a SIP phone that will always connect to the same service, so wherever you may be, you will always use the same service. Works sort of like a mobile phone. Example: skype.
- a SIP phone that will connect via the local serivice. Works like bringing your own phone and plugging it into any outlet and using the phone service of your host.

I have experienced both ways of operating.


The most common example, though it does not fit the bill, is WIFI. If you get access, it will do the same wherever you are -> mostly network specific. OTOH you normally have a subscription so only the paying customer may access the node -> node specific.

I may think that IF DHCP is the only way to distribute information for geographical reasons, it should be used. OR "somebody" should suggest a new set of protocols and servers - including how "it" would get the information about the client's network location from DHCP.

On 14/10/13 20.25, Ted Lemon wrote:
During the IESG review of the DHCP Option Guidelines document, a number of issues came up, but the most contentious had to do with the question of exactly what services it makes sense to configure with DHCP.   This is an issue because the use model for one class of such services is quite different from the use model for the other class, and prospective users of DHCP to configure services of the other class therefore disputed the option document's advice on when to use FQDNs.

The dichotomy that I would like us to discuss is between network-specific services and node-specific services.

To illustrate what I mean, consider DNS.   DNS is the same everywhere (at least in principle).   If I ask a question of a DNS server on network A, and ask the same question on network B, I should get an equivalent answer; at the very least, the answer should come from the same data, and should validate with DNSSEC.   So it doesn't matter which DNS resolver I use, and indeed this matches how we use DNS.   So DNS is a network-specific service: the DNS server you use probably should be the one closest to you.

Now, consider IMAP.   If you use IMAP, you probably have one or more IMAP servers.   These servers are fixed in location.   You do not check a different IMAP server when you are at Starbucks than you do when you are at home, or at work.   So IMAP is a node-specific service—your IMAP configuration stays with your laptop or tablet, and does not change as you move from network to network.

If you look at the list of DHCPv4 options, you can find lots of IMAP-like services, and lots of DNS-like services.   I think that the DHCPv4 options for configuring node-specific services are a mistake—they are a throwback to a time when nodes didn't move around, so we weren't aware that we had a problem with the use model for DHCPv4 in configuring things like SMTP and IMAP.

At the same time, during the discussion about the Option Guidelines draft, several people raised the idea of services that are configured via DHCP, even though they are node-specific, because in certain cases that's the only option, and it makes sense to configure them that way in those cases.   For instance, a desktop SIP phone might get its initial SIP configuration over DHCP, and then not use DHCP to get SIP configuration anymore.

I am going to make a claim, and I would like the working group to tell me whether they agree with or disagree with this claim.   My claim is that DHCP doesn't make sense for configuring node-specific services.   There may be edge cases where a node-specific service can be configured using DHCP, but DHCP isn't the right service to be used in this case—it's used in this case because there is no better alternative, not because DHCP is a good alternative.   And while there may be edge cases where configuring a particular node-specific service using DHCP makes sense, there will be many more cases where using DHCP to configure that same service would not only not work, but would probably create serious security vulnerabilities.

Thoughts?
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------010709080603060308090600-- From Ted.Lemon@nominum.com Mon Oct 14 19:01:43 2013 Return-Path: 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 DF5BC21E8094 for ; Mon, 14 Oct 2013 19:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 KvXOK7PjUKrt for ; Mon, 14 Oct 2013 19:01:37 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABF821E8087 for ; Mon, 14 Oct 2013 19:01:36 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUlyiABA60Sm/ABxS1f3dmLCj1yeEsWjL@postini.com; Mon, 14 Oct 2013 19:01:37 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 27A0D1B82CE for ; Mon, 14 Oct 2013 19:01:36 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 07069190043; Mon, 14 Oct 2013 19:01:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Oct 2013 19:01:35 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <525C8B08.5010109@s-carlsen.dk> Date: Mon, 14 Oct 2013 22:01:33 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <27497AD8-45FA-4685-82DA-431DC9787802@nominum.com> References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> <525C8B08.5010109@s-carlsen.dk> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 02:01:44 -0000 Sten, what I'm trying to get to is whether DHCP is the right solution = for these problems in the abstract. If it is the only solution that's = available now, it's perfectly understandable for people to use it in = ways that don't entirely make sense. But there has been noise made in = the IETF about solving the problem of configuring applications like IMAP = and SIP in node-specific rather than network-specific ways, and I'm = trying to get the sense of whether working group participants agree that = that's a good idea, or really think DHCP is the right way to solve that = problem and that no better solution is needed or wanted. From jiangsheng@huawei.com Mon Oct 14 19:03:00 2013 Return-Path: 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 F106421E8094 for ; Mon, 14 Oct 2013 19:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uGB6M6bX0Ze0 for ; Mon, 14 Oct 2013 19:02:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BD30C21E8084 for ; Mon, 14 Oct 2013 19:02:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZB99758; Tue, 15 Oct 2013 02:02:49 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 15 Oct 2013 03:01:58 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 15 Oct 2013 03:02:47 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0146.000; Tue, 15 Oct 2013 10:02:39 +0800 From: Sheng Jiang To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] What sorts of services does DHCP configure? Thread-Index: AQHOyQrkQEQ991LaX0ejQZk7nFFTAJn0+s3A Date: Tue, 15 Oct 2013 02:02:38 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD484BA@nkgeml512-mbx.china.huawei.com> References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> In-Reply-To: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 02:03:00 -0000 SGksIFRlZCwNCg0KSSBhbSBub3Qgc3VyZSB5b3VyIGRlZmluaXRpb24gb2Ygbm9kZS1zcGVjaWZp YyBoZXJlLiBGb3IgbWUsIGlmIHRoZSBJTUFQIGNvbmZpZ3VyYXRpb24gaGFzIG9uZSBmaXhlZCB2 YWx1ZSB3aXRoaW4gdGhlIERIQ1Agc2VydmVyIG1hbmFnZWQgZG9tYWluLCBpdCBpcyBuZXR3b3Jr LXNwZWNpZmljIGFuZCBtYXkgYmUgc3VpdGFibGUgZm9yIERIQ1AgY29uZmlndXJhdGlvbi4NCg0K SW4gbXkgZXllcywgbm9kZS1zcGVjaWZpYyBjb25maWd1cmF0aW9uIG1lYW5zIGRpZmZlcmVudCBh bW9uZyBkaWZmZXJlbnQgbm9kZSwgY2xvc2VkIHRvIHRoZSBub2RlLXN0YXRlZnVsLiBESENQIHN0 YXRlZnVsIG1vZGVsIGNvdWxkIHN1cHBvcnQgbm9kZS1zcGVjaWZpYyBjb25maWd1cmF0aW9uLiBI b3dldmVyLCBiZWNhdXNlIERIQ1AgZG9lcyBub3Qgc3VwcG9ydCB1c2VyIGF1dGhlbnRpY2F0aW9u LCBpdCBtYXkgbm90IGJlIHRoZSBiZXN0IGNob2ljZSB0byBkbyBub2RlLXNwZWNpZmljIGNvbmZp Z3VyYXRpb24uIEkgZ3Vlc3MgQUFBIHNlcnZlciBhbmQgUmFkaXVzIHByb3RvY29sIGFyZSBiZXR0 ZXIgY2hvaWNlIG92ZXIgREhDUCBmb3Igbm9kZS1zcGVjaWZpYyBjb25maWd1cmF0aW9uLg0KDQpG b3Igd2hhdCB5b3VyIGNhbGxlZCBub2RlLXNwZWNpZmljLCBJIGd1ZXNzIGl0IGlzIG1vcmUgc3Vp dGFibGUgdG8gY2FsbCBuZXR3b3JrLWluZGVwZW5kZW50IGNvbmZpZ3VyYXRpb24gYmVjYXVzZSB0 aGV5IGRvbid0IGNoYW5nZSB3aGVuIHRoZSBub2RlIGNoYW5nZXMgYXR0YWNoZWQgbmV0d29ya3M7 IG9yIEFwcGxpY2F0aW9uLXNwZWNpZmljIGNvbmZpZ3VyYXRpb24gZm9yIHRoYXQgbWFueSBleGFt cGxlcyBpbiBteSBtaW5kIGFyZSBhcHBsaWNhdGlvbiByZWxldmFudC4gTXkgY29uY2VybiBmb3Ig dGhlbSBhcmUgdHdvOiBhKSBpcyB0aGVyZSBhbnkgaGFybSB0byBkbyBpdCB0aHJvdWdoIERIQ1A7 IGIpIGlzIHRoZXJlIGJldHRlciBhbHRlcm5hdGl2ZSBvdmVyIERIQ1AuDQoNClJlZ2FyZHMsDQoN ClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGRoY3dnLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5P ZiBUZWQgTGVtb24NCj5TZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE1LCAyMDEzIDI6MjYgQU0NCj5U bzogZGhjd2dAaWV0Zi5vcmcgV0cNCj5TdWJqZWN0OiBbZGhjd2ddIFdoYXQgc29ydHMgb2Ygc2Vy dmljZXMgZG9lcyBESENQIGNvbmZpZ3VyZT8NCj4NCj5EdXJpbmcgdGhlIElFU0cgcmV2aWV3IG9m IHRoZSBESENQIE9wdGlvbiBHdWlkZWxpbmVzIGRvY3VtZW50LCBhIG51bWJlciBvZg0KPmlzc3Vl cyBjYW1lIHVwLCBidXQgdGhlIG1vc3QgY29udGVudGlvdXMgaGFkIHRvIGRvIHdpdGggdGhlIHF1 ZXN0aW9uIG9mDQo+ZXhhY3RseSB3aGF0IHNlcnZpY2VzIGl0IG1ha2VzIHNlbnNlIHRvIGNvbmZp Z3VyZSB3aXRoIERIQ1AuICAgVGhpcyBpcyBhbg0KPmlzc3VlIGJlY2F1c2UgdGhlIHVzZSBtb2Rl bCBmb3Igb25lIGNsYXNzIG9mIHN1Y2ggc2VydmljZXMgaXMgcXVpdGUgZGlmZmVyZW50DQo+ZnJv bSB0aGUgdXNlIG1vZGVsIGZvciB0aGUgb3RoZXIgY2xhc3MsIGFuZCBwcm9zcGVjdGl2ZSB1c2Vy cyBvZiBESENQIHRvDQo+Y29uZmlndXJlIHNlcnZpY2VzIG9mIHRoZSBvdGhlciBjbGFzcyB0aGVy ZWZvcmUgZGlzcHV0ZWQgdGhlIG9wdGlvbg0KPmRvY3VtZW50J3MgYWR2aWNlIG9uIHdoZW4gdG8g dXNlIEZRRE5zLg0KPg0KPlRoZSBkaWNob3RvbXkgdGhhdCBJIHdvdWxkIGxpa2UgdXMgdG8gZGlz Y3VzcyBpcyBiZXR3ZWVuIG5ldHdvcmstc3BlY2lmaWMNCj5zZXJ2aWNlcyBhbmQgbm9kZS1zcGVj aWZpYyBzZXJ2aWNlcy4NCj4NCj5UbyBpbGx1c3RyYXRlIHdoYXQgSSBtZWFuLCBjb25zaWRlciBE TlMuICAgRE5TIGlzIHRoZSBzYW1lIGV2ZXJ5d2hlcmUgKGF0DQo+bGVhc3QgaW4gcHJpbmNpcGxl KS4gICBJZiBJIGFzayBhIHF1ZXN0aW9uIG9mIGEgRE5TIHNlcnZlciBvbiBuZXR3b3JrIEEsIGFu ZCBhc2sNCj50aGUgc2FtZSBxdWVzdGlvbiBvbiBuZXR3b3JrIEIsIEkgc2hvdWxkIGdldCBhbiBl cXVpdmFsZW50IGFuc3dlcjsgYXQgdGhlDQo+dmVyeSBsZWFzdCwgdGhlIGFuc3dlciBzaG91bGQg Y29tZSBmcm9tIHRoZSBzYW1lIGRhdGEsIGFuZCBzaG91bGQgdmFsaWRhdGUNCj53aXRoIEROU1NF Qy4gICBTbyBpdCBkb2Vzbid0IG1hdHRlciB3aGljaCBETlMgcmVzb2x2ZXIgSSB1c2UsIGFuZCBp bmRlZWQNCj50aGlzIG1hdGNoZXMgaG93IHdlIHVzZSBETlMuICAgU28gRE5TIGlzIGEgbmV0d29y ay1zcGVjaWZpYyBzZXJ2aWNlOiB0aGUNCj5ETlMgc2VydmVyIHlvdSB1c2UgcHJvYmFibHkgc2hv dWxkIGJlIHRoZSBvbmUgY2xvc2VzdCB0byB5b3UuDQo+DQo+Tm93LCBjb25zaWRlciBJTUFQLiAg IElmIHlvdSB1c2UgSU1BUCwgeW91IHByb2JhYmx5IGhhdmUgb25lIG9yIG1vcmUNCj5JTUFQIHNl cnZlcnMuICAgVGhlc2Ugc2VydmVycyBhcmUgZml4ZWQgaW4gbG9jYXRpb24uICAgWW91IGRvIG5v dCBjaGVjayBhDQo+ZGlmZmVyZW50IElNQVAgc2VydmVyIHdoZW4geW91IGFyZSBhdCBTdGFyYnVj a3MgdGhhbiB5b3UgZG8gd2hlbiB5b3UgYXJlIGF0DQo+aG9tZSwgb3IgYXQgd29yay4gICBTbyBJ TUFQIGlzIGEgbm9kZS1zcGVjaWZpYyBzZXJ2aWNl4oCUeW91ciBJTUFQDQo+Y29uZmlndXJhdGlv biBzdGF5cyB3aXRoIHlvdXIgbGFwdG9wIG9yIHRhYmxldCwgYW5kIGRvZXMgbm90IGNoYW5nZSBh cyB5b3UNCj5tb3ZlIGZyb20gbmV0d29yayB0byBuZXR3b3JrLg0KPg0KPklmIHlvdSBsb29rIGF0 IHRoZSBsaXN0IG9mIERIQ1B2NCBvcHRpb25zLCB5b3UgY2FuIGZpbmQgbG90cyBvZiBJTUFQLWxp a2UNCj5zZXJ2aWNlcywgYW5kIGxvdHMgb2YgRE5TLWxpa2Ugc2VydmljZXMuICAgSSB0aGluayB0 aGF0IHRoZSBESENQdjQgb3B0aW9ucyBmb3INCj5jb25maWd1cmluZyBub2RlLXNwZWNpZmljIHNl cnZpY2VzIGFyZSBhIG1pc3Rha2XigJR0aGV5IGFyZSBhIHRocm93YmFjayB0byBhDQo+dGltZSB3 aGVuIG5vZGVzIGRpZG4ndCBtb3ZlIGFyb3VuZCwgc28gd2Ugd2VyZW4ndCBhd2FyZSB0aGF0IHdl IGhhZCBhDQo+cHJvYmxlbSB3aXRoIHRoZSB1c2UgbW9kZWwgZm9yIERIQ1B2NCBpbiBjb25maWd1 cmluZyB0aGluZ3MgbGlrZSBTTVRQIGFuZA0KPklNQVAuDQo+DQo+QXQgdGhlIHNhbWUgdGltZSwg ZHVyaW5nIHRoZSBkaXNjdXNzaW9uIGFib3V0IHRoZSBPcHRpb24gR3VpZGVsaW5lcyBkcmFmdCwN Cj5zZXZlcmFsIHBlb3BsZSByYWlzZWQgdGhlIGlkZWEgb2Ygc2VydmljZXMgdGhhdCBhcmUgY29u ZmlndXJlZCB2aWEgREhDUCwgZXZlbg0KPnRob3VnaCB0aGV5IGFyZSBub2RlLXNwZWNpZmljLCBi ZWNhdXNlIGluIGNlcnRhaW4gY2FzZXMgdGhhdCdzIHRoZSBvbmx5IG9wdGlvbiwNCj5hbmQgaXQg bWFrZXMgc2Vuc2UgdG8gY29uZmlndXJlIHRoZW0gdGhhdCB3YXkgaW4gdGhvc2UgY2FzZXMuICAg Rm9yIGluc3RhbmNlLA0KPmEgZGVza3RvcCBTSVAgcGhvbmUgbWlnaHQgZ2V0IGl0cyBpbml0aWFs IFNJUCBjb25maWd1cmF0aW9uIG92ZXIgREhDUCwgYW5kIHRoZW4NCj5ub3QgdXNlIERIQ1AgdG8g Z2V0IFNJUCBjb25maWd1cmF0aW9uIGFueW1vcmUuDQo+DQo+SSBhbSBnb2luZyB0byBtYWtlIGEg Y2xhaW0sIGFuZCBJIHdvdWxkIGxpa2UgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gdGVsbCBtZQ0KPndo ZXRoZXIgdGhleSBhZ3JlZSB3aXRoIG9yIGRpc2FncmVlIHdpdGggdGhpcyBjbGFpbS4gICBNeSBj bGFpbSBpcyB0aGF0IERIQ1ANCj5kb2Vzbid0IG1ha2Ugc2Vuc2UgZm9yIGNvbmZpZ3VyaW5nIG5v ZGUtc3BlY2lmaWMgc2VydmljZXMuICAgVGhlcmUgbWF5IGJlDQo+ZWRnZSBjYXNlcyB3aGVyZSBh IG5vZGUtc3BlY2lmaWMgc2VydmljZSBjYW4gYmUgY29uZmlndXJlZCB1c2luZyBESENQLCBidXQN Cj5ESENQIGlzbid0IHRoZSByaWdodCBzZXJ2aWNlIHRvIGJlIHVzZWQgaW4gdGhpcyBjYXNl4oCU aXQncyB1c2VkIGluIHRoaXMgY2FzZQ0KPmJlY2F1c2UgdGhlcmUgaXMgbm8gYmV0dGVyIGFsdGVy bmF0aXZlLCBub3QgYmVjYXVzZSBESENQIGlzIGEgZ29vZCBhbHRlcm5hdGl2ZS4NCj5BbmQgd2hp bGUgdGhlcmUgbWF5IGJlIGVkZ2UgY2FzZXMgd2hlcmUgY29uZmlndXJpbmcgYSBwYXJ0aWN1bGFy DQo+bm9kZS1zcGVjaWZpYyBzZXJ2aWNlIHVzaW5nIERIQ1AgbWFrZXMgc2Vuc2UsIHRoZXJlIHdp bGwgYmUgbWFueSBtb3JlIGNhc2VzDQo+d2hlcmUgdXNpbmcgREhDUCB0byBjb25maWd1cmUgdGhh dCBzYW1lIHNlcnZpY2Ugd291bGQgbm90IG9ubHkgbm90IHdvcmssDQo+YnV0IHdvdWxkIHByb2Jh Ymx5IGNyZWF0ZSBzZXJpb3VzIHNlY3VyaXR5IHZ1bG5lcmFiaWxpdGllcy4NCj4NCj5UaG91Z2h0 cz8NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmRo Y3dnIG1haWxpbmcgbGlzdA0KPmRoY3dnQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaGN3Zw0K From mellon@fugue.com Mon Oct 14 19:09:02 2013 Return-Path: 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 A8BCD21E8087 for ; Mon, 14 Oct 2013 19:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 rqh-FIETBxMs for ; Mon, 14 Oct 2013 19:08:56 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id ED76821E809D for ; Mon, 14 Oct 2013 19:08:49 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 5B4FE238033F; Mon, 14 Oct 2013 22:08:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AD484BA@nkgeml512-mbx.china.huawei.com> Date: Mon, 14 Oct 2013 22:08:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AD484BA@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1812) Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 02:09:02 -0000 On Oct 14, 2013, at 10:02 PM, Sheng Jiang wrote: > I am not sure your definition of node-specific here. For me, if the = IMAP configuration has one fixed value within the DHCP server managed = domain, it is network-specific and may be suitable for DHCP = configuration. That's a pretty big if. How would the node know? How would it = securely reject IMAP configurations that would be harmful? > For what your called node-specific, I guess it is more suitable to = call network-independent configuration because they don't change when = the node changes attached networks; or Application-specific = configuration for that many examples in my mind are application = relevant. My concern for them are two: a) is there any harm to do it = through DHCP; b) is there better alternative over DHCP. I think network-independent is not a bad idea, although maybe = network-location-independent is more clear, since of course all of the = things we are talking about are dependent on the network. I agree with = you that (a) and (b) are good questions to ask. From jiangsheng@huawei.com Mon Oct 14 19:33:30 2013 Return-Path: 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 9BAA511E8167 for ; Mon, 14 Oct 2013 19:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 iY6HPzNEbd8n for ; Mon, 14 Oct 2013 19:33:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A456711E8168 for ; Mon, 14 Oct 2013 19:33:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZC01168; Tue, 15 Oct 2013 02:33:20 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 15 Oct 2013 03:32:30 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 15 Oct 2013 03:33:19 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0146.000; Tue, 15 Oct 2013 10:33:12 +0800 From: Sheng Jiang To: Ted Lemon Thread-Topic: [dhcwg] What sorts of services does DHCP configure? Thread-Index: AQHOyQrkQEQ991LaX0ejQZk7nFFTAJn0+s3A//+D9YCAAIjoAA== Date: Tue, 15 Oct 2013 02:33:10 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD48532@nkgeml512-mbx.china.huawei.com> References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AD484BA@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 02:33:30 -0000 Pk9uIE9jdCAxNCwgMjAxMywgYXQgMTA6MDIgUE0sIFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1 YXdlaS5jb20+IHdyb3RlOg0KPj4gSSBhbSBub3Qgc3VyZSB5b3VyIGRlZmluaXRpb24gb2Ygbm9k ZS1zcGVjaWZpYyBoZXJlLiBGb3IgbWUsIGlmIHRoZSBJTUFQDQo+Y29uZmlndXJhdGlvbiBoYXMg b25lIGZpeGVkIHZhbHVlIHdpdGhpbiB0aGUgREhDUCBzZXJ2ZXIgbWFuYWdlZCBkb21haW4sIGl0 DQo+aXMgbmV0d29yay1zcGVjaWZpYyBhbmQgbWF5IGJlIHN1aXRhYmxlIGZvciBESENQIGNvbmZp Z3VyYXRpb24uDQo+DQo+VGhhdCdzIGEgcHJldHR5IGJpZyBpZi4gICBIb3cgd291bGQgdGhlIG5v ZGUga25vdz8gICBIb3cgd291bGQgaXQgc2VjdXJlbHkNCj5yZWplY3QgSU1BUCBjb25maWd1cmF0 aW9ucyB0aGF0IHdvdWxkIGJlIGhhcm1mdWw/DQoNCkkgZ3Vlc3MgSSBzaG91bGQgbm90IHVzZSBJ TUFQIGNvbmZpZ3VyYXRpb24gYXMgdGhlIGV4YW1wbGUgZm9yIHRoZSBkZWZpbml0aW9uIG9mIG5l dHdvcmstc3BlY2lmaWMgaGVyZS4gSXQgbWlzLWxlYWRlZCB5b3UuIEkgYW0gbm90IHJlYWR5IHRv IGRpc2N1c3MgaW4gZGVlcCByZWdhcmRpbmcgdG8gSU1BUCBjb25maWd1cmF0aW9uLCB5ZXQuIDpQ IFRoZSBjbGFyaWZpY2F0aW9uIG9mIG15c2VsZiBzaG91bGQgYmU6IElNQVAgY29uZmlndXJhdGlv biBtYXkgYmUgY29uZmlndXJlZCB0aHJvdWdoIERIQ1Agc3RhdGVsZXNzIG1vZGVsLiBJdCBkb2Vz IG5vdCBtYXRjaCBteSB1bmRlcnN0YW5kaW5nIG9mIG5vZGUtc3BlY2lmaWMuDQoNClJlZ2FyZGlu ZyB0byB5b3VyIHF1ZXN0aW9uIG9mIGhvdyBub2RlIGJlIGFibGUgdG8gZGlzdGluZ3Vpc2ggYSBo YXJtZnVsIGNvbmZpZ3VyYXRpb24sIHVubGVzcyB0aGVyZSBpcyBhbm90aGVyIGFsdGVybmF0aXZl IG1lY2hhbmlzbSBjYW4gcHJvdmlkZSBzdWNoIGZ1bmN0aW9uLCBpdCBzaG91bGQgbm90IGluIHRo ZSBjZW50ZXIgb2Ygb3VyIGNvbmNlcm4uDQoNClJlZ2FyZHMsDQoNClNoZW5nDQo= From swmike@swm.pp.se Mon Oct 14 23:14:55 2013 Return-Path: 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 BF42F21F942D for ; Mon, 14 Oct 2013 23:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 bWR8eKSCl6C0 for ; Mon, 14 Oct 2013 23:14:55 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D980E21F9A6C for ; Mon, 14 Oct 2013 23:14:53 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 042EAA1; Tue, 15 Oct 2013 08:14:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EFF6C9C; Tue, 15 Oct 2013 08:14:50 +0200 (CEST) Date: Tue, 15 Oct 2013 08:14:50 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> Message-ID: References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1659733270-1381817690=:2685" Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 06:14:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1659733270-1381817690=:2685 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 14 Oct 2013, Ted Lemon wrote: > I am going to make a claim, and I would like the working group to tell > me whether they agree with or disagree with this claim. My claim is > that DHCP doesn't make sense for configuring node-specific services. > There may be edge cases where a node-specific service can be configured > using DHCP, but DHCP isn't the right service to be used in this > case—it's used in this case because there is no better alternative, not > because DHCP is a good alternative. And while there may be edge cases > where configuring a particular node-specific service using DHCP makes > sense, there will be many more cases where using DHCP to configure that > same service would not only not work, but would probably create serious > security vulnerabilities. I agree. In my view DHCP should be used to bootstrap stuff, give you information to be able to communicate on the network and know where to go to learn more. So outgoing non-authenticated SMTP server could go into DHCP, IMAP account information should not. SMTP server will change with location, IMAP account information does not (just as you say). So in your SIP phone example case, there should be DHCP options to tell it where to go to talk to the configuration system, and additional information it might need in order to do this. The Netconf/YANG guys are working on zeroconf draft in order to do this kind of bootstrapping, but I can imagine that there will be opposition to this method because people are used to have the DHCP client configure resolv.conf or NTP or whatever, and bringing in other methods will be uphill struggle because of added complexity. In the long run, I think a unified method is probably best though. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1659733270-1381817690=:2685-- From stenc@s-carlsen.dk Tue Oct 15 01:39:59 2013 Return-Path: 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 7101821F9E77 for ; Tue, 15 Oct 2013 01:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 ZsOsYRhaA0Dj for ; Tue, 15 Oct 2013 01:39:58 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id A375F21F9C0E for ; Tue, 15 Oct 2013 01:39:54 -0700 (PDT) Received: from silver3wired.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fefe:16ca]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id D830C2B24; Tue, 15 Oct 2013 10:39:51 +0200 (CEST) Message-ID: <525CFF57.3080506@s-carlsen.dk> Date: Tue, 15 Oct 2013 10:39:51 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ted Lemon References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> <525C8B08.5010109@s-carlsen.dk> <27497AD8-45FA-4685-82DA-431DC9787802@nominum.com> In-Reply-To: <27497AD8-45FA-4685-82DA-431DC9787802@nominum.com> Content-Type: multipart/alternative; boundary="------------010704080102060501030301" Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:39:59 -0000 This is a multi-part message in MIME format. --------------010704080102060501030301 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 15/10/13 04.01, Ted Lemon wrote: > Sten, what I'm trying to get to is whether DHCP is the right solution for these problems in the abstract. If it is the only solution that's available now, it's perfectly understandable for people to use it in ways that don't entirely make sense. But there has been noise made in the IETF about solving the problem of configuring applications like IMAP and SIP in node-specific rather than network-specific ways, and I'm trying to get the sense of whether working group participants agree that that's a good idea, or really think DHCP is the right way to solve that problem and that no better solution is needed or wanted. I do see your point, what I try to say is that there is no other system that knows your location within the network better. So either you use DHCP to hand out a "configuration server" including maybe parameters or do configurations it self. I do see that a different type of service to do all those configurations looks like a good idea, however it also means that that the management systems now will have yet another system to manage from the same database. A question: will there be many networks that only have one of the two types of server? > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------010704080102060501030301 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 15/10/13 04.01, Ted Lemon wrote:
Sten, what I'm trying to get to is whether DHCP is the right solution for these problems in the abstract. If it is the only solution that's available now, it's perfectly understandable for people to use it in ways that don't entirely make sense.   But there has been noise made in the IETF about solving the problem of configuring applications like IMAP and SIP in node-specific rather than network-specific ways, and I'm trying to get the sense of whether working group participants agree that that's a good idea, or really think DHCP is the right way to solve that problem and that no better solution is needed or wanted.
I do see your point, what I try to say is that there is no other system that knows your location within the network better. So either you use DHCP to hand out a "configuration server" including maybe parameters or do configurations it self.

I do see that a different type of service to do all those configurations looks like a good idea, however it also means that that the management systems now will have yet another system to manage from the same database.

A question: will there be many networks that only have one of the two types of server?



-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------010704080102060501030301-- From kre@munnari.OZ.AU Tue Oct 15 03:24:08 2013 Return-Path: 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 0D17611E81C7 for ; Tue, 15 Oct 2013 03:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6] 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 lSInqrcVANxv for ; Tue, 15 Oct 2013 03:24:07 -0700 (PDT) Received: from jade.coe.psu.ac.th (unknown [IPv6:2001:3c8:9009:181::2]) by ietfa.amsl.com (Postfix) with ESMTP id E897911E81C5 for ; Tue, 15 Oct 2013 03:23:51 -0700 (PDT) Received: from perseus.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9009:181::2]) by jade.coe.psu.ac.th with ESMTP id r9FAFMWA013311; Tue, 15 Oct 2013 17:15:22 +0700 (ICT) Received: from perseus.noi.kre.to (localhost [127.0.0.1]) by perseus.noi.kre.to (8.14.7/8.14.2) with ESMTP id r9FAFIAk002355; Tue, 15 Oct 2013 17:15:18 +0700 (ICT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.5 From: Robert Elz To: Ted Lemon In-Reply-To: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Oct 2013 17:15:18 +0700 Message-ID: <3156.1381832118@perseus.noi.kre.to> Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 10:24:08 -0000 Since you're asking a largely philosophical question, you'll get a mostly philosophical answer from me - which will start from looking at what we can tell of the protocol now - partly from usage (but that doesn't help a lot for this purpose, as, as you say, it has all kinds of crud jammed in) but also from the more simple aspect of its name... The Dynamic Host Configuration Protocol ... a protocol for configuring hosts (dynamically, as in not necessarily with static configuration, but that part isn't relevant to your question I don't think.) What is, is "host" - as in "node that is not a router" (though I don't see any particular reason DHCP couldn't be used to configure routers as well). Just based upon this, attempting to redefine DHCP as a network configuration protocol, leaving the node configuration for some unspecified something else looks like it would be backwards. Next comment is your concentration on "services" being configured. I think I know why that is - because if you allowed other node specific information to get bundled in with the ones that are a problem for you, then this would be obvious nonsense - other node specific information that gets configured include its address (and OK, that's also network specific) and the hostname (which isn't, or shouldn't be). Attempt to tell people that DHCP shouldn't be configuring hostnames (ever) and I doubt you'd get many supporters. What DHCP offers is information - it doesn't configure services, it just provides raw data that something else can use to configure the service. Sometimes that distinction is important. As an example, DHCP (on unix systems) doesn't configure resolv.conf - what it does is get s alist of DNS back end resolvers and make that data available. Something else (true, usually run triggered by the DHCP client's actions) takes that data and (sometimes) puts it in resolv.conf (on other systems it goes into a "forwarder" config in named.boot or something included from that). That said, the examples you picked were both particularly poor choices - SMTP isn't, as for me at least, I prefer that configured just the way you explain configuring the DNS resolver, as a local network specific service - I just want the nearest MTA that will be willing to take my mail and deliver it. The nearer the better, as it increases the chances that I'll be able to contact it to hand off the e-mail even in the presence of severe network disruptions. Of course, I know that others treat SMTP as kind of an inverse IMAP, where there needs to be an existing relationship (and security config) between client and server ... IMAP on the other hand (or POP if anyone is still using that) is not a good example of what you're asking for an entirely different reason .. of course, it may be that this causes you to rephrase your question/opinion in a different way. IMAP isn't a node specific service at all, it is a user specific service. You only view it as a node specific service if you have the impression of a very tight (almost unbreakable) bond between node and user, that is fairly common these days. But consider the case of a shared office notebook, that anyone picks up (one from the pile) and takes away to use for a few days, returning it when they're done? Should the IMAP configuration be node specific, or user specific? Since when DHCP normally runs (at least initially) the identity of the user won't always be known, DHCP at first glance doesn't look to be a good fit for configuring services that are user specific, and need the user's credentials to be able to determine the proper response - as distinct from true node configuration (independent of the user). But, I know that you're not proposing that all of this stuff go unconfigured, or that we revert to the bad old days, of users attempting to follow the configuration manual in conjunction with some configuration information provideed (via a phone call, on a web page, in e-mail, or even printed) from whatever network info center the user is supposed to get that particular information from. That means that we need some kind of a config protocol. What's more it needs to be a protocol that works starting with a 100% unconfigured node - and some information for that node (and/or the node's user) somewhere in the network. What is the protocol that allows the node to discover where that information is to be found going to look like, and is it (really) going to be anything significantly different from DHCP ? For (some) shared info, we can adopt the IPv6 model (in fact, we should probably only really be considering IPv6 - doing much more work on IPv4 is really just painful palliative care for an obviously doomed protocol) and broadcast (that is, of course, multicast) the config. That works quite well when the same info is appropriate for all nodes that will receive the broadcast (like the DNS resolver and router locations). What that leaves for DHCP, or some DHCP like protocol, is the information that is meant to be unique for each node (hostnames, even IMAP servers ...) Consider a node that has obtained the user identity information from its user (which may be simply known at boot time for a node that is tightly bound to a specific user, or later, after the user has been identified and authenticated in other cases) then sending those credentials to the DHCP server in a DHCP request option, and for the DHCP server to then reply with node and user specific information - which it may have obtained by consulting with a radius (or other AAA) server and hence supply this particular user's correct IMAP (and other similar) configuration? Whether that's the right solution or not I don't know, but I do believe that whatever solution is eventually adopted, it needs to start with making node & user specific information available to a 100% unconfigured node, without any user assistance (some nodes may not even have a mechanism for to user to assist, even if they were able) and I'm having trouble seeing how any solution is going to be so dramatically different from DHCP that simply using DHCP as (at least a part of) the resulting protocol wouldn't be a sane result. Consequently, I don't think it is a good idea now to start on the divorce proceedings between these kinds of config info and DHCP, simply writing it off as a problem for someone else to solve - and while the way that DHCP is currently defined (and more importantly in many cases perhaps, configured) to provide this info may be sub-optimal, we may want to see if we can find an amicable reconciliation. kre From mellon@fugue.com Tue Oct 15 06:15:27 2013 Return-Path: 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 9DD3411E818B for ; Tue, 15 Oct 2013 06:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 rMUShRAojJ16 for ; Tue, 15 Oct 2013 06:15:21 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2D77121F9FF9 for ; Tue, 15 Oct 2013 06:15:21 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 5728F23805B3; Tue, 15 Oct 2013 09:15:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AD48532@nkgeml512-mbx.china.huawei.com> Date: Tue, 15 Oct 2013 09:15:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <281049A9-3C3F-48E1-8562-A2E11C31E213@fugue.com> References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923AD484BA@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AD48532@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1812) Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 13:15:27 -0000 On Oct 14, 2013, at 10:33 PM, Sheng Jiang wrote: > I guess I should not use IMAP configuration as the example for the = definition of network-specific here. It mis-leaded you. I am not ready = to discuss in deep regarding to IMAP configuration, yet. :P The = clarification of myself should be: IMAP configuration may be configured = through DHCP stateless model. It does not match my understanding of = node-specific. I chose IMAP deliberately, because it _is_ something that is a local = network service, and that made some sense to configure using DHCP back = in the olden days when we rode around in horse-drawn buggies and used = computers that didn't fit in our pockets (and hence might roam to = different networks). > Regarding to your question of how node be able to distinguish a = harmful configuration, unless there is another alternative mechanism can = provide such function, it should not in the center of our concern. To be clear, the question I am asking ought to be answered as if such a = mechanism did exist. People have talked about creating such a = mechanism, and I think it's a good idea. If there were a mechanism for = delivering configuration information that ought not to vary as a device = moves from network to network, what services would you still want to = configure using DHCP? What services would it no longer make sense to = configure using DHCP. It's important to note that _nobody_ uses DHCP to configure IMAP or POP = or SMTP. You can't buy a device that gets these configurations from = DHCP automatically, even though DHCP provides the ability to configure = these services. Why not? Because it doesn't work. IMAP and POP are specific to the = user. You set up IMAP and POP manually. Microsoft actually has a = proprietary protocol for configuring Exchange based on your email = address. There are some services where it _sometimes_ works for DHCP to be what = configures it. There are some services where it _obviously_ works for = DHCP to configure it. There are some services where it _never_ makes = sense for DHCP to configure it. This is what I'm getting at. I'd = like to try to get some clarity on how we can predict which services, = even if we added a DHCP option to support them, would never be = configured by DHCP, which would be configured by DHCP only in restricted = cases, and which would almost always be configured by DHCP. I would also like us to discuss the security implications of configuring = these services via DHCP. E.g., if you configure SMTP via DHCP and = start sending mail out the SMTP server you got from DHCP, isn't spam = filtering going to cause your mail to bounce? If you configure SIP = using DHCP, aren't you going to wind up exposing yourself to = eavesdropping when you use a SIP server without any secure mechanism for = determining who operates it?= From repenno@cisco.com Tue Oct 15 06:41:29 2013 Return-Path: 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 3AE1D21E80BB for ; Tue, 15 Oct 2013 06:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 22kvp8S4+tHN for ; Tue, 15 Oct 2013 06:41:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFFF21E80B8 for ; Tue, 15 Oct 2013 06:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3567; q=dns/txt; s=iport; t=1381844482; x=1383054082; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=14w94tn8Prki+0KX8geFi/6NO/I8uPH44XNthvt0gWg=; b=Fe1TC4A8f54jaD/0h2eyFIWrJo6PZCyabFh5xvzYDf8ipbx2M8VoYZVZ lHVskvaOgz8dTJK8xIqALGJ8hXsVn73QYkBwnCjKZsMe2wJqRQK7Vz++N 41RiEYni4v7iXsuAnrHczKaMRFNm07mFj0HmZ+FOueFIpbdNQVsvELzzP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFALlFXVKtJV2c/2dsb2JhbABagwc4UsIjgSIWdIIlAQEBBAEBATc0CxIBCA4KChQ3CyUCBAENBQiHfgy9GwSOAAEQgQgxB4MfgQYDk2WWIYMkgXA5 X-IronPort-AV: E=Sophos;i="4.93,499,1378857600"; d="scan'208";a="272309253" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 15 Oct 2013 13:41:20 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9FDfKY2002730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 13:41:20 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 08:41:20 -0500 From: "Reinaldo Penno (repenno)" To: Ted Lemon , Sheng Jiang Thread-Topic: [dhcwg] What sorts of services does DHCP configure? Thread-Index: AQHOyQrfiAXKk6KM3ESJzga2BnKmuZn1VvoAgAABtoCAAAbSAIAAs2QA//+R8YA= Date: Tue, 15 Oct 2013 13:41:19 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B733790@xmb-rcd-x04.cisco.com> In-Reply-To: <281049A9-3C3F-48E1-8562-A2E11C31E213@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.76.64] Content-Type: text/plain; charset="us-ascii" Content-ID: <7621640A69301E449C2D611CB9545D69@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 13:41:29 -0000 Hi, Would it make sense to determine which DHCP options are used today in wild and reasoning behind them? I have done a few captures before and noticed that DHCP options vary between home, Hotel, Hotspot, Airport, etc. As far as your SIP example below, I see SIP server through DHCP just as a discovery step. Your SIP client should apply whatever security policies to accept or not that SIP Server. Thanks, Reinaldo On 10/15/13 6:15 AM, "Ted Lemon" wrote: >On Oct 14, 2013, at 10:33 PM, Sheng Jiang wrote: >> I guess I should not use IMAP configuration as the example for the >>definition of network-specific here. It mis-leaded you. I am not ready >>to discuss in deep regarding to IMAP configuration, yet. :P The >>clarification of myself should be: IMAP configuration may be configured >>through DHCP stateless model. It does not match my understanding of >>node-specific. > >I chose IMAP deliberately, because it _is_ something that is a local >network service, and that made some sense to configure using DHCP back in >the olden days when we rode around in horse-drawn buggies and used >computers that didn't fit in our pockets (and hence might roam to >different networks). > >> Regarding to your question of how node be able to distinguish a harmful >>configuration, unless there is another alternative mechanism can provide >>such function, it should not in the center of our concern. > >To be clear, the question I am asking ought to be answered as if such a >mechanism did exist. People have talked about creating such a >mechanism, and I think it's a good idea. If there were a mechanism for >delivering configuration information that ought not to vary as a device >moves from network to network, what services would you still want to >configure using DHCP? What services would it no longer make sense to >configure using DHCP. > >It's important to note that _nobody_ uses DHCP to configure IMAP or POP >or SMTP. You can't buy a device that gets these configurations from >DHCP automatically, even though DHCP provides the ability to configure >these services. > >Why not? Because it doesn't work. IMAP and POP are specific to the >user. You set up IMAP and POP manually. Microsoft actually has a >proprietary protocol for configuring Exchange based on your email address. > >There are some services where it _sometimes_ works for DHCP to be what >configures it. There are some services where it _obviously_ works for >DHCP to configure it. There are some services where it _never_ makes >sense for DHCP to configure it. This is what I'm getting at. I'd like >to try to get some clarity on how we can predict which services, even if >we added a DHCP option to support them, would never be configured by >DHCP, which would be configured by DHCP only in restricted cases, and >which would almost always be configured by DHCP. > >I would also like us to discuss the security implications of configuring >these services via DHCP. E.g., if you configure SMTP via DHCP and start >sending mail out the SMTP server you got from DHCP, isn't spam filtering >going to cause your mail to bounce? If you configure SIP using DHCP, >aren't you going to wind up exposing yourself to eavesdropping when you >use a SIP server without any secure mechanism for determining who >operates it? >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From mellon@fugue.com Tue Oct 15 07:14:29 2013 Return-Path: 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 1D3F911E8128 for ; Tue, 15 Oct 2013 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 rZKlgpojBAkF for ; Tue, 15 Oct 2013 07:14:23 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 753E211E8121 for ; Tue, 15 Oct 2013 07:14:20 -0700 (PDT) Received: from [IPv6:2001:470:88a3::b89c:175c:85c:2515] (unknown [IPv6:2001:470:88a3:0:b89c:175c:85c:2515]) by toccata.fugue.com (Postfix) with ESMTPSA id CAFE923805B3; Tue, 15 Oct 2013 10:14:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B733790@xmb-rcd-x04.cisco.com> Date: Tue, 15 Oct 2013 10:14:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <468A1C46-7425-4499-BBF2-50EED2DBD248@fugue.com> References: <45A697A8FFD7CF48BCF2BE7E106F06040B733790@xmb-rcd-x04.cisco.com> To: Reinaldo Penno X-Mailer: Apple Mail (2.1812) Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:14:29 -0000 On Oct 15, 2013, at 9:41 AM, Reinaldo Penno (repenno) = wrote: > Would it make sense to determine which DHCP options are used today in = wild > and reasoning behind them? >=20 > I have done a few captures before and noticed that DHCP options vary > between home, Hotel, Hotspot, Airport, etc. It can't hurt to ask this question, but I'm not convinced that it's = necessary. DHCP clients don't use options they don't request, so it = doesn't matter if the server sends them. So it's probably not = necessary to survey DHCP servers=97just survey DHCP clients and see what = options they request. > As far as your SIP example below, I see SIP server through DHCP just = as a > discovery step. Your SIP client should apply whatever security = policies to > accept or not that SIP Server. Right, but going a little farther into your example, this only works for = clients that (a) request the SIP option and (b) have some way of = validating the response they get back. So we can have a very clear = discussion about this security model, and also possibly ask whether = existing clients actually do this, and whether this is a good idea, or = just the best we could do with what services are available. And then this question can be asked about lots of other services as = well. E.g., does it make sense to configure NTP this way, given that = NTP provides replay protection for security protocols (that's a = complicated question)? Does it make sense to configure SMTP this way, = given that SMTP servers are no longer really interchangeable as they = were in the early days of the Internet? POP? IMAP? Etc. From repenno@cisco.com Tue Oct 15 07:45:12 2013 Return-Path: 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 E5B4721E80BB for ; Tue, 15 Oct 2013 07:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lhT1NT274OIT for ; Tue, 15 Oct 2013 07:45:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0094F21F9D0E for ; Tue, 15 Oct 2013 07:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2053; q=dns/txt; s=iport; t=1381848300; x=1383057900; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9WLHFtnG2MDHRxLGaWxaSZgiIRxn9aJ0ckbLej5XfUA=; b=a93dKTMcjYzUB1FxQ8WhbZ1N+iSEx3bNU+bHtPIeuYS9bvzlHOkqJLpq MeWV7/i9i5qnP7eWoWPNpbBO8su0umGbXNF+YNV9a+humTWGOEEE8aJaD 9f4XhHz1FZ/WXzvxXwRNKYZ3veBIN6Gz6RxpajCvWj+LIzHxdoKhBTgiO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFANRTXVKtJXG+/2dsb2JhbABagwc4UsFaS4EgFnSCJQEBAQMBGGESAQgOFFYlAgQOBQiHeAYMvSqPFwIxB4MfgQYDmTOQU4MkgWkkHA X-IronPort-AV: E=Sophos;i="4.93,499,1378857600"; d="scan'208";a="272324481" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2013 14:44:59 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9FEixVf012719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 14:44:59 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; Tue, 15 Oct 2013 09:44:59 -0500 From: "Reinaldo Penno (repenno)" To: Ted Lemon Thread-Topic: [dhcwg] What sorts of services does DHCP configure? Thread-Index: AQHOyQrfiAXKk6KM3ESJzga2BnKmuZn1VvoAgAABtoCAAAbSAIAAs2QA//+R8YCAAH6KgP//kz6A Date: Tue, 15 Oct 2013 14:44:58 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B7337D7@xmb-rcd-x04.cisco.com> In-Reply-To: <468A1C46-7425-4499-BBF2-50EED2DBD248@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.69.5] Content-Type: text/plain; charset="Windows-1252" Content-ID: <56BC7D284D774D4FBCB5C148B9B7A1AC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:45:12 -0000 On 10/15/13 7:14 AM, "Ted Lemon" wrote: >On Oct 15, 2013, at 9:41 AM, Reinaldo Penno (repenno) >wrote: >> Would it make sense to determine which DHCP options are used today in >>wild >> and reasoning behind them? >>=20 >> I have done a few captures before and noticed that DHCP options vary >> between home, Hotel, Hotspot, Airport, etc. > >It can't hurt to ask this question, but I'm not convinced that it's >necessary. DHCP clients don't use options they don't request, so it >doesn't matter if the server sends them. So it's probably not necessary >to survey DHCP servers=8Bjust survey DHCP clients and see what options the= y >request. Right, DHCP clients. certain OSs allows applications to ask for certain DHCP options. http://msdn.microsoft.com/en-us/library/windows/desktop/aa363298%28v=3Dvs.8= 5% 29.aspx > >> As far as your SIP example below, I see SIP server through DHCP just as >>a >> discovery step. Your SIP client should apply whatever security policies >>to >> accept or not that SIP Server. > >Right, but going a little farther into your example, this only works for >clients that=20 "Clients" here can be an application as above, not necessarily a DHCP client that triggers everything. >(a) request the SIP option and (b) have some way of validating the >response they get back. So we can have a very clear discussion about >this security model, and also possibly ask whether existing clients >actually do this, and whether this is a good idea, or just the best we >could do with what services are available. > >And then this question can be asked about lots of other services as well. > E.g., does it make sense to configure NTP this way, given that NTP >provides replay protection for security protocols (that's a complicated >question)? Does it make sense to configure SMTP this way, given that >SMTP servers are no longer really interchangeable as they were in the >early days of the Internet? POP? IMAP? Etc. > From mellon@fugue.com Tue Oct 15 08:26:01 2013 Return-Path: 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 546E921E80C4 for ; Tue, 15 Oct 2013 08:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Cf0NDDlsei8G for ; Tue, 15 Oct 2013 08:25:55 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 920FB21E80C0 for ; Tue, 15 Oct 2013 08:25:55 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id BA84223805B3; Tue, 15 Oct 2013 11:25:53 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B7337D7@xmb-rcd-x04.cisco.com> Date: Tue, 15 Oct 2013 11:25:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45A697A8FFD7CF48BCF2BE7E106F06040B7337D7@xmb-rcd-x04.cisco.com> To: Reinaldo Penno X-Mailer: Apple Mail (2.1812) Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:26:01 -0000 On Oct 15, 2013, at 10:44 AM, Reinaldo Penno (repenno) = wrote: > certain OSs allows applications to ask for certain DHCP options. >=20 > = http://msdn.microsoft.com/en-us/library/windows/desktop/aa363298%28v=3Dvs.= 85% > 29.aspx Yup. And in that case, we should see the option on the DHCP parameter = request list. It would be interesting to know what clients rely on = this behavior. From stenc@s-carlsen.dk Tue Oct 15 08:38:24 2013 Return-Path: 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 916F921E8102 for ; Tue, 15 Oct 2013 08:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001] 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 yTQPQWpBZ-Qs for ; Tue, 15 Oct 2013 08:38:23 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 52D5921E814C for ; Tue, 15 Oct 2013 08:38:21 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 4C47531F5 for ; Tue, 15 Oct 2013 17:38:19 +0200 (CEST) Message-ID: <525D616B.6060805@s-carlsen.dk> Date: Tue, 15 Oct 2013 17:38:19 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: dhcwg@ietf.org References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> <3156.1381832118@perseus.noi.kre.to> In-Reply-To: <3156.1381832118@perseus.noi.kre.to> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------000402030101060108000007" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:38:24 -0000 This is a multi-part message in MIME format. --------------000402030101060108000007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You do have a point in bringing the user into this. I suggest to focus on looking at services and servers in three groups: - location agnostic, DNS is an example. - location specific, router is an example - user dependent, IMAP is an example I think only those that are not user specific should be provided by DHCP. Next question is of course whether hosts actually request and use these. On 15/10/13 12:15, Robert Elz wrote: > Since you're asking a largely philosophical question, you'll get a mostly > philosophical answer from me - which will start from looking at what > we can tell of the protocol now - partly from usage (but that doesn't > help a lot for this purpose, as, as you say, it has all kinds of crud jammed > in) but also from the more simple aspect of its name... > > The Dynamic Host Configuration Protocol ... a protocol for configuring > hosts (dynamically, as in not necessarily with static configuration, but > that part isn't relevant to your question I don't think.) > > What is, is "host" - as in "node that is not a router" (though I don't see > any particular reason DHCP couldn't be used to configure routers as well). > > Just based upon this, attempting to redefine DHCP as a network configuration > protocol, leaving the node configuration for some unspecified something else > looks like it would be backwards. > > Next comment is your concentration on "services" being configured. I think > I know why that is - because if you allowed other node specific information > to get bundled in with the ones that are a problem for you, then this would > be obvious nonsense - other node specific information that gets configured > include its address (and OK, that's also network specific) and the hostname > (which isn't, or shouldn't be). Attempt to tell people that DHCP shouldn't > be configuring hostnames (ever) and I doubt you'd get many supporters. > > What DHCP offers is information - it doesn't configure services, it just > provides raw data that something else can use to configure the service. > Sometimes that distinction is important. As an example, DHCP (on unix > systems) doesn't configure resolv.conf - what it does is get s alist of > DNS back end resolvers and make that data available. Something else > (true, usually run triggered by the DHCP client's actions) takes that > data and (sometimes) puts it in resolv.conf (on other systems it goes into > a "forwarder" config in named.boot or something included from that). > > That said, the examples you picked were both particularly poor choices - SMTP > isn't, as for me at least, I prefer that configured just the way you explain > configuring the DNS resolver, as a local network specific service - I just want > the nearest MTA that will be willing to take my mail and deliver it. > The nearer the better, as it increases the chances that I'll be able to > contact it to hand off the e-mail even in the presence of severe network > disruptions. Of course, I know that others treat SMTP as kind of an inverse > IMAP, where there needs to be an existing relationship (and security config) > between client and server ... > > IMAP on the other hand (or POP if anyone is still using that) is not a good > example of what you're asking for an entirely different reason .. of course, > it may be that this causes you to rephrase your question/opinion in a > different way. > > IMAP isn't a node specific service at all, it is a user specific service. > You only view it as a node specific service if you have the impression of > a very tight (almost unbreakable) bond between node and user, that is fairly > common these days. But consider the case of a shared office notebook, > that anyone picks up (one from the pile) and takes away to use for a few > days, returning it when they're done? Should the IMAP configuration be > node specific, or user specific? > > Since when DHCP normally runs (at least initially) the identity of the > user won't always be known, DHCP at first glance doesn't look to be a good > fit for configuring services that are user specific, and need the user's > credentials to be able to determine the proper response - as distinct from > true node configuration (independent of the user). > > But, I know that you're not proposing that all of this stuff go unconfigured, > or that we revert to the bad old days, of users attempting to follow the > configuration manual in conjunction with some configuration information > provideed (via a phone call, on a web page, in e-mail, or even printed) > from whatever network info center the user is supposed to get that particular > information from. That means that we need some kind of a config protocol. > What's more it needs to be a protocol that works starting with a 100% > unconfigured node - and some information for that node (and/or the node's > user) somewhere in the network. > > What is the protocol that allows the node to discover where that information > is to be found going to look like, and is it (really) going to be anything > significantly different from DHCP ? > > For (some) shared info, we can adopt the IPv6 model (in fact, we should > probably only really be considering IPv6 - doing much more work on IPv4 > is really just painful palliative care for an obviously doomed protocol) > and broadcast (that is, of course, multicast) the config. That works quite > well when the same info is appropriate for all nodes that will receive the > broadcast (like the DNS resolver and router locations). What that leaves > for DHCP, or some DHCP like protocol, is the information that is meant to be > unique for each node (hostnames, even IMAP servers ...) > > Consider a node that has obtained the user identity information from its > user (which may be simply known at boot time for a node that is tightly > bound to a specific user, or later, after the user has been identified and > authenticated in other cases) then sending those credentials to the DHCP > server in a DHCP request option, and for the DHCP server to then reply with > node and user specific information - which it may have obtained by > consulting with a radius (or other AAA) server and hence supply this > particular user's correct IMAP (and other similar) configuration? > > Whether that's the right solution or not I don't know, but I do believe that > whatever solution is eventually adopted, it needs to start with making > node & user specific information available to a 100% unconfigured node, > without any user assistance (some nodes may not even have a mechanism for > to user to assist, even if they were able) and I'm having trouble seeing > how any solution is going to be so dramatically different from DHCP that > simply using DHCP as (at least a part of) the resulting protocol wouldn't > be a sane result. > > Consequently, I don't think it is a good idea now to start on the divorce > proceedings between these kinds of config info and DHCP, simply writing it > off as a problem for someone else to solve - and while the way that DHCP > is currently defined (and more importantly in many cases perhaps, configured) > to provide this info may be sub-optimal, we may want to see if we can > find an amicable reconciliation. > > kre > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------000402030101060108000007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You do have a point in bringing the user into this.

I suggest to focus on looking at services and servers in three groups:
- location agnostic, DNS is an example.
- location specific, router is an example
- user dependent, IMAP is an example

I think only those that are not user specific should be provided by DHCP.

Next question is of course whether hosts actually request and use these.

On 15/10/13 12:15, Robert Elz wrote:
Since you're asking a largely philosophical question, you'll get a mostly
philosophical answer from me - which will start from looking at what
we can tell of the protocol now - partly from usage (but that doesn't
help a lot for this purpose, as, as you say, it has all kinds of crud jammed 
in) but also from the more simple aspect of its name...

The Dynamic Host Configuration Protocol ... a protocol for configuring
hosts (dynamically, as in not necessarily with static configuration, but
that part isn't relevant to your question I don't think.)

What is, is "host" - as in "node that is not a router" (though I don't see
any particular reason DHCP couldn't be used to configure routers as well).

Just based upon this, attempting to redefine DHCP as a network configuration
protocol, leaving the node configuration for some unspecified something else
looks like it would be backwards.

Next comment is your concentration on "services" being configured.  I think
I know why that is - because if you allowed other node specific information
to get bundled in with the ones that are a problem for you, then this would
be obvious nonsense - other node specific information that gets configured 
include its address (and OK, that's also network specific) and the hostname
(which isn't, or shouldn't be).   Attempt to tell people that DHCP shouldn't
be configuring hostnames (ever) and I doubt you'd get many supporters.

What DHCP offers is information - it doesn't configure services, it just
provides raw data that something else can use to configure the service.
Sometimes that distinction is important.   As an example, DHCP (on unix
systems) doesn't configure resolv.conf - what it does is get s alist of
DNS back end resolvers and make that data available.  Something else
(true, usually run triggered by the DHCP client's actions) takes that
data and (sometimes) puts it in resolv.conf (on other systems it goes into
a "forwarder" config in named.boot or something included from that).

That said, the examples you picked were both particularly poor choices - SMTP
isn't, as for me at least, I prefer that configured just the way you explain
configuring the DNS resolver, as a local network specific service - I just want
the nearest MTA that will be willing to take my mail and deliver it.
The nearer the better, as it increases the chances that I'll be able to
contact it to hand off the e-mail even in the presence of severe network
disruptions.   Of course, I know that others treat SMTP as kind of an inverse
IMAP, where there needs to be an existing relationship (and security config)
between client and server ...

IMAP on the other hand (or POP if anyone is still using that) is not a good
example of what you're asking for an entirely different reason .. of course,
it may be that this causes you to rephrase your question/opinion in a
different way.

IMAP isn't a node specific service at all, it is a user specific service.
You only view it as a node specific service if you have the impression of
a very tight (almost unbreakable) bond between node and user, that is fairly
common these days.   But consider the case of a shared office notebook,
that anyone picks up (one from the pile) and takes away to use for a few
days, returning it when they're done?   Should the IMAP configuration be
node specific, or user specific?

Since when DHCP normally runs (at least initially) the identity of the
user won't always be known, DHCP at first glance doesn't look to be a good
fit for configuring services that are user specific, and need the user's
credentials to be able to determine the proper response - as distinct from
true node configuration (independent of the user).

But, I know that you're not proposing that all of this stuff go unconfigured,
or that we revert to the bad old days, of users attempting to follow the
configuration manual in conjunction with some configuration information
provideed (via a phone call, on a web page, in e-mail, or even printed)
from whatever network info center the user is supposed to get that particular
information from.  That means that we need some kind of a config protocol.
What's more it needs to be a protocol that works starting with a 100%
unconfigured node - and some information for that node (and/or the node's
user) somewhere in the network.

What is the protocol that allows the node to discover where that information
is to be found going to look like, and is it (really) going to be anything
significantly different from DHCP ?

For (some) shared info, we can adopt the IPv6 model (in fact, we should
probably only really be considering IPv6 - doing much more work on IPv4
is really just painful palliative care for an obviously doomed protocol)
and broadcast (that is, of course, multicast) the config.  That works quite
well when the same info is appropriate for all nodes that will receive the
broadcast (like the DNS resolver and router locations).   What that leaves
for DHCP, or some DHCP like protocol, is the information that is meant to be
unique for each node (hostnames, even IMAP servers ...)

Consider a node that has obtained the user identity information from its
user (which may be simply known at boot time for a node that is tightly
bound to a specific user, or later, after the user has been identified and
authenticated in other cases) then sending those credentials to the DHCP
server in a DHCP request option, and for the DHCP server to then reply with
node and user specific information - which it may have obtained by
consulting with a radius (or other AAA) server and hence supply this
particular user's correct IMAP (and other similar) configuration?

Whether that's the right solution or not I don't know, but I do believe that
whatever solution is eventually adopted, it needs to start with making
node & user specific information available to a 100% unconfigured node,
without any user assistance (some nodes may not even have a mechanism for
to user to assist, even if they were able) and I'm having trouble seeing
how any solution is going to be so dramatically different from DHCP that
simply using DHCP as (at least a part of) the resulting protocol wouldn't
be a sane result.

Consequently, I don't think it is a good idea now to start on the divorce
proceedings between these kinds of config info and DHCP, simply writing it
off as a problem for someone else to solve - and while the way that DHCP
is currently defined (and more importantly in many cases perhaps, configured)
to provide this info may be sub-optimal, we may want to see if we can
find an amicable reconciliation.

kre

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


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------000402030101060108000007-- From Ted.Lemon@nominum.com Tue Oct 15 13:51:19 2013 Return-Path: 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 0F13121F9B85 for ; Tue, 15 Oct 2013 13:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 2u38b-HjTTJc for ; Tue, 15 Oct 2013 13:51:10 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 2234B21F9AE6 for ; Tue, 15 Oct 2013 13:51:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUl2qurkvr0h5F4rffafwAVGsAhfN6OJp@postini.com; Tue, 15 Oct 2013 13:51:07 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 75F7D1B82E2 for ; Tue, 15 Oct 2013 13:51:05 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B776E19005C; Tue, 15 Oct 2013 13:50:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Oct 2013 13:50:07 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <525CFF57.3080506@s-carlsen.dk> Date: Tue, 15 Oct 2013 16:50:05 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <00CFFD78-D4CB-4FD7-ACF4-6446D24A29CD@nominum.com> References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> <525C8B08.5010109@s-carlsen.dk> <27497AD8-45FA-4685-82DA-431DC9787802@nominum.com> <525CFF57.3080506@s-carlsen.dk> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:51:19 -0000 On Oct 15, 2013, at 4:39 AM, Sten Carlsen wrote: > I do see your point, what I try to say is that there is no other = system that knows your location within the network better. So either you = use DHCP to hand out a "configuration server" including maybe parameters = or do configurations it self. >=20 > I do see that a different type of service to do all those = configurations looks like a good idea, however it also means that that = the management systems now will have yet another system to manage from = the same database. >=20 > A question: will there be many networks that only have one of the two = types of server? Hm, I think you've hit on another question. I'm not sure it's central, = but it's worth thinking about. The SMTP server doesn't vary depending = on where in the local network topology the host is connected. The DNS = server needn't either. The router does, obviously. Can you think of = other examples? BTW, DNS servers frequently are set up with maps of the network in the = way that you describe, and indeed one of the arguments against the = advice given on FQDNs in the Option Guidelines document is that people = might want to do that, and if the DHCP server does the DNS lookup, it = won't work. From repenno@cisco.com Tue Oct 15 14:07:47 2013 Return-Path: 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 357CC21F9E1D for ; Tue, 15 Oct 2013 14:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 OeU5pXUi+4vi for ; Tue, 15 Oct 2013 14:07:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ABED921F9E11 for ; Tue, 15 Oct 2013 14:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=583; q=dns/txt; s=iport; t=1381871261; x=1383080861; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cJOOujxUkBljbB/pqJEoOC1ztY0sqXeEXTHyIGky1Io=; b=KcFEFRz3OVvQCChpq7QXDvqo2PP4Hqt3SseKjIa+3xe48NoDQpu/0bA/ PibHGw2uKH5vg6B74B+93yJn+xm/KqntVD/3Ou9UkqIDEYcZ+ow2lHRTL pyoEU99f2daCtJhjNwiQh9tIVxrMLf0umYQSVEOukjeQ7VmObi4xntrxF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAAuuXVKtJXHB/2dsb2JhbABagweBCsIqgSYWdIInAQQ6PxIBCCIUQiUCBAENBQiHfr4EjhGBCDEHgx+BBgOqBoMkgXA5 X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208";a="272482674" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 15 Oct 2013 21:07:38 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9FL7cti009155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 21:07:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 16:07:38 -0500 From: "Reinaldo Penno (repenno)" To: Ted Lemon , Sten Carlsen Thread-Topic: [dhcwg] What sorts of services does DHCP configure? Thread-Index: AQHOyQrfiAXKk6KM3ESJzga2BnKmuZn1O08AgAAbXoCAAG9IgIAAzAeA//+PjAA= Date: Tue, 15 Oct 2013 21:07:37 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B734A24@xmb-rcd-x04.cisco.com> In-Reply-To: <00CFFD78-D4CB-4FD7-ACF4-6446D24A29CD@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.126.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D2D676D4202F841A80207B241CC77B5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 21:07:47 -0000 Foreword, I'm not sure this is done through DHCP or which role it plays in determining user location. In some enterprise environments the mail server you connect (Exchange or IMAP) vary depending on your location. Same for SIP Servers, etc. You want users to connect to the closest server. On 10/15/13 1:50 PM, "Ted Lemon" wrote: >Hm, I think you've hit on another question. I'm not sure it's central, >but it's worth thinking about. The SMTP server doesn't vary depending >on where in the local network topology the host is connected.=20 From Ted.Lemon@nominum.com Tue Oct 15 14:22:47 2013 Return-Path: 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 11F7211E80DC for ; Tue, 15 Oct 2013 14:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.095 X-Spam-Level: X-Spam-Status: No, score=-106.095 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, J_BACKHAIR_34=1, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 UaLpJw6hRnFq for ; Tue, 15 Oct 2013 14:22:40 -0700 (PDT) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 81B7121F9D21 for ; Tue, 15 Oct 2013 14:22:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUl2yIO6x2kfSC9NOvsdxcgpF7NjFyIF5@postini.com; Tue, 15 Oct 2013 14:22:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0AA701B82DD for ; Tue, 15 Oct 2013 14:22:40 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 68B2019005C; Tue, 15 Oct 2013 14:22:39 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Oct 2013 14:22:39 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B734A24@xmb-rcd-x04.cisco.com> Date: Tue, 15 Oct 2013 17:22:37 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <771CAC3B-56AD-445E-AC97-75D6CB4521DB@nominum.com> References: <45A697A8FFD7CF48BCF2BE7E106F06040B734A24@xmb-rcd-x04.cisco.com> To: Reinaldo Penno X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 21:22:47 -0000 On Oct 15, 2013, at 5:07 PM, Reinaldo Penno (repenno) = wrote: > In some enterprise environments the mail server you connect (Exchange = or > IMAP) vary depending on your location. Same for SIP Servers, etc. You > want users to connect to the closest server. Can you give me any example where DHCP is the right way to solve the = problem as you have stated it? Particularly in an enterprise = environment, I am _highly_ skeptical that there is ever a case where it = makes sense to send a user to different Exchange servers as they move = around the company. SIP is a little more believable, in that I really wish my current = SIP<->POTS provider allowed me to register with the closest SIP server = rather than always being bound to the SIP server closest to my home, but = I don't see how DHCP can help me to solve this problem, since the SIP = server I would need to register with is based on my relationship to my = SIP provider, not to whoever happens to have an open WiFi for me to use = at the moment. From repenno@cisco.com Tue Oct 15 15:01:40 2013 Return-Path: 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 A78C721F9B65 for ; Tue, 15 Oct 2013 15:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_34=1, 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 m8xavh2Ya4u7 for ; Tue, 15 Oct 2013 15:01:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5154421F9B5A for ; Tue, 15 Oct 2013 15:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1389; q=dns/txt; s=iport; t=1381874490; x=1383084090; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xggrDQ0Fvp1TJsREdwWjOz+n7bZk5hyNn9DIrftz3FY=; b=iVUlC5tzT5/uun22fvqYyyH4QhujlajsnOgaCbAvywuOstQAAiyrB7ky txv9j0hZtSrTD9HRgglP6GAnZDrdiRU4bkjtfHPYiRPGwGPpNosTrLV4t c0orqYaf71tIXgP+W3PmMeErsJZXO42V2h+5NTQApNiivYttM3+5HM4LX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAHm6XVKtJV2b/2dsb2JhbABagweBCsIqgScWdIInAQQnEzgHEgEIIhRCJQIEDgUIh36+C44RgQgxB4MfgQYDqgaDJIFwOQ X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208";a="272616544" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 15 Oct 2013 22:01:27 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9FM1RGU022597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 22:01:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 17:01:26 -0500 From: "Reinaldo Penno (repenno)" To: Ted Lemon Thread-Topic: [dhcwg] What sorts of services does DHCP configure? Thread-Index: AQHOyQrfiAXKk6KM3ESJzga2BnKmuZn1O08AgAAbXoCAAG9IgIAAzAeA//+PjACAAHmLgP//lX0A Date: Tue, 15 Oct 2013 22:01:26 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B734AAC@xmb-rcd-x04.cisco.com> In-Reply-To: <771CAC3B-56AD-445E-AC97-75D6CB4521DB@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.126.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <35F88338ED83FD4FAFD291541CC83F55@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:01:40 -0000 On 10/15/13 2:22 PM, "Ted Lemon" wrote: >On Oct 15, 2013, at 5:07 PM, Reinaldo Penno (repenno) >wrote: >> In some enterprise environments the mail server you connect (Exchange or >> IMAP) vary depending on your location. Same for SIP Servers, etc. You >> want users to connect to the closest server. > >Can you give me any example where DHCP is the right way to solve the >problem as you have stated it? Right way? I can not. It might be one way, and if not DHCP something else needs to be on its place. >Particularly in an enterprise environment, I am _highly_ skeptical that >there is ever a case where it makes sense to send a user to different >Exchange servers as they move around the company. By move around I mean when I'm in Japan my iPhone connects to closest Push Server.=20 > >SIP is a little more believable, in that I really wish my current >SIP<->POTS provider allowed me to register with the closest SIP server >rather than always being bound to the SIP server closest to my home, but >I don't see how DHCP can help me to solve this problem, since the SIP >server I would need to register with is based on my relationship to my >SIP provider, not to whoever happens to have an open WiFi for me to use >at the moment. There are several SIP Servers and relays inside some companies. > From stenc@s-carlsen.dk Tue Oct 15 15:06:31 2013 Return-Path: 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 9343321F8424 for ; Tue, 15 Oct 2013 15:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_34=1, NO_RELAYS=-0.001] 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 c7LNIDWPZEfx for ; Tue, 15 Oct 2013 15:06:30 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 8391A21F9CC7 for ; Tue, 15 Oct 2013 15:06:28 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 3F9BE2A53; Wed, 16 Oct 2013 00:06:26 +0200 (CEST) Message-ID: <525DBC60.1080209@s-carlsen.dk> Date: Wed, 16 Oct 2013 00:06:24 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ted Lemon , Reinaldo Penno References: <45A697A8FFD7CF48BCF2BE7E106F06040B734A24@xmb-rcd-x04.cisco.com> <771CAC3B-56AD-445E-AC97-75D6CB4521DB@nominum.com> In-Reply-To: <771CAC3B-56AD-445E-AC97-75D6CB4521DB@nominum.com> Content-Type: multipart/alternative; boundary="------------050508050806020600010505" Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:06:31 -0000 This is a multi-part message in MIME format. --------------050508050806020600010505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 15/10/13 23.22, Ted Lemon wrote: > On Oct 15, 2013, at 5:07 PM, Reinaldo Penno (repenno) wrote: >> In some enterprise environments the mail server you connect (Exchange or >> IMAP) vary depending on your location. Same for SIP Servers, etc. You >> want users to connect to the closest server. > Can you give me any example where DHCP is the right way to solve the problem as you have stated it? Particularly in an enterprise environment, I am _highly_ skeptical that there is ever a case where it makes sense to send a user to different Exchange servers as they move around the company. Actually that is what happened in Nokia, it was not in general the DHCP that made it happen but yes, there is a good case here. Think that I normally live in Copenhagen but next day I might be in Beijing or San Diego, you really want to use the closer server and in some cases there are strict rules, maybe even laws about it (not sure which). For Exchange, the point is obviously that your mail and calendar comes from the same repository wherever you are but outgoing mail and other services may be more locally anchored. > > SIP is a little more believable, in that I really wish my current SIP<->POTS provider allowed me to register with the closest SIP server rather than always being bound to the SIP server closest to my home, but I don't see how DHCP can help me to solve this problem, since the SIP server I would need to register with is based on my relationship to my SIP provider, not to whoever happens to have an open WiFi for me to use at the moment. > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------050508050806020600010505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 15/10/13 23.22, Ted Lemon wrote:
On Oct 15, 2013, at 5:07 PM, Reinaldo Penno (repenno) <repenno@cisco.com> wrote:

In some enterprise environments the mail server you connect (Exchange or
IMAP) vary depending on your location. Same for SIP Servers, etc.  You
want users to connect to the closest server.

Can you give me any example where DHCP is the right way to solve the problem as you have stated it?   Particularly in an enterprise environment, I am _highly_ skeptical that there is ever a case where it makes sense to send a user to different Exchange servers as they move around the company.
Actually that is what happened in Nokia, it was not in general the DHCP that made it happen but yes, there is a good case here. Think that I normally live in Copenhagen but next day I might be in Beijing or San Diego, you really want to use the closer server and in some cases there are strict rules, maybe even laws about it (not sure which). For Exchange, the point is obviously that your mail and calendar comes from the same repository wherever you are but outgoing mail and other services may be more locally anchored.

SIP is a little more believable, in that I really wish my current SIP<->POTS provider allowed me to register with the closest SIP server rather than always being bound to the SIP server closest to my home, but I don't see how DHCP can help me to solve this problem, since the SIP server I would need to register with is based on my relationship to my SIP provider, not to whoever happens to have an open WiFi for me to use at the moment.



-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------050508050806020600010505-- From stenc@s-carlsen.dk Tue Oct 15 15:12:14 2013 Return-Path: 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 43B4E11E818B for ; Tue, 15 Oct 2013 15:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 gb3-PWbjJGwS for ; Tue, 15 Oct 2013 15:12:13 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D09221F9B10 for ; Tue, 15 Oct 2013 15:12:13 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 0291626C9; Wed, 16 Oct 2013 00:12:11 +0200 (CEST) Message-ID: <525DBDBB.9060905@s-carlsen.dk> Date: Wed, 16 Oct 2013 00:12:11 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ted Lemon References: <82A56139-52CC-47A6-9A5B-3708E18D9B86@fugue.com> <525C8B08.5010109@s-carlsen.dk> <27497AD8-45FA-4685-82DA-431DC9787802@nominum.com> <525CFF57.3080506@s-carlsen.dk> <00CFFD78-D4CB-4FD7-ACF4-6446D24A29CD@nominum.com> In-Reply-To: <00CFFD78-D4CB-4FD7-ACF4-6446D24A29CD@nominum.com> Content-Type: multipart/alternative; boundary="------------020802090902000808060005" Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:12:14 -0000 This is a multi-part message in MIME format. --------------020802090902000808060005 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 15/10/13 22.50, Ted Lemon wrote: > On Oct 15, 2013, at 4:39 AM, Sten Carlsen wrote: >> I do see your point, what I try to say is that there is no other system that knows your location within the network better. So either you use DHCP to hand out a "configuration server" including maybe parameters or do configurations it self. >> >> I do see that a different type of service to do all those configurations looks like a good idea, however it also means that that the management systems now will have yet another system to manage from the same database. >> >> A question: will there be many networks that only have one of the two types of server? > Hm, I think you've hit on another question. I'm not sure it's central, but it's worth thinking about. The SMTP server doesn't vary depending on where in the local network topology the host is connected. The DNS server needn't either. The router does, obviously. Can you think of other examples? Depending if the organisation is local or global, I can think of the selection of printers. It is rather impractical to print on the homely printer when you are abroad. I have not seen this solved in a really good way yet but I have seen the problems. Normally I don't print much but some items must be on paper and finding a printer usually takes forever. At least show me the local printer portal that knows about all local printers. > > BTW, DNS servers frequently are set up with maps of the network in the way that you describe, and indeed one of the arguments against the advice given on FQDNs in the Option Guidelines document is that people might want to do that, and if the DHCP server does the DNS lookup, it won't work. > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------020802090902000808060005 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 15/10/13 22.50, Ted Lemon wrote:
On Oct 15, 2013, at 4:39 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

I do see your point, what I try to say is that there is no other system that knows your location within the network better. So either you use DHCP to hand out a "configuration server" including maybe parameters or do configurations it self.

I do see that a different type of service to do all those configurations looks like a good idea, however it also means that that the management systems now will have yet another system to manage from the same database.

A question: will there be many networks that only have one of the two types of server?

Hm, I think you've hit on another question.   I'm not sure it's central, but it's worth thinking about.   The SMTP server doesn't vary depending on where in the local network topology the host is connected.   The DNS server needn't either.   The router does, obviously.   Can you think of other examples?
Depending if the organisation is local or global, I can think of the selection of printers. It is rather impractical to print on the homely printer when you are abroad. I have not seen this solved in a really good way yet but I have seen the problems. Normally I don't print much but some items must be on paper and finding a printer usually takes forever.
At least show me the local printer portal that knows about all local printers.

BTW, DNS servers frequently are set up with maps of the network in the way that you describe, and indeed one of the arguments against the advice given on FQDNs in the Option Guidelines document is that people might want to do that, and if the DHCP server does the DNS lookup, it won't work.



-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------020802090902000808060005-- From Ted.Lemon@nominum.com Tue Oct 15 15:18:34 2013 Return-Path: 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 462C211E8212 for ; Tue, 15 Oct 2013 15:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 jWJh6l5gL0hr for ; Tue, 15 Oct 2013 15:18:15 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4F19F11E8210 for ; Tue, 15 Oct 2013 15:18:15 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUl2/Jt2aVPyUJx9oJwj+B4vcKyXUDXgZ@postini.com; Tue, 15 Oct 2013 15:18:15 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B0B3C1B82DD for ; Tue, 15 Oct 2013 15:18:14 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 972AA19005C; Tue, 15 Oct 2013 15:18:14 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Oct 2013 15:18:14 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <525DBC60.1080209@s-carlsen.dk> Date: Tue, 15 Oct 2013 18:18:12 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1ABC4971-1E44-4146-BEF5-A6BB3146E137@nominum.com> References: <45A697A8FFD7CF48BCF2BE7E106F06040B734A24@xmb-rcd-x04.cisco.com> <771CAC3B-56AD-445E-AC97-75D6CB4521DB@nominum.com> <525DBC60.1080209@s-carlsen.dk> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:18:34 -0000 On Oct 15, 2013, at 6:06 PM, Sten Carlsen wrote: > Actually that is what happened in Nokia, it was not in general the = DHCP that made it happen but yes, there is a good case here. Think that = I normally live in Copenhagen but next day I might be in Beijing or San = Diego, you really want to use the closer server and in some cases there = are strict rules, maybe even laws about it (not sure which). For = Exchange, the point is obviously that your mail and calendar comes from = the same repository wherever you are but outgoing mail and other = services may be more locally anchored. Hm, so Outlook somehow got this information out of DHCP? This sounds = like a really cool new attack vector. From stenc@s-carlsen.dk Tue Oct 15 15:24:30 2013 Return-Path: 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 4B95A11E816D for ; Tue, 15 Oct 2013 15:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 EnLc76k3ydS2 for ; Tue, 15 Oct 2013 15:24:29 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 2283111E818B for ; Tue, 15 Oct 2013 15:24:28 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 4898C5197; Wed, 16 Oct 2013 00:24:27 +0200 (CEST) Message-ID: <525DC09B.5080703@s-carlsen.dk> Date: Wed, 16 Oct 2013 00:24:27 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ted Lemon References: <45A697A8FFD7CF48BCF2BE7E106F06040B734A24@xmb-rcd-x04.cisco.com> <771CAC3B-56AD-445E-AC97-75D6CB4521DB@nominum.com> <525DBC60.1080209@s-carlsen.dk> <1ABC4971-1E44-4146-BEF5-A6BB3146E137@nominum.com> In-Reply-To: <1ABC4971-1E44-4146-BEF5-A6BB3146E137@nominum.com> Content-Type: multipart/alternative; boundary="------------080701010604030501070007" Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:24:30 -0000 This is a multi-part message in MIME format. --------------080701010604030501070007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 16/10/13 00.18, Ted Lemon wrote: > On Oct 15, 2013, at 6:06 PM, Sten Carlsen wrote: >> Actually that is what happened in Nokia, it was not in general the DHCP that made it happen but yes, there is a good case here. Think that I normally live in Copenhagen but next day I might be in Beijing or San Diego, you really want to use the closer server and in some cases there are strict rules, maybe even laws about it (not sure which). For Exchange, the point is obviously that your mail and calendar comes from the same repository wherever you are but outgoing mail and other services may be more locally anchored. > Hm, so Outlook somehow got this information out of DHCP? This sounds like a really cool new attack vector. No, I don't think DHCP was involved and it did not work as painless as it should have. I was thinking that DHCP might provide an address to a portal or such that might do the actual work. A bit like the "next server" for TFTP. > > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------080701010604030501070007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 16/10/13 00.18, Ted Lemon wrote:
On Oct 15, 2013, at 6:06 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

Actually that is what happened in Nokia, it was not in general the DHCP that made it happen but yes, there is a good case here. Think that I normally live in Copenhagen but next day I might be in Beijing or San Diego, you really want to use the closer server and in some cases there are strict rules, maybe even laws about it (not sure which). For Exchange, the point is obviously that your mail and calendar comes from the same repository wherever you are but outgoing mail and other services may be more locally anchored.

Hm, so Outlook somehow got this information out of DHCP?   This sounds like a really cool new attack vector.
No, I don't think DHCP was involved and it did not work as painless as it should have. I was thinking that DHCP might provide an address to a portal or such that might do the actual work. A bit like the "next server" for TFTP.




-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------080701010604030501070007-- From Ted.Lemon@nominum.com Tue Oct 15 15:43:33 2013 Return-Path: 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 3EBEC11E81F4 for ; Tue, 15 Oct 2013 15:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0ygYHbGoqhze for ; Tue, 15 Oct 2013 15:43:20 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9718811E818B for ; Tue, 15 Oct 2013 15:43:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUl3FBKQQ7TttRIE0rSEvPz5uYhE97/Bw@postini.com; Tue, 15 Oct 2013 15:43:17 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AB1201B82CE for ; Tue, 15 Oct 2013 15:43:16 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A267419005C; Tue, 15 Oct 2013 15:43:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Oct 2013 15:43:16 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <525DC09B.5080703@s-carlsen.dk> Date: Tue, 15 Oct 2013 18:43:12 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <71D33595-0CE9-42CD-A572-D6C80DA9BA74@nominum.com> References: <45A697A8FFD7CF48BCF2BE7E106F06040B734A24@xmb-rcd-x04.cisco.com> <771CAC3B-56AD-445E-AC97-75D6CB4521DB@nominum.com> <525DBC60.1080209@s-carlsen.dk> <1ABC4971-1E44-4146-BEF5-A6BB3146E137@nominum.com> <525DC09B.5080703@s-carlsen.dk> To: Sten Carlsen X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:43:33 -0000 On Oct 15, 2013, at 6:24 PM, Sten Carlsen wrote: > No, I don't think DHCP was involved and it did not work as painless as = it should have. I was thinking that DHCP might provide an address to a = portal or such that might do the actual work. A bit like the "next = server" for TFTP. Okay, so just to be clear here, I'm not looking for new applications for = DHCP. I'm asking people to tell me if they disagree with my theory = that services of this type (a) can't be generally configured by DHCP and = (b) aren't typically configured by DHCP at the present time. Yes, of = course you can cobble together some hack using DHCP. The question is (a) is it _ever_ a good idea, (b) is it safe to enable = this behavior by default on all nodes, and (c) if it's not safe, is the = behavior in any sense useful? From stenc@s-carlsen.dk Tue Oct 15 15:59:54 2013 Return-Path: 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 AE10921F9EE5 for ; Tue, 15 Oct 2013 15:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 tI9m0Rb-PogD for ; Tue, 15 Oct 2013 15:59:54 -0700 (PDT) Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCF221F93BF for ; Tue, 15 Oct 2013 15:59:46 -0700 (PDT) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id BC34326C9; Wed, 16 Oct 2013 00:59:45 +0200 (CEST) Message-ID: <525DC8E1.8050208@s-carlsen.dk> Date: Wed, 16 Oct 2013 00:59:45 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ted Lemon References: <45A697A8FFD7CF48BCF2BE7E106F06040B734A24@xmb-rcd-x04.cisco.com> <771CAC3B-56AD-445E-AC97-75D6CB4521DB@nominum.com> <525DBC60.1080209@s-carlsen.dk> <1ABC4971-1E44-4146-BEF5-A6BB3146E137@nominum.com> <525DC09B.5080703@s-carlsen.dk> <71D33595-0CE9-42CD-A572-D6C80DA9BA74@nominum.com> In-Reply-To: <71D33595-0CE9-42CD-A572-D6C80DA9BA74@nominum.com> Content-Type: multipart/alternative; boundary="------------010905030803040008030108" Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:59:54 -0000 This is a multi-part message in MIME format. --------------010905030803040008030108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 16/10/13 00.43, Ted Lemon wrote: > On Oct 15, 2013, at 6:24 PM, Sten Carlsen wrote: >> No, I don't think DHCP was involved and it did not work as painless as it should have. I was thinking that DHCP might provide an address to a portal or such that might do the actual work. A bit like the "next server" for TFTP. > Okay, so just to be clear here, I'm not looking for new applications for DHCP. Right, that is fine. > I'm asking people to tell me if they disagree with my theory that services of this type (a) can't be generally configured by DHCP and (b) aren't typically configured by DHCP at the present time. Yes, of course you can cobble together some hack using DHCP. > > The question is (a) is it _ever_ a good idea, (b) is it safe to enable this behavior by default on all nodes, and (c) if it's not safe, is the behavior in any sense useful? 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? I am still trying to learn more. > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------010905030803040008030108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 16/10/13 00.43, Ted Lemon wrote:
On Oct 15, 2013, at 6:24 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:

No, I don't think DHCP was involved and it did not work as painless as it should have. I was thinking that DHCP might provide an address to a portal or such that might do the actual work. A bit like the "next server" for TFTP.

Okay, so just to be clear here, I'm not looking for new applications for DHCP.
Right, that is fine.
   I'm asking people to tell me if they disagree with my theory that services of this type (a) can't be generally configured by DHCP and (b) aren't typically configured by DHCP at the present time.   Yes, of course you can cobble together some hack using DHCP.

The question is (a) is it _ever_ a good idea, (b) is it safe to enable this behavior by default on all nodes, and (c) if it's not safe, is the behavior in any sense useful?
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?

I am still trying to learn more.



-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------010905030803040008030108-- From repenno@cisco.com Tue Oct 15 16:03:16 2013 Return-Path: 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 8F72911E8209 for ; Tue, 15 Oct 2013 16:03:16 -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=[AWL=-0.000, 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 JSnMYomE-DSJ for ; Tue, 15 Oct 2013 16:03:11 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DEBEB21F9FF9 for ; Tue, 15 Oct 2013 16:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5955; q=dns/txt; s=iport; t=1381878191; x=1383087791; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=RmfuFLPjhz8pUvvrS/ii06OGpfKaZW5hkeDHNpKjCKQ=; b=EEGjSrAcsFsAsy3tI4jDTdRLI6IwcxFRBIAV8ODFKWxWC0MMp/R+Auka ZzZ/iiKM+nTCkYuvJWrd0i+1NW9sDsBI6F1nmnmXjiZzjPcuvmD8TV7R0 Prc1mb1JU/2JbHnCcH3++BUi6tt1RNjoRK+nX2RPld/onXAk55WeVm4Ys 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAAHJXVKtJV2Z/2dsb2JhbABagkNEgQrCKoEiFnSCJQEBAQR5EgEIEQMBAgsdORQJCAIEAQ0FCId+vguPGSARB4MfgQYDqgaDJIIp X-IronPort-AV: E=Sophos;i="4.93,503,1378857600"; d="scan'208,217";a="272551238" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2013 23:03:10 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FN3AJB004723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 23:03:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 18:03:10 -0500 From: "Reinaldo Penno (repenno)" To: Sten Carlsen , Ted Lemon Thread-Topic: [dhcwg] What sorts of services does DHCP configure? Thread-Index: AQHOyQrfiAXKk6KM3ESJzga2BnKmuZn1O08AgAAbXoCAAG9IgIAAzAeA//+PjACAAHmLgIAADDsAgAADTACAAAG/gIAABT4AgAAEn4D//4uaAA== Date: Tue, 15 Oct 2013 23:03:09 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B735BD1@xmb-rcd-x04.cisco.com> In-Reply-To: <525DC8E1.8050208@s-carlsen.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.126.180] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F06040B735BD1xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org WG" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 23:03:16 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F06040B735BD1xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree with Sten. From: Sten Carlsen > Date: Tuesday, October 15, 2013 3:59 PM To: Ted Lemon > Cc: Cisco Employee >, "dhcwg@ie= tf.org WG" > Subject: Re: [dhcwg] What sorts of services does DHCP configure? On 16/10/13 00.43, Ted Lemon wrote: On Oct 15, 2013, at 6:24 PM, Sten Carlsen wrote: No, I don't think DHCP was involved and it did not work as painless as it s= hould have. I was thinking that DHCP might provide an address to a portal o= r such that might do the actual work. A bit like the "next server" for TFTP= . Okay, so just to be clear here, I'm not looking for new applications for DH= CP. Right, that is fine. I'm asking people to tell me if they disagree with my theory that servic= es of this type (a) can't be generally configured by DHCP and (b) aren't ty= pically configured by DHCP at the present time. Yes, of course you can co= bble together some hack using DHCP. The question is (a) is it _ever_ a good idea, (b) is it safe to enable this= behavior by default on all nodes, and (c) if it's not safe, is the behavio= r in any sense useful? I tend to look at this from the opposite side, what are the services that n= eed to be configured and infomation that needs to be delivered? And as a co= nsequence what are the tools? What is in the toolbox now and what is missing? Some of the missing tools a= re leading to ugly hacks now. The answer might not be DHCP, but then what is it? I am still trying to learn more. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --_000_45A697A8FFD7CF48BCF2BE7E106F06040B735BD1xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <9A3CA0E588315A4498113AF53404B882@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Agree with  Sten.

From: Sten Carlsen <stenc@s-carlsen.dk>
Date: Tuesday, October 15, 2013 3:5= 9 PM
To: Ted Lemon <ted.lemon@nominum.com>
Cc: Cisco Employee <repenno@cisco.com>, "dhcwg@ietf.org WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] What sorts of = services does DHCP configure?


On 16/10/13 00.43, Ted Lemon wrote:
On Oct 15, 2013, at 6:24 PM, Sten Carlsen <stenc@s-carlsen.dk&=
gt; wrote:

No, I don't think DHCP was involved and it did not work as p=
ainless as it should have. I was thinking that DHCP might provide an addres=
s to a portal or such that might do the actual work. A bit like the "n=
ext server" for TFTP.

Okay, so just to be clear here, I'm not looking for new appl=
ications for DHCP.
Right, that is fine.
   I'm asking people to tell me if they disagree with my the=
ory that services of this type (a) can't be generally configured by DHCP an=
d (b) aren't typically configured by DHCP at the present time.   Yes, of co=
urse you can cobble together some hack using DHCP.

The question is (a) is it _ever_ a good idea, (b) is it safe to enable this=
 behavior by default on all nodes, and (c) if it's not safe, is the behavio=
r in any sense useful?
I tend to look at this from the opposite side, what are the services that n= eed to be configured and infomation that needs to be delivered? And as a co= nsequence what are the tools?
What is in the toolbox now and what is missing? Some of the missing tools a= re leading to ugly hacks now.
The answer might not be DHCP, but then what is it?

I am still trying to learn more.






--=20
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"=20










--_000_45A697A8FFD7CF48BCF2BE7E106F06040B735BD1xmbrcdx04ciscoc_--

From jiangsheng@huawei.com  Tue Oct 15 19:20:29 2013
Return-Path: 
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 A6D0921F9950 for ; Tue, 15 Oct 2013 19:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.561
X-Spam-Level: 
X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 byEO0k1ItLBO for ; Tue, 15 Oct 2013 19:20:14 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A7CAB11E823E for ; Tue, 15 Oct 2013 19:19:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZC83126; Wed, 16 Oct 2013 02:19:44 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 16 Oct 2013 03:18:51 +0100
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 16 Oct 2013 03:19:42 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0146.000; Wed, 16 Oct 2013 10:19:37 +0800
From: Sheng Jiang 
To: "Bernie Volz (volz)" , "dhcwg@ietf.org" 
Thread-Topic: Call for Agenda Items for IETF-88 (Vancouver)
Thread-Index: Ac7CyRRj2lhQNkosRiKfaagKYriJPwHTIBHw
Date: Wed, 16 Oct 2013 02:19:36 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD490D9@nkgeml512-mbx.china.huawei.com>
References: <489D13FBFA9B3E41812EA89F188F018E1ACF6595@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ACF6595@xmb-rcd-x04.cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AD490D9nkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [dhcwg] Call for Agenda Items for IETF-88 (Vancouver)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 02:20:29 -0000

--_000_5D36713D8A4E7348A7E10DF7437A4B923AD490D9nkgeml512mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiBJZiB5b3Ugd291bGQgbGlrZSB0aW1lLCBwbGVhc2UgaW5kaWNhdGU6DQoNCj4gLSAgICAgICAg
ICBEcmFmdCBuYW1lIG9yIHRvcGljDQoNCj4gLSAgICAgICAgICBXaG8gd2lsbCBwcmVzZW50DQoN
Cj4gLSAgICAgICAgICBIb3cgbXVjaCB0aW1lIGlzIG5lZWRlZA0KDQo+DQoNCj4gLSAgICAgICAg
ICBXaHkgaXMgdGltZSBuZWVkZWQgKHRlbGwgdXMgd2h5IHlvdSBjYW7igJl0IGdldCB3aGF0IHlv
dSBuZWVkDQoNCj4gYnkgcG9zdGluZyBvbiB0aGUgbWFpbGluZyBsaXN0KSBhbmQgd2hhdCB3aWxs
IGJlIGNvdmVyZWQNCg0KDQoNCldlJ2QgbGlrZSB0byByZXF1ZXN0IGEgMTAgbWludXRlcyBzbG90
IGZvciBhZGRyZXNzIHJlZ2lzdHJhdGlvbiB3b3JrLCBhcyBVUkkgYmVsb3cuIFN1cmVzaCB3aWxs
IGJlIHRoZSBwcmVzZW50ZXIgZm9yIG5vdy4gVGhpcyB0aW1lIGlzIG5lZWRlZCwgYmVjYXVzZSB0
aGlzIGlzIGEgY2hhcnRlcmVkIGl0ZW0gYW5kIHRoZSBkcmFmdCBoYXMgbWFkZSBtYWduaWZpY2Vu
dCBjaGFuZ2VzIGZyb20gcHJldmlvdXMgdmVyc2lvbi4NCg0KDQoNCmh0dHA6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLWFkZHItcmVnaXN0cmF0aW9uDQoNCg0KDQpUaGUgYXV0
aG9ycyB3b3VsZCBsaWtlIHRvIGNhbGwgY29tbWVudHMgYW5kIHJldmlld2VycyBmb3IgdGhlIGN1
cnJlbnQgdmVyc2lvbi4NCg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KDQoNClNoZW5nICsgU3VyZXNo
DQoNCg0KRnJvbTogZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJuaWUgVm9seiAodm9seikNClNlbnQ6IE1vbmRheSwg
T2N0b2JlciAwNywgMjAxMyAzOjI1IEFNDQpUbzogZGhjd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFtk
aGN3Z10gQ2FsbCBmb3IgQWdlbmRhIEl0ZW1zIGZvciBJRVRGLTg4IChWYW5jb3V2ZXIpDQpJbXBv
cnRhbmNlOiBIaWdoDQoNCkhpOg0KDQpUaGUgVmFuY291dmVyIElFVEYgaXMgbm90IHRoYXQgZmFy
IG9mZiAoTm92IDMtOCkuIFNlZSBodHRwOi8vd3d3LmlldGYub3JnL21lZXRpbmcvODgvaW5kZXgu
aHRtbCBmb3IgbW9yZSBkZXRhaWxzLCBpbmNsdWRpbmcgdmVudWUgaW5mb3JtYXRpb24gYW5kIGlt
cG9ydGFudCBkYXRlcy4NCg0KVGhlIHByZWxpbWluYXJ5IGFnZW5kYSBoYXMgdGhlIERIQyBXRyBp
cyBzY2hlZHVsZWQgZm9yIFRVRVNEQVksIE5vdmVtYmVyIDUgZnJvbSAwOTAwLTExMzAgUFNULg0K
DQpQbGVhc2UgYWxzbyBub3RlOg0KDQogICogICAyMDEzLTEwLTA3IChNb25kYXkpOiBXb3JraW5n
IEdyb3VwIENoYWlyIGFwcHJvdmFsIGZvciBpbml0aWFsIGRvY3VtZW50IChWZXJzaW9uIC0wMCkg
c3VibWlzc2lvbnMgYXBwcmVjaWF0ZWQgYnkgVVRDIDI0OjAwLg0KICAqICAgMjAxMy0xMC0xMSAo
RnJpZGF5KTogRmluYWwgYWdlbmRhIHRvIGJlIHB1Ymxpc2hlZC4NCiAgKiAgIDIwMTMtMTAtMjEg
KE1vbmRheSk6IEludGVybmV0IERyYWZ0IHN1Ym1pc3Npb24gY3V0LW9mZiAoZm9yIGFsbCBkcmFm
dHMsIGluY2x1ZGluZyAtMDApIGJ5IFVUQyAyNDowMCwgdXBsb2FkIHVzaW5nIElFVEYgSUQgU3Vi
bWlzc2lvbiBUb29sPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvc3VibWl0Lz4uDQpXZSBh
cmUgc3RhcnRpbmcgdGhlIGNhbGwgZm9yIGFnZW5kYSBpdGVtcy4gVGhlIGNvLWNoYWlycyB3aWxs
IGZpbmFsaXplIHRoZSBhZ2VuZGEgYWJvdXQgdHdvIHdlZWtzIGJlZm9yZSB0aGUgbWVldGluZyBh
bmQgd2lsbCBnaXZlIHByaW9yaXR5IHRvIGl0ZW1zIGFzIGZvbGxvd3MgKGluIHRoaXMgb3JkZXIp
Og0KDQoNCjEuICAgICAgV0cgZG9jdW1lbnRzIHdpdGggYWN0aXZlIHdvcmtpbmcgZ3JvdXAgZGlz
Y3Vzc2lvbiBvciB0aGF0IGFyZSBkZWVtZWQgY3JpdGljYWwgKGkuZS4sIGhhdmUgdXBjb21pbmcg
bWlsZXN0b25lcykNCg0KMi4gICAgICBXRyBkb2N1bWVudHMgd2l0aCBsaXR0bGUgb3Igbm8gZGlz
Y3Vzc2lvbiAocHJvdmlkZWQgdGhlcmUgaXMgYSBzdHJvbmcgcmVhc29uIGZvciB0aGUgZGlzY3Vz
c2lvbiDigKYgaS5lLiwgYSBoaWdoZXIgYmFuZHdpZHRoIGRpc2N1c3Npb24gaXMgbmVlZGVkKQ0K
DQozLiAgICAgIE5vbiBXRyBkb2N1bWVudHMgd2l0aCBhY3RpdmUgd29ya2luZyBncm91cCBkaXNj
dXNzaW9uDQoNCjQuICAgICAgTm9uIFdHIGRvY3VtZW50cyB3aXRoIGxpdHRsZSBvciBubyBkaXNj
dXNzaW9uDQoNCldlIHdpbGwgbGltaXQgdGhlIG51bWJlciBvZiBwcmVzZW50YXRpb25zIHRvIHJl
ZHVjZSB0aGUgY2hhbmNlIHRoYXQgd2UgZG9u4oCZdCBnZXQgdG8gdGhlbSBhbGwuDQoNClBsZWFz
ZSBiZSBzdXJlIHRvIGZvY3VzIHlvdXIgcHJlc2VudGF0aW9ucyBvbiBpc3N1ZXMgdGhhdCBuZWVk
IGRpc2N1c3Npb24gb3IgaW5wdXQgKG5ldyB3b3JrIGNhbiBpbmNsdWRlIGFuIG92ZXJ2aWV3LCBi
dXQgdGhlIGZvY3VzIHNob3VsZCBiZSBvbiBpc3N1ZXMgbmVlZGluZyByZXNvbHV0aW9uKS4gU3Rh
dHVzIHVwZGF0ZXMgY2FuIGJlIHNlbnQgdG8gdGhlIG1haWxpbmcgbGlzdC4NCg0KSWYgeW91IHdv
dWxkIGxpa2UgdGltZSwgcGxlYXNlIGluZGljYXRlOg0KDQotICAgICAgICBEcmFmdCBuYW1lIG9y
IHRvcGljDQoNCi0gICAgICAgIFdobyB3aWxsIHByZXNlbnQNCg0KLSAgICAgICAgSG93IG11Y2gg
dGltZSBpcyBuZWVkZWQNCg0KLSAgICAgICAgV2h5IGlzIHRpbWUgbmVlZGVkICh0ZWxsIHVzIHdo
eSB5b3UgY2Fu4oCZdCBnZXQgd2hhdCB5b3UgbmVlZCBieSBwb3N0aW5nIG9uIHRoZSBtYWlsaW5n
IGxpc3QpIGFuZCB3aGF0IHdpbGwgYmUgY292ZXJlZA0KDQpUaGFua3MuDQoNCg0KLSAgICAgICAg
VG9tZWsgJiBCZXJuaWUNCg==

--_000_5D36713D8A4E7348A7E10DF7437A4B923AD490D9nkgeml512mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1
IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh
bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz
IDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z
b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl
ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRl
eHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0
UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7
DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBj
bTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFu
LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw
YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls
U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFyDQoJe21z
by1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3
OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA
bGlzdCBsMA0KCXttc28tbGlzdC1pZDo1NDU5NDY0NTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7
DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2NjIxMzQyODYgLTEzNTYxNzE4NTAgNjc2OTg2OTEg
Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2
OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6
Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz
dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp
ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm
b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww
OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n
czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21z
by1saXN0LWlkOjU1MTAzODM0OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTU1MzkwNTA4MDt9
DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21z
by1saXN0LWlkOjY0ODg5ODcyNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10
ZW1wbGF0ZS1pZHM6MTk2NjM5MjI3NCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw
MyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBs
MjpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
MTguMHB0O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h
bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs
aXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0
Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVs
OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k
ZW50Oi05LjBwdDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxNDc2NDg5NzA0Ow0KCW1zby1s
aXN0LXRlbXBsYXRlLWlkczoxNjU0NTc5MzIyO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci
Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxl
dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s
ZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv
cDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu
Z2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K
CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs
aXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVs
OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn
Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl
bC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjE2NTkyNjg4MzQ7DQoJ
bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwMTM1Nzc0Mjgg
MTgwODY4NTgwNCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2
NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28t
ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN
Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl
bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZl
bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp
c3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt
c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs
NDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw
bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IElmIHlvdSB3b3VsZCBsaWtlIHRpbWUsIHBsZWFzZSBp
bmRpY2F0ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERyYWZ0IG5hbWUgb3IgdG9waWM8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAt
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdo
byB3aWxsIHByZXNlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhvdyBtdWNoIHRpbWUgaXMgbmVlZGVkPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaHkgaXMgdGltZSBuZWVkZWQgKHRlbGwgdXMgd2h5IHlv
dSBjYW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+4oCZPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj50IGdldCB3aGF0
IHlvdSBuZWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgYnkgcG9zdGluZyBvbiB0aGUgbWFpbGluZyBsaXN0KSBh
bmQgd2hhdCB3aWxsIGJlIGNvdmVyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPldlJ2QgbGlr
ZSB0byByZXF1ZXN0IGEgMTAgbWludXRlcyBzbG90IGZvciBhZGRyZXNzIHJlZ2lzdHJhdGlvbiB3
b3JrLCBhcyBVUkkgYmVsb3cuIFN1cmVzaCB3aWxsIGJlIHRoZSBwcmVzZW50ZXIgZm9yIG5vdy4g
VGhpcyB0aW1lIGlzIG5lZWRlZCwgYmVjYXVzZSB0aGlzIGlzIGEgY2hhcnRlcmVkIGl0ZW0gYW5k
IHRoZSBkcmFmdCBoYXMgbWFkZSBtYWduaWZpY2VudCBjaGFuZ2VzDQogZnJvbSBwcmV2aW91cyB2
ZXJzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiPlRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gY2FsbCBjb21tZW50cyBhbmQgcmV2aWV3ZXJz
IGZvciB0aGUgY3VycmVudCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCBy
ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U2hlbmcgJiM0MzsgU3VyZXNoPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu
NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw
Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1i
b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZXJuaWUgVm9seiAodm9seik8
YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDA3LCAyMDEzIDM6MjUgQU08YnI+DQo8
Yj5Ubzo8L2I+IGRoY3dnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtkaGN3Z10gQ2Fs
bCBmb3IgQWdlbmRhIEl0ZW1zIGZvciBJRVRGLTg4IChWYW5jb3V2ZXIpPGJyPg0KPGI+SW1wb3J0
YW5jZTo8L2I+IEhpZ2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPkhpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U
aGUgVmFuY291dmVyIElFVEYgaXMgbm90IHRoYXQgZmFyIG9mZiAoTm92IDMtOCkuIFNlZQ0KPGEg
aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzg4L2luZGV4Lmh0bWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5odHRwOi8vd3d3LmlldGYub3JnL21lZXRpbmcvODgvaW5k
ZXguaHRtbDwvc3Bhbj48L2E+IGZvciBtb3JlIGRldGFpbHMsIGluY2x1ZGluZyB2ZW51ZSBpbmZv
cm1hdGlvbiBhbmQgaW1wb3J0YW50IGRhdGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHByZWxp
bWluYXJ5IGFnZW5kYSBoYXMgdGhlIERIQyBXRyBpcyBzY2hlZHVsZWQgZm9yIFRVRVNEQVksIE5v
dmVtYmVyIDUgZnJvbSAwOTAwLTExMzAgUFNULjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UGxlYXNlIGFs
c28gbm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm8zO2JhY2tn
cm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+MjAxMy0xMC0wNyAoTW9uZGF5KTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO1dvcmtpbmcgR3JvdXAgQ2hhaXIgYXBwcm92YWwgZm9y
IGluaXRpYWwgZG9jdW1lbnQgKFZlcnNpb24gLTAwKQ0KIHN1Ym1pc3Npb25zIGFwcHJlY2lhdGVk
IGJ5IFVUQyAyNDowMC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzM7YmFja2dyb3VuZDp3aGl0ZSI+
DQo8Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMDEzLTEwLTEx
IChGcmlkYXkpOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+Jm5ic3A7RmluYWwgYWdlbmRhIHRvIGJlIHB1Ymxpc2hlZC48bzpwPjwvbzpwPjwvc3Bh
bj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2
ZWwxIGxmbzM7YmFja2dyb3VuZDp3aGl0ZSI+DQo8Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4yMDEzLTEwLTIxIChNb25kYXkpOjwvc3Bhbj48L2I+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh
bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7SW50ZXJuZXQgRHJhZnQgc3Vi
bWlzc2lvbiBjdXQtb2ZmIChmb3IgYWxsIGRyYWZ0cywgaW5jbHVkaW5nIC0wMCkNCiBieSBVVEMg
MjQ6MDAsIHVwbG9hZCB1c2luZyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvc3VibWl0LyI+SUVURiBJRCBTdWJtaXNzaW9uIFRvb2w8L2E+LjxvOnA+PC9vOnA+PC9z
cGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5X
ZSBhcmUgc3RhcnRpbmcgdGhlIGNhbGwgZm9yIGFnZW5kYSBpdGVtcy4gVGhlIGNvLWNoYWlycyB3
aWxsIGZpbmFsaXplIHRoZSBhZ2VuZGEgYWJvdXQgdHdvIHdlZWtzIGJlZm9yZSB0aGUgbWVldGlu
ZyBhbmQgd2lsbCBnaXZlIHByaW9yaXR5IHRvIGl0ZW1zIGFzIGZvbGxvd3MgKGluIHRoaXMgb3Jk
ZXIpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw
dDttc28tbGlzdDpsMiBsZXZlbDEgbGZvNSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y
ZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb
ZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPldHIGRvY3VtZW50
cyB3aXRoIGFjdGl2ZSB3b3JraW5nIGdyb3VwIGRpc2N1c3Npb24gb3IgdGhhdCBhcmUgZGVlbWVk
IGNyaXRpY2FsIChpLmUuLCBoYXZlIHVwY29taW5nIG1pbGVzdG9uZXMpPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot
MTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm81Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6
SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh
bj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+V0cgZG9j
dW1lbnRzIHdpdGggbGl0dGxlIG9yIG5vIGRpc2N1c3Npb24gKHByb3ZpZGVkIHRoZXJlIGlzIGEg
c3Ryb25nIHJlYXNvbiBmb3IgdGhlIGRpc2N1c3Npb24g4oCmIGkuZS4sIGEgaGlnaGVyIGJhbmR3
aWR0aCBkaXNjdXNzaW9uIGlzIG5lZWRlZCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6
bDIgbGV2ZWwxIGxmbzUiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4g
c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Ob24gV0cgZG9jdW1lbnRzIHdpdGgg
YWN0aXZlIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t
bGlzdDpsMiBsZXZlbDEgbGZvNSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NC48
c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPk5vbiBXRyBkb2N1bWVudHMg
d2l0aCBsaXR0bGUgb3Igbm8gZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPldlIHdpbGwgbGltaXQgdGhlIG51bWJlciBv
ZiBwcmVzZW50YXRpb25zIHRvIHJlZHVjZSB0aGUgY2hhbmNlIHRoYXQgd2UgZG9u4oCZdCBnZXQg
dG8gdGhlbSBhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2UgYmUgc3VyZSB0byBmb2N1cyB5
b3VyIHByZXNlbnRhdGlvbnMgb24gaXNzdWVzIHRoYXQgbmVlZCBkaXNjdXNzaW9uIG9yIGlucHV0
IChuZXcgd29yayBjYW4gaW5jbHVkZSBhbiBvdmVydmlldywgYnV0IHRoZSBmb2N1cyBzaG91bGQg
YmUgb24gaXNzdWVzIG5lZWRpbmcgcmVzb2x1dGlvbikuIFN0YXR1cyB1cGRhdGVzIGNhbiBiZSBz
ZW50IHRvIHRoZSBtYWlsaW5nIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SWYgeW91IHdvdWxkIGxpa2UgdGltZSwgcGxlYXNl
IGluZGljYXRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy
YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvNyI+
PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj
ayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0
ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+RHJhZnQgbmFtZSBvciB0b3BpYzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p
bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvNyI+PCFbaWYgIXN1cHBvcnRMaXN0
c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1z
by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8
L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjpibGFjayI+V2hvIHdpbGwgcHJlc2VudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz
dDpsMCBsZXZlbDEgbGZvNyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFu
IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48
IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SG93IG11Y2gg
dGltZSBpcyBuZWVkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh
cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm
bzciPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3
LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPldoeSBpcyB0aW1lIG5lZWRlZCAodGVs
bCB1cyB3aHkgeW91IGNhbuKAmXQgZ2V0IHdoYXQgeW91IG5lZWQgYnkgcG9zdGluZyBvbiB0aGUg
bWFpbGluZyBsaXN0KSBhbmQgd2hhdCB3aWxsIGJlIGNvdmVyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFua3MuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omw0
IGxldmVsMSBsZm85Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5
bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu
ZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Ub21layAmYW1wOyBC
ZXJuaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_5D36713D8A4E7348A7E10DF7437A4B923AD490D9nkgeml512mbxchi_--

From jiangsheng@huawei.com  Wed Oct 16 01:12:29 2013
Return-Path: 
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 4F83511E8117 for ; Wed, 16 Oct 2013 01:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.566
X-Spam-Level: 
X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.034,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9Du-G74HsD8A for ; Wed, 16 Oct 2013 01:12:19 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5999621F9F51 for ; Wed, 16 Oct 2013 01:11:47 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZD07435; Wed, 16 Oct 2013 08:11:44 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 16 Oct 2013 09:10:48 +0100
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 16 Oct 2013 09:11:41 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0146.000; Wed, 16 Oct 2013 16:11:33 +0800
From: Sheng Jiang 
To: "dhcwg@ietf.org" 
Thread-Topic: New Version Notification for draft-jiang-dhc-sedhcpv6-02.txt
Thread-Index: AQHOykbdwQ6kRC+BiEOrNNzNDITUQJn2+T2w
Date: Wed, 16 Oct 2013 08:11:32 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD492CE@nkgeml512-mbx.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [dhcwg] FW: New Version Notification for draft-jiang-dhc-sedhcpv6-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 08:12:29 -0000

VGhlIGF1dGhvcnMgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBTZWN1cmUgREhDUHY2
LCBmb2xsb3dpbmcgdGhlIHJldmlldyBjb21tZW50cyBmcm9tIFRlZCBMZW1vbiBhbiBCZXJuaWUg
Vm9sei4gVGhlIGxhdGVzdCB2ZXJzaW9uIGNhbiBiZSBmb3VuZCB0aHJvdWdoIGJlbG93IFVSTC4N
Cg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamlhbmctZGhjLXNl
ZGhjcHY2LTAyLnR4dA0KDQpDaGFuZ2UgbG9nDQoNCiAgIGRyYWZ0LWppYW5nLWRoYy1zZWRoY3B2
Ni0wMTogcmVtb3ZlZCBwcm90ZWN0aW9uIGJldHdlZW4gcmVsYXkgYWdlbnQNCiAgIGFuZCBzZXJ2
ZXIgZHVlIHRvIGNvbXBsZXhpdHksIGZvbGxvd2luZyB0aGUgY29tbWVudHMgZnJvbSBUZWQgTGVt
b24sDQogICBCZXJuaWUgVm9sei4gMjAxMy0xMC0xNi4NCg0KICAgZHJhZnQtamlhbmctZGhjLXNl
ZGhjcHY2LTAxOiB1cGRhdGUgYWNjb3JkaW5nIHRvIHJldmlldyBjb21tZW50cyBmcm9tDQogICBU
ZWQgTGVtb24sIEJlcm5pZSBWb2x6LCBSYWxwaCBEcm9tcy4gIFNlcGFyYXRlZCBQdWJsaWMgS2V5
Lw0KICAgQ2VydGlmaWNhdGUgb3B0aW9uIGludG8gdHdvIG9wdGlvbnMuICBSZWZpbmVkIG1hbnkg
ZGV0YWlsZWQNCiAgIHByb2Nlc3Nlcy4gMjAxMy0xMC0wOC4NCg0KICAgZHJhZnQtamlhbmctZGhj
LXNlZGhjcHY2LTAwOiBvcmlnaW5hbCB2ZXJzaW9uLCB0aGlzIGRyYWZ0IGlzIGENCiAgIHJlcGxh
Y2VtZW50IG9mIGRyYWZ0LWlldGYtZGhjLXNlY3VyZS1kaGNwdjYsIHdoaWNoIHJlYWNoZWQgSUVT
RyBhbmQNCiAgIGRlYWQgYmVjYXVzZSBvZiBjb25zaWRlcmF0aW9uIHJlZ2FyZGluZyB0byBDR0Eu
ICBUaGUgYXV0aG9ycyBmb2xsb3dlZA0KICAgdGhlIHN1Z2dlc3Rpb24gZnJvbSBJRVNHIG1ha2lu
ZyBhIGdlbmVyYWwgcHVibGljIGtleSBiYXNlZCBtZWNoYW5pc20uDQogICAyMDEzLTA2LTI5Lg0K
DQpNb3JlIHZpZXcgYW5kIGNvbW1lbnRzIGFyZSBhbHdheXMgYXBwcmVjaWF0ZWQuDQoNCkJlc3Qg
cmVnYXJkcywNCg0KU2hlbmcgKyBTZWFuDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp
ZXRmLm9yZ10NCj5TZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTYsIDIwMTMgNDowOCBQTQ0KPlRv
OiBTaGVuZyBKaWFuZzsgU2VhbiBTaGVuDQo+U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0
aW9uIGZvciBkcmFmdC1qaWFuZy1kaGMtc2VkaGNwdjYtMDIudHh0DQo+DQo+DQo+QSBuZXcgdmVy
c2lvbiBvZiBJLUQsIGRyYWZ0LWppYW5nLWRoYy1zZWRoY3B2Ni0wMi50eHQNCj5oYXMgYmVlbiBz
dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNoZW5nIEppYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+
SUVURiByZXBvc2l0b3J5Lg0KPg0KPkZpbGVuYW1lOgkgZHJhZnQtamlhbmctZGhjLXNlZGhjcHY2
DQo+UmV2aXNpb246CSAwMg0KPlRpdGxlOgkJIFNlY3VyZSBESENQdjYgd2l0aCBQdWJsaWMgS2V5
DQo+Q3JlYXRpb24gZGF0ZToJIDIwMTMtMTAtMTYNCj5Hcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1p
c3Npb24NCj5OdW1iZXIgb2YgcGFnZXM6IDE2DQo+VVJMOg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcv
aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWppYW5nLWRoYy1zZWRoY3B2Ni0wMi50eHQNCj5TdGF0dXM6
ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamlhbmctZGhj
LXNlZGhjcHY2DQo+SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1qaWFuZy1kaGMtc2VkaGNwdjYtMDINCj5EaWZmOg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcv
cmZjZGlmZj91cmwyPWRyYWZ0LWppYW5nLWRoYy1zZWRoY3B2Ni0wMg0KPg0KPkFic3RyYWN0Og0K
PiAgIFRoZSBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhD
UHY2KSBlbmFibGVzDQo+ICAgREhDUHY2IHNlcnZlcnMgdG8gcGFzcyBjb25maWd1cmF0aW9uIHBh
cmFtZXRlcnMuICBJdCBvZmZlcnMNCj4gICBjb25maWd1cmF0aW9uIGZsZXhpYmlsaXR5LiAgSWYg
bm90IHNlY3VyZWQsIERIQ1B2NiBpcyB2dWxuZXJhYmxlIHRvDQo+ICAgdmFyaW91cyBhdHRhY2tz
LCBwYXJ0aWN1bGFybHkgc3Bvb2ZpbmcgYXR0YWNrcy4gIFRoaXMgZG9jdW1lbnQNCj4gICBhbmFs
eXplcyB0aGUgc2VjdXJpdHkgaXNzdWVzIG9mIERIQ1B2NiBhbmQgc3BlY2lmaWVzIGEgU2VjdXJl
IERIQ1B2Ng0KPiAgIG1lY2hhbmlzbSBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIERIQ1B2NiBj
bGllbnQgYW5kIHNlcnZlci4gIFRoaXMNCj4gICBtZWNoYW5pc20gaXMgYmFzZWQgb24gcHVibGlj
L3ByaXZhdGUga2V5IHBhaXJzLiAgVGhlIGF1dGhvcml0eSBvZiB0aGUNCj4gICBzZW5kZXIgbWF5
IGRlcGVuZCBvbiBlaXRoZXIgcHJlLWNvbmZpZ3VyYXRpb24gbWVjaGFuaXNtIG9yIFB1YmxpYyBL
ZXkNCj4gICBJbmZyYXN0cnVjdHVyZS4NCj4NCj4NCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0
IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u
DQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0
b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=

From linux@thehobsons.co.uk  Wed Oct 16 06:10:22 2013
Return-Path: 
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 BBE5611E82A3 for ; Wed, 16 Oct 2013 06:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Py7P+dCo5X7D for ; Wed, 16 Oct 2013 06:10:22 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 60E9521F9E6A for ; Wed, 16 Oct 2013 06:10:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 8424810401B for ; Wed, 16 Oct 2013 14:10:18 +0100 (BST)
Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6Z8Nj26AzpT for ; Wed, 16 Oct 2013 14:10:18 +0100 (BST)
Received: from localhost (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 23A5610401A for ; Wed, 16 Oct 2013 14:10:18 +0100 (BST)
From: "Simon Hobson"  
To: "dhcwg@ietf.org WG"  
Date: Wed, 16 Oct 2013 14:10:27 +0100
X-Priority: 3
X-Mailer: MailForge 3.0 Mac OS X
Message-ID: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 13:10:22 -0000

"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. 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 volz@cisco.com  Wed Oct 16 07:16:07 2013
Return-Path: 
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 8896E21F996A for ; Wed, 16 Oct 2013 07:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 bEs6XDS9hCyv for ; Wed, 16 Oct 2013 07:16:01 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D06E21F9CC0 for ; Wed, 16 Oct 2013 07:15:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5295; q=dns/txt; s=iport; t=1381932956; x=1383142556; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fkZAt5GdcNAXYqRZg0L3BdP02z1r2bxR6c1aAjrdFbY=; b=gqp/Uo0EFtHMKl787LYpFxWR2LuZrBZZLue14iPWLK8mQoFg+NzYFVlD BN1h3J41zW3rmyfDUoVEa6qRuCwMPtAVj+CjCsISlEZ8vO0XH4YhgZw6J uCxBbvG2uu0Bf1crF3bJsIpeotBYyyuTPR26xy8gafOaNVUMOl3HST/N4 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAPeeXlKtJV2c/2dsb2JhbABagwc4UsIPgR0WdIIlAQEBAwEBAQE3NBAHBAIBCBEEAQEBCgsJCQcnCxQJCAIEEwiHeAYMvxWNfgoKBoEIOAYEgxWBBgOUJ5VfgySBZwkXIg
X-IronPort-AV: E=Sophos;i="4.93,507,1378857600"; d="scan'208";a="272592422"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 16 Oct 2013 14:15:56 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9GEFuIT028743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Oct 2013 14:15:56 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 09:15:55 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org WG" 
Thread-Topic: [dhcwg] What sorts of services does DHCP configure?
Thread-Index: AQHOynEYwYMFemNcIUSUMhuRl4LgSpn3W33g
Date: Wed, 16 Oct 2013 14:15:55 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk>
In-Reply-To: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 14:16:07 -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 taken, but simply because thi=
ngs 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 service=
d 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 sayi=
ng 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 p=
rovide, such as:
- Formats for encoding data into options.
- Rules about how to handle multiple instances (i.e., single option with mu=
ltiple 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 lim=
ited as this will be more fluid over the years.

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

The basic philosophy is that DHCP should be used for getting a DEVICE (clie=
nt) 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] On Behalf Of S=
imon Hobson
Sent: Wednesday, October 16, 2013 9:10 AM
To: 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=20
>> that need to be configured and infomation that needs to be delivered? An=
d as a consequence what are the tools?
>> What is in the toolbox now and what is missing? Some of the missing tool=
s 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 thi=
ngs 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 i=
mportantly, user-account centric - there is a difference) and in the genera=
l case not connected to network location.

SMTP is similarly (IMO) generally user-account specific. When I'm sending m=
ail, 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 addre=
ss 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 - th=
e client does a lookup for autoconfigure. and requests the con=
fig from it. In a large corporate environment, it's possible that they simp=
ly setup difference autoconfig servers (I assume this is an integral part o=
f Exchange but that's not something I've worked with) and configure the loc=
al DNS accordingly. Which leads on to ...

DNS. This is not as location agnostic as Ted makes out in his first post. I=
ME it's far from rare to have different views of the DNS in different locat=
ions - so accessing web.mycompanyname.com in one office may well take you t=
o 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 - whe=
rever I am I'll need to connect back to the same registrar. If the telephon=
y provider has multiple SIP registrar servers then I may well be best conne=
cting 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 u=
p 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 administrat=
ors could would out which SIP options to pass to a device depending on netw=
ork 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 st=
arting from here we wouldn't do ..." - not because the original decisions w=
ere wrong in the context in which they were taken, but simply because thing=
s have changed dramatically over the years.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

From volz@cisco.com  Wed Oct 16 07:38:42 2013
Return-Path: 
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 6594011E82EC for ; Wed, 16 Oct 2013 07:38:39 -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 XtSkDqrxeK4D for ; Wed, 16 Oct 2013 07:38:34 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 052A011E82F4 for ; Wed, 16 Oct 2013 07:37:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66111; q=dns/txt; s=iport; t=1381934271; x=1383143871; h=from:to:subject:date:message-id:mime-version; bh=qg23StrV0JWdz4BeN8J6/gkC6dfCxP2z37HfrWNGdLs=; b=N2Eg8AZBN7rrCm+pXAnms0b16rp/ChleEYCC4R1QSudR6FmZc9gy6Pix 6AKJUttUhmd7iPyoBkSIUqcED+95LJxBhUOvB8ZkxStnCkDWNT+0NKyck hsmhY7y/NW5IMtDZ0V52XnDouEqz8FBPDuGqttJAgYZkb8owsIpTELVCe 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlkHABykXlKtJV2Y/2dsb2JhbABagkNEOFK5RIhLgR0WbQeCJQEBAQQdEEEdAQgRBAEBCxYBBigRFAkJAQQTCAESh1kDDwydOpdeDYlrjGOBJQuBDQ8eCgeDGYEGA4VQjleBdIMYix2FNoMkgWgIFyI
X-IronPort-AV: E=Sophos;i="4.93,508,1378857600";  d="scan'208,217";a="269799460"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 16 Oct 2013 14:37:45 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9GEbjXN015487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Oct 2013 14:37:45 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 09:37:44 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: Reminder - Call for Agenda Items for IETF-88 (Vancouver)
Thread-Index: Ac7KfMJe1YUp8FMwSq+GYgQfVvVphQ==
Date: Wed, 16 Oct 2013 14:37:44 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD1E4B5@xmb-rcd-x04.cisco.com>
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_489D13FBFA9B3E41812EA89F188F018E1AD1E4B5xmbrcdx04ciscoc_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 16 Oct 2013 07:41:25 -0700
Subject: Re: [dhcwg] Reminder - Call for Agenda Items for IETF-88 (Vancouver)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 14:38:42 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E1AD1E4B5xmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi:

Just a reminder to submit agenda items (see earlier email below for details=
 on what you need to provide).

>From the requests so far received and assuming we accept them all and stick=
 to the requested times (which past history has shown rarely happens), we w=
ould use up 100 of out 150 minutes. I suspect we have a pretty full agenda =
as it stands now.

Tomek and I plan to review the requests this coming Monday (Oct 21st) at 11=
 AM EDT. Requests received after this time will only be accommodated on a t=
ime-available basis.

The requests so far (in pretty much the order in which they were received a=
nd NOT in the order they may appear on the agenda) are below. This also inc=
ludes the details in the request (not yet cleaned up for the agenda). If yo=
u requested time, please check it is in the list below.

The chairs (and AD) reserve the right to add "high priority" items they dee=
m important to assure forward progress by the WG.


-          Tomek & Bernie

WG Status and Administration - 10 minutes
Requested by: co-chairs
RFC-3315bis Design Team formation - 20 minutes
Requested by: Tomek
I'd like to request a 20 minutes slot for RFC3315bis work. There's no draft=
 yet. I will be the presenter. This time is needed, because 3315bis is in t=
he charter and advancement of the DHCPv6 protocol is one of primary goals o=
f this WG.
This will be more or less a follow-up discussion to the discussion that wil=
l happen soon on the mailing list (will send out an initial proposal in cou=
ple days). I'd like to discuss the following issues:
*         clarify the goal of the 3315bis work
*         scope of work:
o    coming up with a list of RFCs and drafts that we want to merge
o    coming up with a proposed list of changes + justifications why they ar=
e necessary
*         call for volunteers
*         work organisation (a "design" or "editors" team? where to store i=
ntermediate draft revisions?)
Route Problem at Relay during DHCPv6 Prefix Delegation - 10 minutes
Requested by: Alexandru Petrescu alexandru.petrescu@gmail.com
*         Title: "Route Problem at Relay during DHCPv6 Prefix Delegation"
*         Authors: under discussion, committed M. Boucadair, L. Yeh and A. =
Petrescu.
*         Time needed: 5-10 min.
*         Why time needed: because several diverging opinions were expresse=
d with respect to the problem form, and to the kind of solution (draft-sten=
berg, snoop-or-not, routing protoocol). We already discussed publicly, but =
in private people seem to diverge.
DHCP access network identifier - 10 minutes
Requested by: Shwetha Bhandari shwethab@cisco.com
We need 5 mins slot to present the revision we are planning on draft-ietf-d=
hc-access-network-identifier-00.txt and request for feed back.
*         Draft name or topic - DHCP access network identifier
*         Who will present - Shwetha Bhandari
*         How much time is needed - 5 mins
*         Why is time needed (tell us why you can't get what you need by po=
sting on the mailing list) and what will be covered - We will start the dis=
cussion on -01 on the mailer. If there is sufficient feedback received over=
 the mailer to progress the draft then this slot can be dropped. IF the mai=
ler is quiet then as it is a wg draft we may want to poll the audience duri=
ng the meeting to help review this.
We are revising the draft to address offline review comments received for a=
 specific suboption/option to disambiguate it. We will also send the detail=
s of change -01 to the wg as soon as we submit the same tentatively end of =
this week.
Secure DHCPv6 - 10 minutes
Requested by: Sheng Jiang jiangsheng@huawei.com
Yes, I would like to present this in the Vancouver. 10 minutes for presenta=
tion should be fine.
Stateless Reconfiguration - 15 minutes
Requested by: Sheng Jiang jiangsheng@huawei.com
I'd like to request a 15 minutes slot for reconfiguration in stateless DHCP=
v6 work, as URI below. I will be the presenter. This time is needed, becaus=
e this is an un-support issue in current stateless DHCPv6. It is definitely=
 in the scope of DHC WG.
http://www.ietf.org/internet-drafts/draft-jiang-dhc-stateless-reconfigurati=
on-00.txt
The authors would like to get reviews by the WG, particularly on whether th=
is problem are valid. We are also open for discussion regarding to solution=
 design. Several design questions are listed in the document for WG to deci=
de.
Handling Unknown DHCPv6 Messages - 10 minutes
Requested by: Qi Sun sunqi.csnet.thu@gmail.com
*         Name: Handling Unknown DHCPv6 Messages
*         Presenter: Qi Sun
*         Time: 5 min
*         Why: This draft describes how a DHCPv6 node handles messages with=
 unkonwn types, which RFC3315 isn't specific about. This document is on the=
 milestone.
*         What will be covered: Updates on the definition of the 'valid mes=
sage', and the text causing debates.
Address Registration - 10 minutes
Requested by: Sheng Jiang jiangsheng@huawei.com
We'd like to request a 10 minutes slot for address registration work, as UR=
I below. Suresh will be the presenter for now. This time is needed, because=
 this is a chartered item and the draft has made magnificent changes from p=
revious version.
http://tools.ietf.org/html/draft-ietf-dhc-addr-registration
The authors would like to call comments and reviewers for the current versi=
on.


From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B=
ernie Volz (volz)
Sent: Sunday, October 06, 2013 3:25 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Call for Agenda Items for IETF-88 (Vancouver)
Importance: High

Hi:

The Vancouver IETF is not that far off (Nov 3-8). See http://www.ietf.org/m=
eeting/88/index.html for more details, including venue information and impo=
rtant dates.

The preliminary agenda has the DHC WG is scheduled for TUESDAY, November 5 =
from 0900-1130 PST.

Please also note:

  *   2013-10-07 (Monday): Working Group Chair approval for initial documen=
t (Version -00) submissions appreciated by UTC 24:00.
  *   2013-10-11 (Friday): Final agenda to be published.
  *   2013-10-21 (Monday): Internet Draft submission cut-off (for all draft=
s, including -00) by UTC 24:00, upload using IETF ID Submission Tool.
We are starting the call for agenda items. The co-chairs will finalize the =
agenda about two weeks before the meeting and will give priority to items a=
s follows (in this order):


1.       WG documents with active working group discussion or that are deem=
ed critical (i.e., have upcoming milestones)

2.       WG documents with little or no discussion (provided there is a str=
ong reason for the discussion ... i.e., a higher bandwidth discussion is ne=
eded)

3.       Non WG documents with active working group discussion

4.       Non WG documents with little or no discussion

We will limit the number of presentations to reduce the chance that we don'=
t get to them all.

Please be sure to focus your presentations on issues that need discussion o=
r input (new work can include an overview, but the focus should be on issue=
s needing resolution). Status updates can be sent to the mailing list.

If you would like time, please indicate:

-          Draft name or topic

-          Who will present

-          How much time is needed

-          Why is time needed (tell us why you can't get what you need by p=
osting on the mailing list) and what will be covered

Thanks.


-          Tomek & Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E1AD1E4B5xmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi:<=
/p>

 


Just a reminder to sub=
mit agenda items (see earlier email below for details on what you need to p=
rovide).


 


From the requests so f=
ar received and assuming we accept them all and stick to the requested time=
s (which past history has shown rarely happens), we would use up 100 of out=
 150 minutes. I suspect we have a pretty
 full agenda as it stands now.


 


Tomek and I plan to re=
view the requests this coming Monday (Oct 21st) at 11 AM EDT. Re=
quests received after this time will only be accommodated on a time-availab=
le basis.


 


The requests so far (i=
n pretty much the order in which they were received and NOT in the order th=
ey may appear on the agenda) are below. This also includes the details in t=
he request (not yet cleaned up for the
 agenda). If you requested time, please check it is in the list below.=



 


The chairs (and AD) re=
serve the right to add “high priority” items they deem importan=
t to assure forward progress by the WG.


 


-&n=
bsp;        
Tomek & Be=
rnie


 



WG Status and Administration - 10 minutes


Requested by: co-chairs



RFC-3315bis Design Team formation - 20 minutes


Requested by: Tomek


I'd like to request a 20 minutes slot for RFC3=
315bis work. There's no draft yet. I will be the presenter. This time is ne=
eded, because 3315bis is in the charter and advancement
 of the DHCPv6 protocol is one of primary goals of this WG.


This will be more or less a follow-up discussi=
on to the discussion that will happen soon on the mailing list (will send o=
ut an initial proposal in couple days). I'd like to discuss
 the following issues:



·       &=
nbsp;
clarify the goa=
l of the 3315bis work



·       &=
nbsp;
scope of work:<=
o:p>



o   
coming up with =
a list of RFCs and drafts that we want to merge



o   
coming up with =
a proposed list of changes + justifications why they are necessary=




·       &=
nbsp;
call for volunt=
eers



·       &=
nbsp;
work organisati=
on (a "design" or "editors" team? where to store interm=
ediate draft revisions?)



Route Problem at Relay during DHCPv6 Prefix Delegation - 10 m=
inutes


Requested by: Alexandru Petrescu alexandru.petrescu@gmail.com<=
/p>


·       &=
nbsp;
Title: "Ro=
ute Problem at Relay during DHCPv6 Prefix Delegation"



·       &=
nbsp;
Authors: under =
discussion, committed M. Boucadair, L. Yeh and A. Petrescu.



·       &=
nbsp;
Time needed: 5-=
10 min.



·       &=
nbsp;
Why time needed=
: because several diverging opinions were expressed with respect to the pro=
blem form, and to the kind of solution (draft-stenberg,
 snoop-or-not, routing protoocol). We already discussed publicly, but in pr=
ivate people seem to diverge.



DHCP access network identifier - 10 minutes=



Requested by: Shwetha Bhandari shwethab@cisco.com


We need 5 mins slot to present the revision we=
 are planning on draft-ietf-dhc-access-network-identifier-00.txt and reques=
t for feed back.



·       &=
nbsp;
Draft name or t=
opic – DHCP access network identifier



·       &=
nbsp;
Who will presen=
t – Shwetha Bhandari



·       &=
nbsp;
How much time i=
s needed – 5 mins



·       &=
nbsp;
Why is time nee=
ded (tell us why you can’t get what you need by posting on the mailin=
g list) and what will be covered – We will start the discussion
 on –01 on the mailer. If there is sufficient feedback received over =
the mailer to progress the draft then this slot can be dropped. IF the mail=
er is quiet then as it is a wg draft we may want to poll the audience durin=
g the meeting to help review this.


We are revising the draft to address offline r=
eview comments received for a specific suboption/option to disambiguate it.=
 We will also send the details of change –01 to the wg
 as soon as we submit the same tentatively end of this week.



=
Secure DHCPv6 - 10 minutes


Requested by: Sheng Jiang jiangsheng@huawei.com


Yes, I would like to present this in the Vanco=
uver. 10 minutes for presentation should be fine.



Stateless Reconfiguration - 15 minutes

Requested by: Sheng Jiang jiangsheng@huawei.com


I'd like to request a 15 minutes slot for reco=
nfiguration in stateless DHCPv6 work, as URI below. I will be the presenter=
. This time is needed, because this is an un-support issue
 in current stateless DHCPv6. It is definitely in the scope of DHC WG.=



http://www.ietf.org/internet-drafts/draft-jiang-=
dhc-stateless-reconfiguration-00.txt


The authors would like to get reviews by the W=
G, particularly on whether this problem are valid. We are also open for dis=
cussion regarding to solution design. Several design questions
 are listed in the document for WG to decide.



Handling Unknown DHCPv6 Messages - 10 minutes


Requested by: Qi Sun sunqi.csnet.thu@gmail.com



·       &=
nbsp;
Name: Handling =
Unknown DHCPv6 Messages



·       &=
nbsp;
Presenter: Qi S=
un



·       &=
nbsp;
Time: 5 min



·       &=
nbsp;
Why: This draft=
 describes how a DHCPv6 node handles messages with unkonwn types, which RFC=
3315 isn't specific about. This document is on the milestone.



·       &=
nbsp;
What will be co=
vered: Updates on the definition of the 'valid message', and the text causi=
ng debates.



Address Registration - 10 minutes


Requested by: Sheng Jiang jiangsheng@huawei.com


We'd like to request a 10 minutes slot for add=
ress registration work, as URI below. Suresh will be the presenter for now.=
 This time is needed, because this is a chartered item
 and the draft has made magnificent changes from previous version.


http://tools.ietf.org/html/draft-ietf-dhc-addr-registration


The authors would like to call comments and re=
viewers for the current version.


 


 






From: dhcwg-bo=
unces@ietf.org [mailto:dhcwg-bounces@ietf.org]
On Behalf Of Bernie Volz (volz)

Sent: Sunday, October 06, 2013 3:25 PM

To: dhcwg@ietf.org

Subject: [dhcwg] Call for Agenda Items for IETF-88 (Vancouver)

Importance: High






 


Hi:

 =



The Vancouver IETF is not that far off (Nov 3-8). Se=
e 
http://www.ietf.org/meeting/88/index.html<=
/span> for more details, including venue information and important date=
s.


 


The preliminary agenda has the DHC WG is scheduled f=
or TUESDAY, November 5 from 0900-1130 PST.


 


Please also note:


    

  • 
2013-10-07 (Monday): Working G=
roup Chair approval for initial document (Version -00) submissions apprecia=
ted by
 UTC 24:00.
  • 
2013-10-11 (Friday): Final age=
nda to be published.
  • 
2013-10-21 (Monday): Internet =
Draft submission cut-off (for all drafts, including -00) by UTC 24:00, uplo=
ad using IETF
 ID Submission Tool.


We are starting the call for agenda items. The co-ch=
airs will finalize the agenda about two weeks before the meeting and will g=
ive priority to items as follows (in this order):


 =



1.&nbs=
p;     
WG documents wit=
h active working group discussion or that are deemed critical (i.e., have u=
pcoming milestones)


2.&nbs=
p;     
WG documents wit=
h little or no discussion (provided there is a strong reason for the discus=
sion … i.e., a higher bandwidth discussion is needed)


3.&nbs=
p;     
Non WG documents=
 with active working group discussion


4.&nbs=
p;     
Non WG documents=
 with little or no discussion


 =



We will limit the number=
 of presentations to reduce the chance that we don’t get to them all.=



 


Please be sure to focus your presentations on issues=
 that need discussion or input (new work can include an overview, but the f=
ocus should be on issues needing resolution). Status updates can be sent to=
 the mailing list.


 =



If you would like time, =
please indicate:


- =
;        
Draft name or to=
pic


- =
;        
Who will present=



- =
;        
How much time is=
 needed


- =
;        
Why is time need=
ed (tell us why you can’t get what you need by posting on the mailing=
 list) and what will be covered


 =



Thanks.


 =



- =
;        
Tomek & Bern=
ie






--_000_489D13FBFA9B3E41812EA89F188F018E1AD1E4B5xmbrcdx04ciscoc_--

From stenc@s-carlsen.dk  Wed Oct 16 07:48:53 2013
Return-Path: 
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 8C38F11E82A8 for ; Wed, 16 Oct 2013 07:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 WifzF956vwta for ; Wed, 16 Oct 2013 07:48:52 -0700 (PDT)
Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id ACCA411E81D3 for ; Wed, 16 Oct 2013 07:48:51 -0700 (PDT)
Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 66EB53264 for ; Wed, 16 Oct 2013 16:48:33 +0200 (CEST)
Message-ID: <525EA740.7000902@s-carlsen.dk>
Date: Wed, 16 Oct 2013 16:48:32 +0200
From: Sten Carlsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------000602020406020601090909"
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 14:48:53 -0000

This is a multi-part message in MIME format.
--------------000602020406020601090909
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


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] On Behalf Of Simon Hobson
> Sent: Wednesday, October 16, 2013 9:10 AM
> To: 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. 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
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


--------------000602020406020601090909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
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] On Behalf Of Simon Hobson
Sent: Wednesday, October 16, 2013 9:10 AM
To: 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
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


    

    

    
-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


  


--------------000602020406020601090909--

From Ted.Lemon@nominum.com  Wed Oct 16 07:52:04 2013
Return-Path: 
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 5AB9C11E81DA for ; Wed, 16 Oct 2013 07:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.59
X-Spam-Level: 
X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 w4r79bqaXcpE for ; Wed, 16 Oct 2013 07:51:57 -0700 (PDT)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 14F8221F9C7D for ; Wed, 16 Oct 2013 07:51:56 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUl6oDNd/XziezghsFoe1RBS5IR6Q2cYj@postini.com; Wed, 16 Oct 2013 07:51:57 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1C07F1B8087 for ; Wed, 16 Oct 2013 07:51:56 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 04B2F19005C; Wed, 16 Oct 2013 07:51:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Oct 2013 07:51:50 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com>
Date: Wed, 16 Oct 2013 10:51:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <9430A0E8-D3B4-403D-BDD2-676020E89CEF@nominum.com>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com>
To: "Bernie Volz (volz)" 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org WG" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 14:52:04 -0000

On Oct 16, 2013, at 10:15 AM, Bernie Volz (volz)  wrote:
> 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.

Yup, that's my thinking as well.


From volz@cisco.com  Wed Oct 16 08:01:25 2013
Return-Path: 
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 ; 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 ; 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 ; 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)" 
To: Sten Carlsen , "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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:01:25 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E1AD1E5A1xmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> 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 t=
hose configurations?

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

Again ... The basic philosophy is that DHCP should be used for getting a DE=
VICE (client) connectivity to a network and network resources needed for co=
nnectivity, 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 m=
achine" 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 certa=
inly 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 (clie=
nt) 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 m=
ight want to use.


-          Bernie


From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of S=
ten 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 st=
arting from here we wouldn't do ..." - not because the original decisions w=
ere wrong in the context in which they were taken, but simply because thing=
s 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 service=
d 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 sayi=
ng 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 a=
ll those things be done over DHCP and another question, who will decide tho=
se configurations?

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






The option guidelines should focus on providing information we can safely p=
rovide, such as:

- Formats for encoding data into options.

- Rules about how to handle multiple instances (i.e., single option with mu=
ltiple 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 lim=
ited as this will be more fluid over the years.



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



The basic philosophy is that DHCP should be used for getting a DEVICE (clie=
nt) 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-b=
ounces@ietf.org] On Behalf Of Simon Hobson

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

To: 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 a=
s a consequence what are the tools?

What is in the toolbox now and what is missing? Some of the missing tools a=
re 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 thi=
ngs 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 i=
mportantly, user-account centric - there is a difference) and in the genera=
l case not connected to network location.



SMTP is similarly (IMO) generally user-account specific. When I'm sending m=
ail, 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 addre=
ss 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 - th=
e client does a lookup for autoconfigure. and requests the con=
fig from it. In a large corporate environment, it's possible that they simp=
ly setup difference autoconfig servers (I assume this is an integral part o=
f Exchange but that's not something I've worked with) and configure the loc=
al DNS accordingly. Which leads on to ...



DNS. This is not as location agnostic as Ted makes out in his first post. I=
ME it's far from rare to have different views of the DNS in different locat=
ions - so accessing web.mycompanyname.com in one office may well take you t=
o 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 - whe=
rever I am I'll need to connect back to the same registrar. If the telephon=
y provider has multiple SIP registrar servers then I may well be best conne=
cting 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 u=
p 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 administrat=
ors could would out which SIP options to pass to a device depending on netw=
ork 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 st=
arting from here we wouldn't do ..." - not because the original decisions w=
ere wrong in the context in which they were taken, but simply because thing=
s have changed dramatically over the years.

_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

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

_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

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



--

Best regards



Sten Carlsen



No improvements come from shouting:



       "MALE BOVINE MANURE!!!"

--_000_489D13FBFA9B3E41812EA89F188F018E1AD1E5A1xmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











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


 <=
/p>

That’s exactly my p=
oint 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 th=
ing to use
 for some future application for the IoT or IoE (Everything).


 <=
/p>

Again … The basic p=
hilosophy is that DHCP should be used for getting a DEVICE (client) connect=
ivity to a network and network resources needed for connectivity,
 not to configure all of the services a USER might want to use.<=
/span>


 <=
/p>

USER here is probably cha=
nging as well since a “refrigerator” or “washing machine&=
#8221; is not a USER as we traditional think about it. And, while perhaps n=
ot “low
 power” in these examples, at least some of these devices are certain=
ly likely to be somewhat limited in their capabilities.

 <=
/p>

So, perhaps my basic phil=
osophy statement needs to be revised:


 <=
/p>

The basic philosophy is t=
hat DHCP should be used for getting a DEVICE (client) connectivity to a net=
work 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.


 <=
/p>

- =
        
Bernie=



 <=
/span>






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 origi=
nal decisions were wrong in the context in which they were taken, but simpl=
y 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 se=
rviced 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 questi=
on, who will decide those configurations?



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






 


 


The option guidelines should focus on providing information we can saf=
ely provide, such as:


- Formats for encoding data into options.


- Rules about how to handle multiple instances (i.e., single option wi=
th multiple values is generally better than multiple options) and that orde=
r 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 b=
e limited as this will be more fluid over the years.


 


Please don't flame this as I'm not suggesting user settings will be co=
nfigured 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 connect=
ivity, not to configure all of the services a USER might want to use.<=
/o:p>


 


- Bernie


 


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


From: dhcwg-bounces@ietf.org=
 [mailto:dhcwg-bounces@ietf.o=
rg] On Behalf Of Simon Hobson


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


To: dhcwg@ietf.org WG=



Subject: Re: [dhcwg] What sorts of services does DHCP configure?<=
/o:p>


 


"Reinaldo Penno (repenno)" wrote:


Sten Carlsen wrote:






I tend to look at this from the opposite side, what are the services <=
o:p>


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 to=
ols 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 fo=
r 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 m=
ore importantly, user-account centric - there is a difference) and in the g=
eneral case not connected to network location.


 


SMTP is similarly (IMO) generally user-account specific. When I'm send=
ing 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 a=
nd 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 DHC=
P 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 reque=
sts the config from it. In a large corporate environment, it's possible tha=
t they simply setup difference autoconfig servers (I assume this is an inte=
gral part of Exchange but that's not something I've worked with) and config=
ure the local DNS accordingly. Which leads on to ...


 


DNS. This is not as location agnostic as Ted makes out in his first po=
st. 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 o=
ffice and this same FQDN may well resolve to a different IP. Anycast addres=
sing 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 wel=
l 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 curr=
ently the best (or least bad ?) way of configuring things. For devices that=
 are only intended to work within the corporate network, the various admini=
strators 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 be=
tter 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 origi=
nal decisions were wrong in the context in which they were taken, but simpl=
y because things have changed dramatically over the years.


_______________________________________________


dhcwg mailing list


dhcwg@ietf.org


https://www.ie=
tf.org/mailman/listinfo/dhcwg


_______________________________________________


dhcwg mailing list


dhcwg@ietf.org


https://www.ie=
tf.org/mailman/listinfo/dhcwg









-- 


Best regards


 


Sten Carlsen


 


No improvements come from shouting:


 


       "MALE BOVINE MANURE!!!"=
 






--_000_489D13FBFA9B3E41812EA89F188F018E1AD1E5A1xmbrcdx04ciscoc_--

From stenc@s-carlsen.dk  Wed Oct 16 08:10:34 2013
Return-Path: 
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 38D5911E81DE for ; Wed, 16 Oct 2013 08:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level: 
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 S4zwjxVtJRXZ for ; Wed, 16 Oct 2013 08:10:27 -0700 (PDT)
Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 0A67511E82B3 for ; Wed, 16 Oct 2013 08:10:18 -0700 (PDT)
Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id B487426C9; Wed, 16 Oct 2013 17:10:16 +0200 (CEST)
Message-ID: <525EAC58.5060009@s-carlsen.dk>
Date: Wed, 16 Oct 2013 17:10:16 +0200
From: Sten Carlsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "Bernie Volz (volz)" , "dhcwg@ietf.org" 
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk>	<489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <525EA740.7000902@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1AD1E5A1@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD1E5A1@xmb-rcd-x04.cisco.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------060703060301050100080600"
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:10:34 -0000

This is a multi-part message in MIME format.
--------------060703060301050100080600
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


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.
>
>  
>
> 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.
>
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:*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] On Behalf Of Simon Hobson
> Sent: Wednesday, October 16, 2013 9:10 AM
> To: 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. 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 
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org 
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
> -- 
> Best regards
>  
> Sten Carlsen
>  
> No improvements come from shouting:
>  
>        "MALE BOVINE MANURE!!!" 

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


--------------060703060301050100080600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
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.

        
 

        
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.

      

    

    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:
                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] On Behalf Of Simon Hobson

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

        
To: 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

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

        
_______________________________________________

        
dhcwg mailing list

        
dhcwg@ietf.org

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

        


          

          

        
-- 

        
Best regards

        
 

        
Sten Carlsen

        
 

        
No improvements come from shouting:

        
 

        
       "MALE BOVINE MANURE!!!" 

      

    

    

    
-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


  


--------------060703060301050100080600--

From Ted.Lemon@nominum.com  Wed Oct 16 08:15:07 2013
Return-Path: 
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 6466A11E8289 for ; Wed, 16 Oct 2013 08:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.59
X-Spam-Level: 
X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 7VTwhYCkxFwy for ; Wed, 16 Oct 2013 08:15:00 -0700 (PDT)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id C49AD11E82BE for ; Wed, 16 Oct 2013 08:14:55 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUl6tb0xWpz1VUUGAfWIhBZJLP2gFng1R@postini.com; Wed, 16 Oct 2013 08:14:55 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 426BC1B82B6 for ; Wed, 16 Oct 2013 08:14:55 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3B15419005C; Wed, 16 Oct 2013 08:14:55 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Oct 2013 08:14:55 -0700
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <525EA740.7000902@s-carlsen.dk>
Date: Wed, 16 Oct 2013 11:14:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <525EA740.7000902@s-carlsen.dk>
To: Sten Carlsen 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org WG" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:15:07 -0000

On Oct 16, 2013, at 10:48 AM, Sten Carlsen  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?
> 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 draghuva@cisco.com  Wed Oct 16 08:16:49 2013
Return-Path: 
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 3E31F11E82AA for ; Wed, 16 Oct 2013 08:16:49 -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 XA2hiPvaNzwf for ; Wed, 16 Oct 2013 08:16:44 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 84D4211E8289 for ; Wed, 16 Oct 2013 08:16:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22547; q=dns/txt; s=iport; t=1381936594; x=1383146194; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=oFqcy8/T3YlsU6/Lia8R1ek19efof4ntZgOC4ftrQSk=; b=Kk1Kttb19+6uefGgTQPZUvXgwsOo+Zzx58x5Gxlb9WxxyBf6z4bq3fY1 RUbrOAKvr+mcTUzeLF78SqXxnPf+6U0zxfoB3bOjyhGCLddtW/2xOfqHL jPRCSDspvsA8WvlU5R+W25ItcrCPyp3WmKkjFzL45Vomqhf0h0SGc8SFE A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIGAICtXlKtJXHA/2dsb2JhbABagkNEOFLCD4EdFm0HgiUBAQEEHQwEQQsSAQIGEQMBAgsWBzkUCQgCBA4FCAGHfQy/JI4TgQ0gDQQGAYMfgQYDlCeVX4MkgWhB
X-IronPort-AV: E=Sophos;i="4.93,508,1378857600";  d="scan'208,217";a="272898887"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 16 Oct 2013 15:16:08 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9GFG7UQ030559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Oct 2013 15:16:07 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.78]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 10:16:07 -0500
From: "Dushyant Raghuvanshi (draghuva)" 
To: "dhcwg@ietf.org" 
Thread-Topic: [dhcwg] Call for Agenda Items for IETF-88 (Vancouver)
Thread-Index: AQHOyoKi1Jfwt+YnGUGb4k7XVoTSnA==
Importance: high
X-Priority: 1
Date: Wed, 16 Oct 2013 15:16:06 +0000
Message-ID: <0A2ED610A80E7B4DBCC8E63B8E7EE430271338DA@xmb-rcd-x02.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ACF6595@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.79.253]
Content-Type: multipart/alternative; boundary="_000_0A2ED610A80E7B4DBCC8E63B8E7EE430271338DAxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "Bernie Volz \(volz\)" , "Kim Kinnear \(kkinnear\)" 
Subject: Re: [dhcwg] Call for Agenda Items for IETF-88 (Vancouver)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:16:50 -0000

--_000_0A2ED610A80E7B4DBCC8E63B8E7EE430271338DAxmbrcdx02ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

We would need 10-15 min to present the idea proposed in draft-raghuvanshi-d=
hc-dhcpv6-active-leasequery-00.
Either Bernie Volz or Kim Kinnear will be the presenter.

The time is needed to describe the idea proposed in the draft and get feedb=
ack on the same.

Thanks,
Dushyant.

From: "Bernie Volz (volz)" >
Date: Monday, 7 October 2013 12:54 AM
To: "dhcwg@ietf.org" >
Subject: [dhcwg] Call for Agenda Items for IETF-88 (Vancouver)

Hi:

The Vancouver IETF is not that far off (Nov 3-8). See http://www.ietf.org/m=
eeting/88/index.html for more details, including venue information and impo=
rtant dates.

The preliminary agenda has the DHC WG is scheduled for TUESDAY, November 5 =
from 0900-1130 PST.

Please also note:

  *   2013-10-07 (Monday): Working Group Chair approval for initial documen=
t (Version -00) submissions appreciated by UTC 24:00.
  *   2013-10-11 (Friday): Final agenda to be published.
  *   2013-10-21 (Monday): Internet Draft submission cut-off (for all draft=
s, including -00) by UTC 24:00, upload using IETF ID Submission Tool.
We are starting the call for agenda items. The co-chairs will finalize the =
agenda about two weeks before the meeting and will give priority to items a=
s follows (in this order):


1.       WG documents with active working group discussion or that are deem=
ed critical (i.e., have upcoming milestones)

2.       WG documents with little or no discussion (provided there is a str=
ong reason for the discussion =85 i.e., a higher bandwidth discussion is ne=
eded)

3.       Non WG documents with active working group discussion

4.       Non WG documents with little or no discussion

We will limit the number of presentations to reduce the chance that we don=
=92t get to them all.

Please be sure to focus your presentations on issues that need discussion o=
r input (new work can include an overview, but the focus should be on issue=
s needing resolution). Status updates can be sent to the mailing list.

If you would like time, please indicate:

-          Draft name or topic

-          Who will present

-          How much time is needed

-          Why is time needed (tell us why you can=92t get what you need by=
 posting on the mailing list) and what will be covered

Thanks.


-          Tomek & Bernie

--_000_0A2ED610A80E7B4DBCC8E63B8E7EE430271338DAxmbrcdx02ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <9046A500804E4B47BD413645BB2C95E2@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi,







We wou=
ld need 10-15 min to present the idea proposed in draft-raghuvanshi-dh=
c-dhcpv6-active-leasequery-00.


Either=
 Bernie Volz or Kim Kinnear will be the presenter.







The ti=
me is needed to describe the idea proposed in the draft and get feedback on=
 the same.







Thanks,


Dushyant.









From: "Bernie Volz (volz)"=
; <volz@cisco.com>

Date: Monday, 7 October 2013 12:54 =
AM

To: "dhcwg@ietf.org" <dhc=
wg@ietf.org>

Subject: [dhcwg] Call for Agenda It=
ems for IETF-88 (Vancouver)

















Hi:

 =



The Vancouver IETF is not that far off (Nov 3-8). Se=
e 
http://www.ietf.org/meeting/88/index.html<=
/span> for more details, including venue information and important date=
s.


 


The preliminary agenda has the DHC WG is scheduled f=
or TUESDAY, November 5 from 0900-1130 PST.


 


Please also note:


    

  • 
2013=
-10-07 (Monday): Working Group Chair approval for initial document=
 (Version -00) submissions appreciated by
 UTC 24:00.
  • 
2013=
-10-11 (Friday): Final agenda to be published.
  • 
2013=
-10-21 (Monday): Internet Draft submission cut-off (for all drafts=
, including -00) by UTC 24:00, upload using IETF
 ID Submission Tool.


We are starting the call for agenda items. The co-ch=
airs will finalize the agenda about two weeks before the meeting and will g=
ive priority to items as follows (in this order):


 =



1.      
WG documents=
 with active working group discussion or that are deemed critical (i.e., ha=
ve upcoming milestones)


2.      
WG documents=
 with little or no discussion (provided there is a strong reason for the di=
scussion =85 i.e., a higher bandwidth discussion is needed)


3.      
Non WG docum=
ents with active working group discussion


4.      
Non WG docum=
ents with little or no discussion


 =



We will limit the number=
 of presentations to reduce the chance that we don=92t get to them all.


 


Please be sure to focus your presentations on issues=
 that need discussion or input (new work can include an overview, but the f=
ocus should be on issues needing resolution). Status updates can be sent to=
 the mailing list.


 =



If you would like time, =
please indicate:


-         
Draft name o=
r topic


-         
Who will pre=
sent


-         
How much tim=
e is needed


-         
Why is time =
needed (tell us why you can=92t get what you need by posting on the mailing=
 list) and what will be covered


 =



Thanks.


 =



-         
Tomek & =
Bernie











--_000_0A2ED610A80E7B4DBCC8E63B8E7EE430271338DAxmbrcdx02ciscoc_--

From repenno@cisco.com  Wed Oct 16 08:17:26 2013
Return-Path: 
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 18DCA11E82C7 for ; Wed, 16 Oct 2013 08:17: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=[AWL=-0.000, 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 4ioiXViVOi4f for ; Wed, 16 Oct 2013 08:17:20 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4E50D11E81D3 for ; Wed, 16 Oct 2013 08:17:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30318; q=dns/txt; s=iport; t=1381936640; x=1383146240; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=CdJ+wcJmEesDtBREmegCL0dFDg6StH9qZwI9ehEeVu8=; b=DsTJkPfoNF+MlS7iKOGhL13HpZlS5Qr+j7F7GcQb6U01TnHS08rW+J8y 8YE3a7IdBq+3XxkXxOyZbwnbKX9q2PEau1cX5SZIhE5X3uWFQuLZCQhL/ mSnv/lzIXOU2t2CJ5LtH4pDQFR8XMDzT6RFWUOxkBpu2XKTZfpfcIsp9B k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAJasXlKtJV2c/2dsb2JhbABagkNEOFLCD4EdFnSCJQEBAQMBAQEBKkEQBwYBCBEDAQEBAQoLCwcuCxQJCAIEARIIh3gGDL8kjX4KCgYBgQcgFwEGBIMVgQYDlCeVX4MkgWcJFyI
X-IronPort-AV: E=Sophos;i="4.93,508,1378857600";  d="scan'208,217";a="272832030"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 16 Oct 2013 15:17:19 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9GFHJur015508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 15:17:19 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 10:17:18 -0500
From: "Reinaldo Penno (repenno)" 
To: Sten Carlsen , "Bernie Volz (volz)" ,  "dhcwg@ietf.org" 
Thread-Topic: [dhcwg] What sorts of services does DHCP configure?
Thread-Index: AQHOynEUiAXKk6KM3ESJzga2BnKmuZn3s2OAgAAJHQCAAAOQgIAAAoMA//+MnYA=
Date: Wed, 16 Oct 2013 15:17:18 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B736153@xmb-rcd-x04.cisco.com>
In-Reply-To: <525EAC58.5060009@s-carlsen.dk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.68.203]
Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F06040B736153xmbrcdx04ciscoc_"
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:17:26 -0000

--_000_45A697A8FFD7CF48BCF2BE7E106F06040B736153xmbrcdx04ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

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 li=
ne between USER and DEVICE and that might be interesting to look at so our =
decisions as well founded.



From: Sten Carlsen >
Date: Wednesday, October 16, 2013 8:10 AM
To: "Bernie Volz (volz)" >, "dhcwg@ie=
tf.org" >
Subject: Re: [dhcwg] What sorts of services does DHCP configure?


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 t=
hose configurations?

That=92s exactly my point about the future =96 we just don=92t know what wi=
ll come down the road. And in a =93home=94 network, DHCP might well be a go=
od thing to use for some future application for the IoT or IoE (Everything)=
.

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

USER here is probably changing as well since a =93refrigerator=94 or =93was=
hing machine=94 is not a USER as we traditional think about it. And, while =
perhaps not =93low power=94 in these examples, at least some of these devic=
es 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 (clie=
nt) 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 m=
ight 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 shoul=
d provide
2 - All the other configurations that today are handled by DHCP that we thi=
nk don't belong there.

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


-          Bernie


From:dhcwg-bounces@ietf.org [mailto:dhcwg-bo=
unces@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 st=
arting from here we wouldn't do ..." - not because the original decisions w=
ere wrong in the context in which they were taken, but simply because thing=
s 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 service=
d 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 sayi=
ng 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 a=
ll those things be done over DHCP and another question, who will decide tho=
se configurations?

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






The option guidelines should focus on providing information we can safely p=
rovide, such as:

- Formats for encoding data into options.

- Rules about how to handle multiple instances (i.e., single option with mu=
ltiple 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 lim=
ited as this will be more fluid over the years.



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



The basic philosophy is that DHCP should be used for getting a DEVICE (clie=
nt) 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-b=
ounces@ietf.org] On Behalf Of Simon Hobson

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

To: 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 a=
s a consequence what are the tools?

What is in the toolbox now and what is missing? Some of the missing tools a=
re 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 thi=
ngs 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 i=
mportantly, user-account centric - there is a difference) and in the genera=
l case not connected to network location.



SMTP is similarly (IMO) generally user-account specific. When I'm sending m=
ail, 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 addre=
ss 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 - th=
e client does a lookup for autoconfigure. and requests the con=
fig from it. In a large corporate environment, it's possible that they simp=
ly setup difference autoconfig servers (I assume this is an integral part o=
f Exchange but that's not something I've worked with) and configure the loc=
al DNS accordingly. Which leads on to ...



DNS. This is not as location agnostic as Ted makes out in his first post. I=
ME it's far from rare to have different views of the DNS in different locat=
ions - so accessing web.mycompanyname.com in one office may well take you t=
o 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 - whe=
rever I am I'll need to connect back to the same registrar. If the telephon=
y provider has multiple SIP registrar servers then I may well be best conne=
cting 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 u=
p 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 administrat=
ors could would out which SIP options to pass to a device depending on netw=
ork 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 st=
arting from here we wouldn't do ..." - not because the original decisions w=
ere wrong in the context in which they were taken, but simply because thing=
s have changed dramatically over the years.

_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

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

_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

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



--

Best regards



Sten Carlsen



No improvements come from shouting:



       "MALE BOVINE MANURE!!!"


--
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"


--_000_45A697A8FFD7CF48BCF2BE7E106F06040B736153xmbrcdx04ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







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 t=
he line between USER and DEVICE and that might be interesting to look at so=
 our decisions as well founded. 



















From: Sten Carlsen <stenc@s-carlsen.dk>

Date: Wednesday, October 16, 2013 8=
:10 AM

To: "Bernie Volz (volz)" =
<volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>

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














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 don=
e over DHCP and another question, who will
 decide those configurations?


 


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


 


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


 


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


 


So, perhaps my basic philosophy st=
atement 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 mi=
ght 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 shoul=
d provide

2 - All the other configurations that today are handled by DHCP that we thi=
nk don't belong there.



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








 


-     =
    
Bernie


 





From:dhcwg-bou=
nces@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 origi=
nal decisions were wrong in the context in which they were taken, but simpl=
y 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 se=
rviced 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 questi=
on, who will decide those configurations?



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






 


 


The option guidelines should focus on providing information we can saf=
ely provide, such as:


- Formats for encoding data into options.


- Rules about how to handle multiple instances (i.e., single option wi=
th multiple values is generally better than multiple options) and that orde=
r 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 b=
e limited as this will be more fluid over the years.


 


Please don't flame this as I'm not suggesting user settings will be co=
nfigured 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 connect=
ivity, not to configure all of the services a USER might want to use.<=
/o:p>


 


- Bernie


 


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


From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simo=
n Hobson


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


To: dhcwg@i=
etf.org WG


Subject: Re: [dhcwg] What sorts of services does DHCP configure?<=
/o:p>


 


"Reinaldo Penno (repenno)" wrote:


Sten Carlsen wrote:






I tend to look at this from the opposite side, what are the services <=
o:p>


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 to=
ols 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 fo=
r 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 m=
ore importantly, user-account centric - there is a difference) and in the g=
eneral case not connected to network location.


 


SMTP is similarly (IMO) generally user-account specific. When I'm send=
ing 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 a=
nd 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 DHC=
P 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 reque=
sts the config from it. In a large corporate environment, it's possible tha=
t they simply setup difference autoconfig servers (I assume this is an inte=
gral part of Exchange but that's not something I've worked with) and config=
ure the local DNS accordingly. Which leads on to ...


 


DNS. This is not as location agnostic as Ted makes out in his first po=
st. 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 o=
ffice and this same FQDN may well resolve to a different IP. Anycast addres=
sing 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 wel=
l 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 curr=
ently the best (or least bad ?) way of configuring things. For devices that=
 are only intended to work within the corporate network, the various admini=
strators 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 be=
tter 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 origi=
nal decisions were wrong in the context in which they were taken, but simpl=
y because things have changed dramatically over the years.


_______________________________________________


dhcwg mailing list


dhcwg@ietf.=
org


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


_______________________________________________


dhcwg mailing list


dhcwg@ietf.=
org


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









-- 


Best regards


 


Sten Carlsen


 


No improvements come from shouting:


 


       "MALE BOVINE MANURE!!!"=
 








--=20
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"=20










--_000_45A697A8FFD7CF48BCF2BE7E106F06040B736153xmbrcdx04ciscoc_--

From Ted.Lemon@nominum.com  Wed Oct 16 08:26:19 2013
Return-Path: 
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 2283321F9FAE for ; Wed, 16 Oct 2013 08:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 W7qUDyL-xTZE for ; Wed, 16 Oct 2013 08:26:12 -0700 (PDT)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 43BD421F9C7D for ; Wed, 16 Oct 2013 08:26:10 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUl6wEUdRjK5pVoJC2BXauWusKJxQGJWC@postini.com; Wed, 16 Oct 2013 08:26:10 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BD33E1B82E5 for ; Wed, 16 Oct 2013 08:26:09 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9C8E719005C; Wed, 16 Oct 2013 08:26:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Oct 2013 08:26:09 -0700
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <525EAC58.5060009@s-carlsen.dk>
Date: Wed, 16 Oct 2013 11:26:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk>	<489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <525EA740.7000902@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1AD1E5A1@xmb-rcd-x04.cisco.com> <525EAC58.5060009@s-carlsen.dk>
To: Sten Carlsen 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:26:19 -0000

On Oct 16, 2013, at 11:10 AM, Sten Carlsen  wrote:
> 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 Ted.Lemon@nominum.com  Wed Oct 16 08:30:18 2013
Return-Path: 
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 9408C11E82F3 for ; Wed, 16 Oct 2013 08:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 4HKgBR1jhrEO for ; Wed, 16 Oct 2013 08:30:12 -0700 (PDT)
Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0D06A11E82DA for ; Wed, 16 Oct 2013 08:30:11 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUl6xA97uspwtcifZeGTjBmD6cIy2ynRz@postini.com; Wed, 16 Oct 2013 08:30:12 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 97DD91B82E4 for ; Wed, 16 Oct 2013 08:30:11 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8ECD219005C; Wed, 16 Oct 2013 08:30:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Oct 2013 08:30:11 -0700
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <525DC8E1.8050208@s-carlsen.dk>
Date: Wed, 16 Oct 2013 11:30:08 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <45A697A8FFD7CF48BCF2BE7E106F06040B734A24@xmb-rcd-x04.cisco.com> <771CAC3B-56AD-445E-AC97-75D6CB4521DB@nominum.com> <525DBC60.1080209@s-carlsen.dk> <1ABC4971-1E44-4146-BEF5-A6BB3146E137@nominum.com> <525DC09B.5080703@s-carlsen.dk> <71D33595-0CE9-42CD-A572-D6C80DA9BA74@nominum.com> <525DC8E1.8050208@s-carlsen.dk>
To: Sten Carlsen 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org WG" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:30:18 -0000

On Oct 15, 2013, at 6:59 PM, 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?

I don't think the missing tools are causing us to do ugly hacks.   I =
think that the problems I am talking about are actually being handled =
perfectly well.   E.g., SMTP is generally configured manually by the end =
user, and there is no way to make this better using DHCP, which is why =
it hasn't been done.   NTP is generally hard-coded as an FQDN into the =
operating system, but overridable by the end-user.

Although there is an NTP option for DHCP, and it is implemented in some =
cases, it is not widely used, for reasons that seem obvious to me: NTP =
is required for replay detection, and so trusting the DHCP server to =
tell you what your NTP server is isn't secure.   There is actually a =
standard in the RFC editor queue that makes support for the NTP option =
mandatory in home routers, which I expect will happen, and I expect that =
roughly zero devices will actually request this option on a home =
network.   It's possible that IoT devices will, but I'll believe it when =
I see it.


From stenc@s-carlsen.dk  Wed Oct 16 08:50:25 2013
Return-Path: 
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 801C911E82D7 for ; Wed, 16 Oct 2013 08:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level: 
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 zJew7jg2eam7 for ; Wed, 16 Oct 2013 08:50:24 -0700 (PDT)
Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 369E811E8146 for ; Wed, 16 Oct 2013 08:50:22 -0700 (PDT)
Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id B04D63D6A; Wed, 16 Oct 2013 17:50:19 +0200 (CEST)
Message-ID: <525EB5BB.7020602@s-carlsen.dk>
Date: Wed, 16 Oct 2013 17:50:19 +0200
From: Sten Carlsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Ted Lemon 
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk>	<489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <525EA740.7000902@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1AD1E5A1@xmb-rcd-x04.cisco.com> <525EAC58.5060009@s-carlsen.dk> 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------070701040502030504030804"
Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 15:50:25 -0000

This is a multi-part message in MIME format.
--------------070701040502030504030804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


On 16/10/13 17:26, Ted Lemon wrote:
> On Oct 16, 2013, at 11:10 AM, Sten Carlsen  wrote:
>> 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.
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

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


--------------070701040502030504030804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 16/10/13 17:26, Ted Lemon wrote:

    

    

      
On Oct 16, 2013, at 11:10 AM, Sten Carlsen <stenc@s-carlsen.dk> wrote:


      

        
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.

    

    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

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


  


--------------070701040502030504030804--

From Ted.Lemon@nominum.com  Wed Oct 16 10:41:08 2013
Return-Path: 
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 00A6211E82E2 for ; Wed, 16 Oct 2013 10:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 MS0zQMmWb5yH for ; Wed, 16 Oct 2013 10:41:00 -0700 (PDT)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 58A5621F8D20 for ; Wed, 16 Oct 2013 10:41:00 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUl7Pq4t1sxx7JDXM8gaoraoZLUZlKCyg@postini.com; Wed, 16 Oct 2013 10:41:00 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C05E71B82AE for ; Wed, 16 Oct 2013 10:40:59 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id ADB5619005C; Wed, 16 Oct 2013 10:40:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Oct 2013 10:40:59 -0700
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <525EB5BB.7020602@s-carlsen.dk>
Date: Wed, 16 Oct 2013 13:40:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <226CA93A-1846-4D6B-BF98-316600DDC291@nominum.com>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk>	<489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <525EA740.7000902@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1AD1E5A1@xmb-rcd-x04.cisco.com> <525EAC58.5060009@s-carlsen.dk>  <525EB5BB.7020602@s-carlsen.dk>
To: Sten Carlsen 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 17:41:08 -0000

On Oct 16, 2013, at 11:50 AM, Sten Carlsen  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 stenc@s-carlsen.dk  Wed Oct 16 17:40:03 2013
Return-Path: 
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 0E74511E819B for ; Wed, 16 Oct 2013 17:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 gDBXZajNgQTh for ; Wed, 16 Oct 2013 17:40:02 -0700 (PDT)
Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 3553E11E80E4 for ; Wed, 16 Oct 2013 17:39:56 -0700 (PDT)
Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 420983264; Thu, 17 Oct 2013 02:39:53 +0200 (CEST)
Message-ID: <525F31D9.8000607@s-carlsen.dk>
Date: Thu, 17 Oct 2013 02:39:53 +0200
From: Sten Carlsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Ted Lemon 
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk>	<489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <525EA740.7000902@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1AD1E5A1@xmb-rcd-x04.cisco.com> <525EAC58.5060009@s-carlsen.dk>  <525EB5BB.7020602@s-carlsen.dk> <226CA93A-1846-4D6B-BF98-316600DDC291@nominum.com>
In-Reply-To: <226CA93A-1846-4D6B-BF98-316600DDC291@nominum.com>
Content-Type: multipart/alternative; boundary="------------070205070706090408030007"
Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 00:40:03 -0000

This is a multi-part message in MIME format.
--------------070205070706090408030007
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


On 16/10/13 19.40, Ted Lemon wrote:
> On Oct 16, 2013, at 11:50 AM, Sten Carlsen  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... ;)
>
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

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


--------------070205070706090408030007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 16/10/13 19.40, Ted Lemon wrote:

    

    

      
On Oct 16, 2013, at 11:50 AM, Sten Carlsen <stenc@s-carlsen.dk> 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... ;)



    

    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

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


  


--------------070205070706090408030007--

From jiangsheng@huawei.com  Wed Oct 16 17:50:15 2013
Return-Path: 
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 3322921F936F for ; Wed, 16 Oct 2013 17:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level: 
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 09rtoDRI7Ymj for ; Wed, 16 Oct 2013 17:50:11 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9E99F21F9346 for ; Wed, 16 Oct 2013 17:50:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZD67751; Thu, 17 Oct 2013 00:50:09 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 01:49:22 +0100
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 01:50:07 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Thu, 17 Oct 2013 08:50:01 +0800
From: Sheng Jiang 
To: "Bernie Volz (volz)" , "dhcwg@ietf.org WG" 
Thread-Topic: [dhcwg] What sorts of services does DHCP configure?
Thread-Index: AQHOynEUQEQ991LaX0ejQZk7nFFTAJn22XWAgAE1vTA=
Date: Thu, 17 Oct 2013 00:50:00 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 00:50:15 -0000

PlRoZSBiYXNpYyBwaGlsb3NvcGh5IGlzIHRoYXQgREhDUCBzaG91bGQgYmUgdXNlZCBmb3IgZ2V0
dGluZyBhIERFVklDRSAoY2xpZW50KQ0KPmNvbm5lY3Rpdml0eSB0byBhIG5ldHdvcmsgYW5kIG5l
dHdvcmsgcmVzb3VyY2VzIG5lZWRlZCBmb3IgY29ubmVjdGl2aXR5LCBub3QNCj50byBjb25maWd1
cmUgYWxsIG9mIHRoZSBzZXJ2aWNlcyBhIFVTRVIgbWlnaHQgd2FudCB0byB1c2UuDQoNCkFncmVl
Lg0KDQpOb3csIHRoZSBxdWVzdGlvbiB3aWxsIGJlIHdoZXRoZXIgYWxsIGNvbmZpZ3VyYXRpb24g
Y2FuIGJlIGNsZWFybHkgY2F0ZWdvcml6ZWQgaW50byBuZXR3b3JrIGNvbm5lY3Rpdml0aWVzIG9y
IHVzZXIgc2VydmljZXMuIEkgZ3Vlc3MsIHRoZXJlIG1heSBiZSBjb250cm92ZXJzeSBmb3Igc29t
ZSBuZXR3b3JrIGNvbm5lY3Rpdml0aWVzIHRoYXQgbWF5IG9wZW4gZm9yIHNwZWNpZmljIHNlcnZp
Y2VzLg0KDQpTaGVuZw0KDQo+LSBCZXJuaWUNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYNCj5PZiBTaW1vbiBIb2Jzb24NCj5TZW50OiBXZWRuZXNkYXksIE9j
dG9iZXIgMTYsIDIwMTMgOToxMCBBTQ0KPlRvOiBkaGN3Z0BpZXRmLm9yZyBXRw0KPlN1YmplY3Q6
IFJlOiBbZGhjd2ddIFdoYXQgc29ydHMgb2Ygc2VydmljZXMgZG9lcyBESENQIGNvbmZpZ3VyZT8N
Cj4NCj4iUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIiB3cm90ZToNCj5TdGVuIENhcmxzZW4gd3Jv
dGU6DQo+Pj4gSSB0ZW5kIHRvIGxvb2sgYXQgdGhpcyBmcm9tIHRoZSBvcHBvc2l0ZSBzaWRlLCB3
aGF0IGFyZSB0aGUgc2VydmljZXMNCj4+PiB0aGF0IG5lZWQgdG8gYmUgY29uZmlndXJlZCBhbmQg
aW5mb21hdGlvbiB0aGF0IG5lZWRzIHRvIGJlIGRlbGl2ZXJlZD8gQW5kDQo+YXMgYSBjb25zZXF1
ZW5jZSB3aGF0IGFyZSB0aGUgdG9vbHM/DQo+Pj4gV2hhdCBpcyBpbiB0aGUgdG9vbGJveCBub3cg
YW5kIHdoYXQgaXMgbWlzc2luZz8gU29tZSBvZiB0aGUgbWlzc2luZyB0b29scw0KPmFyZSBsZWFk
aW5nIHRvIHVnbHkgaGFja3Mgbm93Lg0KPj4+IFRoZSBhbnN3ZXIgbWlnaHQgbm90IGJlIERIQ1As
IGJ1dCB0aGVuIHdoYXQgaXMgaXQ/DQo+DQo+PiBBZ3JlZSB3aXRoIFN0ZW4uDQo+DQo+DQo+SSBk
byB0b28uDQo+DQo+TG9va2luZyBiYWNrIHRocm91Z2ggdGhlIHRocmVhZCwgSSBhZ3JlZSB3aXRo
IFRlZCAtIHdlIGhhdmUgb3B0aW9ucyBmb3INCj50aGluZ3MgdGhhdCBpdCBkb2Vzbid0IG1ha2Ug
c2Vuc2UgZm9yIERIQ1AgdG8gY29uZmlndXJlLiBJTU8gSSBjYW4gc2VlIG5vIHVzZQ0KPmNhc2Ug
Zm9yIGNvbmZpZ3VyaW5nIElNQVAgbGlrZSBzZXJ2aWNlcyAtIHRob3NlIGFyZSB1c2VyLWNlbnRy
aWMgKG9yIG1vcmUNCj5pbXBvcnRhbnRseSwgdXNlci1hY2NvdW50IGNlbnRyaWMgLSB0aGVyZSBp
cyBhIGRpZmZlcmVuY2UpIGFuZCBpbiB0aGUgZ2VuZXJhbA0KPmNhc2Ugbm90IGNvbm5lY3RlZCB0
byBuZXR3b3JrIGxvY2F0aW9uLg0KPg0KPlNNVFAgaXMgc2ltaWxhcmx5IChJTU8pIGdlbmVyYWxs
eSB1c2VyLWFjY291bnQgc3BlY2lmaWMuIFdoZW4gSSdtIHNlbmRpbmcNCj5tYWlsLCBJIHdpbGwg
bm9ybWFsbHkgZXhwZWN0IHRvIHVzZSBteSAiaG9tZSIgc2VydmVyIGZvciB0aGUgYWNjb3VudCAt
IHdoaWNoIGlzDQo+dGhlIG9uZSBzZXJ2ZXIgaW4gdGhlIHdvcmxkIHRoYXQgSSBjYW4gYXV0aGVu
dGljYXRlIHRvIGFuZCBrbm93IHRoYXQgaXQgd2lsbA0KPnBhc3MgbXkgb3V0Ym91bmQgbWFpbCAo
bm90IHJlamVjdCBvciBibG9jayBpdCBiZWNhdXNlIHRoZSBlbWFpbCBhZGRyZXNzIGlzbid0DQo+
b25lIGFjY2VwdGVkIGJ5IHdoYXRldmVyIHJhbmRvbSBTTVRQIHNlcnZlciB0aGUgREhDUCBjb25m
aWcgbWlnaHQNCj5zdXBwbHkpLg0KPkFzIGFuIGFzaWRlLCBJIGJlbGlldmUgRXhjaGFuZ2UgY2xp
ZW50IGNvbmZpZyBpcyBkb25lIGluaXRpYWxseSBieSBETlMgLSB0aGUgY2xpZW50DQo+ZG9lcyBh
IGxvb2t1cCBmb3IgYXV0b2NvbmZpZ3VyZS48ZG9tYWluIG5hbWU+IGFuZCByZXF1ZXN0cyB0aGUg
Y29uZmlnDQo+ZnJvbSBpdC4gSW4gYSBsYXJnZSBjb3Jwb3JhdGUgZW52aXJvbm1lbnQsIGl0J3Mg
cG9zc2libGUgdGhhdCB0aGV5IHNpbXBseSBzZXR1cA0KPmRpZmZlcmVuY2UgYXV0b2NvbmZpZyBz
ZXJ2ZXJzIChJIGFzc3VtZSB0aGlzIGlzIGFuIGludGVncmFsIHBhcnQgb2YgRXhjaGFuZ2UNCj5i
dXQgdGhhdCdzIG5vdCBzb21ldGhpbmcgSSd2ZSB3b3JrZWQgd2l0aCkgYW5kIGNvbmZpZ3VyZSB0
aGUgbG9jYWwgRE5TDQo+YWNjb3JkaW5nbHkuIFdoaWNoIGxlYWRzIG9uIHRvIC4uLg0KPg0KPkRO
Uy4gVGhpcyBpcyBub3QgYXMgbG9jYXRpb24gYWdub3N0aWMgYXMgVGVkIG1ha2VzIG91dCBpbiBo
aXMgZmlyc3QgcG9zdC4gSU1FIGl0J3MNCj5mYXIgZnJvbSByYXJlIHRvIGhhdmUgZGlmZmVyZW50
IHZpZXdzIG9mIHRoZSBETlMgaW4gZGlmZmVyZW50IGxvY2F0aW9ucyAtIHNvDQo+YWNjZXNzaW5n
IHdlYi5teWNvbXBhbnluYW1lLmNvbSBpbiBvbmUgb2ZmaWNlIG1heSB3ZWxsIHRha2UgeW91IHRv
IGENCj5zZXJ2ZXIgY2xvc2UgKGluIG5ldHdvcmsgdGVybXMpIHRvIHRoZSB1c2VyLiBNb3ZlIHRv
IGEgZGlmZmVyZW50IG9mZmljZSBhbmQgdGhpcw0KPnNhbWUgRlFETiBtYXkgd2VsbCByZXNvbHZl
IHRvIGEgZGlmZmVyZW50IElQLiBBbnljYXN0IGFkZHJlc3NpbmcgY291bGQgd2VsbA0KPmFjaGll
dmUgdGhlIHNhbWUgdGhpbmcsIGJ1dCBmaWRkbGluZyB3aXRoIHRoZSBETlMgaXMgZWFzaWVyIChh
bmQgbW9yZQ0KPnVuZGVyc3RhbmRhYmxlIGZvciBhIGxvdCBvZiBwZW9wbGUpLg0KPg0KPkFuZCB0
aGVuIHdlIGdldCBzZXJ2aWNlcyBsaWtlIFNJUC4NCj5Gb3IgYSAicHVibGljIiBhY2NvdW50IHRo
ZW4gdGhlIGNvbmZpZyBpcyBhZ2FpbiB1c2VyLWFjY291bnQgc3BlY2lmaWMgLQ0KPndoZXJldmVy
IEkgYW0gSSdsbCBuZWVkIHRvIGNvbm5lY3QgYmFjayB0byB0aGUgc2FtZSByZWdpc3RyYXIuIElm
IHRoZSB0ZWxlcGhvbnkNCj5wcm92aWRlciBoYXMgbXVsdGlwbGUgU0lQIHJlZ2lzdHJhciBzZXJ2
ZXJzIHRoZW4gSSBtYXkgd2VsbCBiZSBiZXN0IGNvbm5lY3RpbmcNCj50byB3aGljaGV2ZXIgb25l
IGlzIGNsb3Nlc3QgKGluIG5ldHdvcmsgdGVybXMpIHRvIG1lIC0gYnV0IHRoYXQncyBub3QNCj5z
b21ldGhpbmcgc29tZSByYW5kb20gREhDUCBhZG1pbiB3aWxsIGhhdmUgYW55IGtub3dsZWRnZSBv
ZiB3aGVuDQo+c2V0dGluZyB1cCBoaXMgc2VydmVyLg0KPkJ1dCB0aGVyZSBtYXkgd2VsbCBiZSBj
b3Jwb3JhdGUgU0lQIGltcGxlbWVudGF0aW9ucyB3aGVyZSBESENQIGlzIGN1cnJlbnRseQ0KPnRo
ZSBiZXN0IChvciBsZWFzdCBiYWQgPykgd2F5IG9mIGNvbmZpZ3VyaW5nIHRoaW5ncy4gRm9yIGRl
dmljZXMgdGhhdCBhcmUgb25seQ0KPmludGVuZGVkIHRvIHdvcmsgd2l0aGluIHRoZSBjb3Jwb3Jh
dGUgbmV0d29yaywgdGhlIHZhcmlvdXMgYWRtaW5pc3RyYXRvcnMNCj5jb3VsZCB3b3VsZCBvdXQg
d2hpY2ggU0lQIG9wdGlvbnMgdG8gcGFzcyB0byBhIGRldmljZSBkZXBlbmRpbmcgb24gbmV0d29y
aw0KPmxvY2F0aW9uLiBCdXQgYWdhaW4sIEkgdGhpbmsgdGhhdCBzdWNoIGEgY29uZmlnIHN5c3Rl
bSB3b3VsZCBiZSBiZXR0ZXIgaWYNCj5zZXBhcmF0ZSBmcm9tIERIQ1AuDQo+DQo+DQo+VG8gZmlu
aXNoLCBhcyBoYXMgYWxyZWFkeSBiZWVuIHBvaW50ZWQgb3V0IC0gbXVjaCBvZiB0aGlzIGlzICJp
ZiB3ZSB3ZXJlIHN0YXJ0aW5nDQo+ZnJvbSBoZXJlIHdlIHdvdWxkbid0IGRvIC4uLiIgLSBub3Qg
YmVjYXVzZSB0aGUgb3JpZ2luYWwgZGVjaXNpb25zIHdlcmUgd3JvbmcNCj5pbiB0aGUgY29udGV4
dCBpbiB3aGljaCB0aGV5IHdlcmUgdGFrZW4sIGJ1dCBzaW1wbHkgYmVjYXVzZSB0aGluZ3MgaGF2
ZQ0KPmNoYW5nZWQgZHJhbWF0aWNhbGx5IG92ZXIgdGhlIHllYXJzLg0KPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBsaXN0DQo+
ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ro
Y3dnDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5k
aGN3ZyBtYWlsaW5nIGxpc3QNCj5kaGN3Z0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg==

From volz@cisco.com  Wed Oct 16 20:31:14 2013
Return-Path: 
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 9CE2911E8220 for ; Wed, 16 Oct 2013 20:31:14 -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=[AWL=-0.000, 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 eHdKXDbN7HXU for ; Wed, 16 Oct 2013 20:31:09 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B757411E80F2 for ; Wed, 16 Oct 2013 20:31:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4900; q=dns/txt; s=iport; t=1381980669; x=1383190269; h=from:to:subject:date:message-id:mime-version; bh=B/O7Fey3al8oFHKghzLVnMTVlwWvDjcAsMu3rjz2WgE=; b=N/TdsXj/8l6y+IIcnpsxX9/Kb2J1aorq/kcxPjtsS39L89+1/X69x7xG 6FV0FeYiHoiDrBb98THptaGIXyRUOq6WfMX+9iIjK6/xuvD2yOpvtn+qp mpbWv6fDY26cVrof+TnvuTf4SjM/N8BUGqyslm6la2/Xd7vtiF0N9yKnz E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjUIABVZX1KtJXHA/2dsb2JhbABagkNEOFK1PIhFgSAWbQeCJwEEHRBeASpWJgEEG4d+DJ4MoUqOGIEILYMqgQYDmTWQVYMkgXA5
X-IronPort-AV: E=Sophos;i="4.93,511,1378857600";  d="scan'208,217";a="273089829"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 17 Oct 2013 03:31:09 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9H3V9GD029090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 17 Oct 2013 03:31:09 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 22:31:08 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends November 11, 2013
Thread-Index: Ac7K6RYO6IlqgYnCS8a24Ug8i2UzUg==
Date: Thu, 17 Oct 2013 03:31:07 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD20B47@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.86.244.159]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AD20B47xmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends November 11, 2013
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 03:31:14 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E1AD20B47xmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all:



The author has requested a call for adoption by the WG for draft-jiang-dhc-=
sedhcpv6-02. (This document "replaces" http://tools.ietf.org/html/draft-iet=
f-dhc-secure-dhcpv6-07 as that document went to the IESG - see https://data=
tracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ for more details. The ne=
w document is very different so please read it.)



This call is being initiated to confirm whether there is WG consensus to ad=
opt this work as DHC WG draft. Please state whether or not you're in favor =
of the adoption by replying to this mail. If you are not in favor, please a=
lso state your objections in your response. This adoption call will complet=
e on November 11, 2013 - after the IETF meeting as it will likely be on the=
 DHC WG agenda.



The HTML version of the document can be viewed at http://tools.ietf.org/htm=
l/draft-jiang-dhc-sedhcpv6.



Regards,

Tomek & Bernie


--_000_489D13FBFA9B3E41812EA89F188F018E1AD20B47xmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all:


 


The author has requested a call for adoption by t=
he WG for draft-jiang-dhc-sedhcpv6-02. (This document “replaces”=
;
http=
://tools.ietf.org/html/draft-ietf-dhc-secure-dhcpv6-07 as that document=
 went to the IESG – see
=
https://datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ for more=
 details. The new document is very different so please read it.)=



 


This call is being initiated to confirm whether t=
here is WG consensus to adopt this work as DHC WG draft. Please state wheth=
er or not you're in favor of the adoption by replying to this mail. If you =
are not in favor, please also state
 your objections in your response. This adoption call will complete on Nove=
mber 11, 2013 – after the IETF meeting as it will likely be on the DH=
C WG agenda.


 


The HTML version of the document can be viewed at=
 
http://tools.ietf.org/html/draft-jiang-dhc-sedhcpv6.


 


Regards,


Tomek & Bernie


 






--_000_489D13FBFA9B3E41812EA89F188F018E1AD20B47xmbrcdx04ciscoc_--

From Ted.Lemon@nominum.com  Wed Oct 16 20:36:11 2013
Return-Path: 
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 821A521F9DAF for ; Wed, 16 Oct 2013 20:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 hz3ELKpM1msW for ; Wed, 16 Oct 2013 20:36:00 -0700 (PDT)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id C27DA21F9D12 for ; Wed, 16 Oct 2013 20:35:45 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUl9bEY286+y0yhVMq8jLRqStDqY9vPY0@postini.com; Wed, 16 Oct 2013 20:35:45 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 127E41B82CE for ; Wed, 16 Oct 2013 20:35:45 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6BC1E19005C; Wed, 16 Oct 2013 20:35:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Oct 2013 20:35:44 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com>
Date: Wed, 16 Oct 2013 23:35:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com>
To: Sheng Jiang 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 03:36:12 -0000

On Oct 16, 2013, at 8:50 PM, Sheng Jiang  wrote:
> 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).


From jiangsheng@huawei.com  Wed Oct 16 20:55:47 2013
Return-Path: 
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 E8BD111E821A for ; Wed, 16 Oct 2013 20:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 UzPBkhq3n0KZ for ; Wed, 16 Oct 2013 20:55:42 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34E6A11E816D for ; Wed, 16 Oct 2013 20:55:40 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZD78042; Thu, 17 Oct 2013 03:55:37 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 04:54:38 +0100
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 04:55:33 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0146.000; Thu, 17 Oct 2013 11:55:28 +0800
From: Sheng Jiang 
To: Ted Lemon 
Thread-Topic: [dhcwg] What sorts of services does DHCP configure?
Thread-Index: AQHOynEUQEQ991LaX0ejQZk7nFFTAJn22XWAgAE1vTD//6m3gIAAihww
Date: Thu, 17 Oct 2013 03:55:27 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com> <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com>
In-Reply-To: <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 03:55:48 -0000

Pk9uIE9jdCAxNiwgMjAxMywgYXQgODo1MCBQTSwgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVh
d2VpLmNvbT4gd3JvdGU6DQo+PiBOb3csIHRoZSBxdWVzdGlvbiB3aWxsIGJlIHdoZXRoZXIgYWxs
IGNvbmZpZ3VyYXRpb24gY2FuIGJlIGNsZWFybHkNCj5jYXRlZ29yaXplZCBpbnRvIG5ldHdvcmsg
Y29ubmVjdGl2aXRpZXMgb3IgdXNlciBzZXJ2aWNlcy4gSSBndWVzcywgdGhlcmUgbWF5DQo+YmUg
Y29udHJvdmVyc3kgZm9yIHNvbWUgbmV0d29yayBjb25uZWN0aXZpdGllcyB0aGF0IG1heSBvcGVu
IGZvciBzcGVjaWZpYw0KPnNlcnZpY2VzLg0KPg0KPklmIHRoZXJlIGlzIG5vIGNvbnRyb3ZlcnN5
IGluIF90aGlzXyB3b3JraW5nIGdyb3VwLCB0aGF0IGFuc3dlcnMgdGhlIHF1ZXN0aW9uIEkNCj53
YXMgcmVxdWVzdGVkIHRvIGFzay4gICBXZSBhcmUgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgd2hhdCB0
aGUgREhDIHdvcmtpbmcNCj5ncm91cCdzIHBvc2l0aW9uIGlzIG9uIHRoaXMgcXVlc3Rpb24sIG5v
dCB3aGF0IHRoZSBJRVRGIGFzIGEgd2hvbGUncyBwb3NpdGlvbiBpcw0KPm9uIGl0LiAgIFRoZSBP
cHRpb24gR3VpZGVsaW5lcyBkb2N1bWVudCBpcyBlc3NlbnRpYWxseSBhZHZpY2UgZnJvbSB0aGUg
REhDDQo+d29ya2luZyBncm91cCB0byB0aGUgSUVURiwgYW5kIHRoYXQncyBzb21ldGhpbmcgdGhl
IElFU0cgc2VlbXMgaGFwcHkgd2l0aA0KPih0aGUgcmVjZXB0aW9uIG9mIHRoaXMgZG9jdW1lbnQg
d2FzIHByZXR0eSBlbnRodXNpYXN0aWNhbGx5IHBvc2l0aXZlKS4NCg0KTXkgY29uY2VybiBpcyBm
b3IgREhDIFdHLCB0b28uDQoNClRha2luZyBhIG1vcmUgc3BlY2lmaWMgZXhhbXBsZSwgIkRpc3Ry
aWJ1dGluZyBBZGRyZXNzIFNlbGVjdGlvbiBQb2xpY3kgdXNpbmcgREhDUHY2IiwgZHJhZnQtaWV0
Zi02bWFuLWFkZHItc2VsZWN0LW9wdC4gRm9yIG5vdywgdGhpcyBkcmFmdCBvbmx5IHByb3BhZ2F0
ZXMgZ2VuZXJpYyBhZGRyZXNzIHNlbGVjdGlvbiBwb2xpY3kuIEl0IGlzIGxpdHRsZSBjb250cm92
ZXJzeSB0byBiZSBESENQdjYgY29uZmlndXJhdGlvbiwgaW4gbXkgZXllcy4NCg0KSG93ZXZlciwg
aXQgaXMgdmVyeSBsaWtlbHkgdGhpcyB3b3VsZCBkZXZlbG9wIGZ1cnRoZXIgaW4gdGhlIGZ1dHVy
ZSwgdG8gYmVjb21lICJpZiB5b3Ugd2FudCB0byBjb25uZWN0IHRvIFNlcnZpY2UvQXBwbGljYXRp
b24gWCwgY2hvb3NlIHNvdXJjZSBhZGRyZXNzIEEiLiBGb3IgdGhhdCwgSSBhbSBub3Qgc3VyZSBp
dCBmYWxscyBpbnRvIG5ldHdvcmsgY29ubmVjdGl2aXRpZXMgb3IgdXNlciBzZXJ2aWNlcy4NCg0K
UmVnYXJkcywNCg0KU2hlbmcNCg==

From Ted.Lemon@nominum.com  Wed Oct 16 21:00:32 2013
Return-Path: 
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 26B7A11E8225 for ; Wed, 16 Oct 2013 21:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 4yyeIqSLbGOw for ; Wed, 16 Oct 2013 21:00:25 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 04DD611E8159 for ; Wed, 16 Oct 2013 21:00:23 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUl9g17ClbtEeguwOD3AJ4wt9GAV38+V8@postini.com; Wed, 16 Oct 2013 21:00:23 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8E7471B82CE for ; Wed, 16 Oct 2013 21:00:23 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8291919005C; Wed, 16 Oct 2013 21:00:23 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Oct 2013 21:00:23 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com>
Date: Thu, 17 Oct 2013 00:00:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com> <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com>
To: Sheng Jiang 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 04:00:32 -0000

On Oct 16, 2013, at 11:55 PM, Sheng Jiang  wrote:
> 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.

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=97e.g., in a PE router<->CE router situation.  But this is not =
something that ought to be enabled on all DHCP clients.


From jiangsheng@huawei.com  Wed Oct 16 22:42:28 2013
Return-Path: 
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 7BBA821F9C70 for ; Wed, 16 Oct 2013 22:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 lHsAfCUrjwT5 for ; Wed, 16 Oct 2013 22:42:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B0E7611E81EC for ; Wed, 16 Oct 2013 22:42:22 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZD83813; Thu, 17 Oct 2013 05:42:21 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 06:41:25 +0100
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Oct 2013 06:42:19 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0146.000; Thu, 17 Oct 2013 13:42:12 +0800
From: Sheng Jiang 
To: Ted Lemon 
Thread-Topic: [dhcwg] What sorts of services does DHCP configure?
Thread-Index: AQHOynEUQEQ991LaX0ejQZk7nFFTAJn22XWAgAE1vTD//6m3gIAAihww//98xoCAAKEVgA==
Date: Thu, 17 Oct 2013 05:42:12 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD49A8B@nkgeml512-mbx.china.huawei.com>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com> <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com> <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com>
In-Reply-To: <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 05:42:28 -0000

Pkl0J3MgcHJldHR5IGNsZWFyIHRvIG1lIHRoYXQgdGhpcyBvcHRpb24gaXMgbm90IGEgdmVyeSBn
b29kIGlkZWEgaW4gbW9zdCBjYXNlcy4NCj5JIGRvbid0IHRoaW5rIHRoZSBESEMgd29ya2luZyBn
cm91cCBpcyBpbiBhIHBvc2l0aW9uIHRvIHNheSBubyB0byBpdCwgYnV0IHdlIGFyZQ0KPmNlcnRh
aW5seSBpbiBhIHBvc2l0aW9uIHRvIHNheSAidGhpcyBpc24ndCBhIGdvb2QgZ2VuZXJhbCBzb2x1
dGlvbiB0byBYIg0KDQpXaHkgREhDIFdHIGNhbm5vdCBzYXkgbm8gdG8gd2hhdCBzaG91bGQgbm90
IGJlIGluIERIQz8gSWYgdGhhdCdzIHRoZSBjYXNlLCB3ZSBoYXZlIG5vIHBvaW50cyB0byBkaXNj
dXNzIGhlcmUgd2hhdCBzaG91bGQgb3Igc2hvdWxkIG5vdCBiZSBjb25maWd1cmVkIHVzaW5nIERI
QyBwcm90b2NvbC4gUGVvcGxlIHdpbGwga2VlcCB0byAiYm9ycm93IiBESENQIGZvciB0aGVpciB1
bnN1aXRhYmxlIHB1cnBvc2VzIGFzIGxvbmcgYXMgdGhleSBkbyBub3QgaGF2ZSBhbm90aGVyIHN1
aXRhYmxlIHByb3RvY29sLg0KDQpSZWdhcmRzLA0KDQpTaGVuZw0K

From alexandru.petrescu@gmail.com  Thu Oct 17 00:00:08 2013
Return-Path: 
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 036D411E8241 for ; Thu, 17 Oct 2013 00:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.139
X-Spam-Level: 
X-Spam-Status: No, score=-10.139 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 kejGlYdkIBLZ for ; Wed, 16 Oct 2013 23:59:59 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 099D011E824F for ; Wed, 16 Oct 2013 23:59:48 -0700 (PDT)
Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r9H6xlTi010695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 17 Oct 2013 08:59:47 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r9H6xlcM030677 for ; Thu, 17 Oct 2013 08:59:47 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r9H6xkc5012963 for ; Thu, 17 Oct 2013 08:59:47 +0200
Message-ID: <525F8AE2.5060106@gmail.com>
Date: Thu, 17 Oct 2013 08:59:46 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk>	<489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com>	<525EA740.7000902@s-carlsen.dk>	<489D13FBFA9B3E41812EA89F188F018E1AD1E5A1@xmb-rcd-x04.cisco.com>	<525EAC58.5060009@s-carlsen.dk>		<525EB5BB.7020602@s-carlsen.dk>	<226CA93A-1846-4D6B-BF98-316600DDC291@nominum.com> <525F31D9.8000607@s-carlsen.dk>
In-Reply-To: <525F31D9.8000607@s-carlsen.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 07:00:08 -0000

Le 17/10/2013 02:39, Sten Carlsen a écrit :
>
> On 16/10/13 19.40, Ted Lemon wrote:
>> On Oct 16, 2013, at 11:50 AM, Sten Carlsen  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... ;)
>>
> Ok, start of list 1, things I would like to get fromDHCP:
> IP/prefix
> subnet-mask

and IPv6 and IPv4 delegated prefix/length.

> lease-time
> routers

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

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

and minimal MTU of the link.

Alex


>
> --
> Best regards
>
> Sten Carlsen
>
> No improvements come from shouting:
>
>         "MALE BOVINE MANURE!!!"
>
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>



From linux@thehobsons.co.uk  Thu Oct 17 04:34:07 2013
Return-Path: 
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 2BABD21F93F8 for ; Thu, 17 Oct 2013 04:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 da9JOKw99Sw6 for ; Thu, 17 Oct 2013 04:34:06 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 43EF821F9385 for ; Thu, 17 Oct 2013 04:34:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 9157C29ED7 for ; Thu, 17 Oct 2013 12:34:00 +0100 (BST)
Received: from patsy.thehobsons.co.uk ([127.0.0.1]) by localhost (patsy.thehobsons.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KliS1YGyRnI for ; Thu, 17 Oct 2013 12:34:00 +0100 (BST)
Received: from localhost (patsy.thehobsons.co.uk [192.168.0.33]) by patsy.thehobsons.co.uk (Postfix) with ESMTP id 3A6C729EAD for ; Thu, 17 Oct 2013 12:34:00 +0100 (BST)
From: "Simon Hobson"  
To: dhcwg@ietf.org
Date: Thu, 17 Oct 2013 12:34:09 +0100
X-Priority: 3
X-Mailer: MailForge 3.0 Mac OS X
Message-ID: <06875D62C7D1551D8BBAA334FF466ED@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 11:34:07 -0000

Sten Carlsen 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?

Well one technique that seems to be getting very popular is autoconf & zeroconf & multicast DNS. Take for example Apple's streaming protocol for playing media across their various devices. AIUI, the devices will use autoconf IPv6 addresses, and multicast DNS to find devices on the network. So (for example) connect an Apple TV to your network and it "just appears" as a video output device for an iPad or iPhone.

Similar things are happening with printers etc. mDNS allows devices to find the printer without the user having to bother about IP addresses, ports, etc.


Ted Lemon wrote:
>Although there is an NTP option for DHCP, and it is implemented in some cases, it is not widely used, for reasons
> that seem obvious to me: NTP is required for replay detection, and so trusting the DHCP server to tell you what
> your NTP server is isn't secure.

It that much different to most options the DHCP server sends ? Eg, if you don't trust the DNS to be accurate then you are going to have fairly limited networking. Assuming you hard code you NTP, then there's nothing to say that on  that the traffic isn't blocked and/or interfered with.

From repenno@cisco.com  Thu Oct 17 05:35:48 2013
Return-Path: 
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 C638B11E81B5 for ; Thu, 17 Oct 2013 05:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.474
X-Spam-Level: 
X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, 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 4n3NglUgF0Xo for ; Thu, 17 Oct 2013 05:35:44 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A811C11E81D2 for ; Thu, 17 Oct 2013 05:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=890; q=dns/txt; s=iport; t=1382013335; x=1383222935; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kYngHKp1E4OGsSim9kUxl+0kt9S1MazZ1xNDDbzKVdg=; b=DMw2KYt8fjcUEYD2xm5t65C8VLZGXeqFaB3DcfqpdtbqLubjGS281a9/ S2CwBs618bvecrO3pas5UA4NDr7bUUxdI3XUp7RyNTcGRe0nYja65Jpk2 UdRLZ8aM7oauxDRtog9cTz0oSWvQvL/7vTg+UvWnrOJcxLHDwfUvD03yl 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAE3ZX1KtJV2Z/2dsb2JhbABagwc4Ur4CgSMWdIInAQQBAQE3NAsSAQgiFDcLJQIEAQ0FCBOHawzAHwSPIDEHgx+BBwOqCoMkgik
X-IronPort-AV: E=Sophos;i="4.93,514,1378857600"; d="scan'208";a="273048893"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 17 Oct 2013 12:35:30 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9HCZUqi028992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 12:35:30 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 17 Oct 2013 07:35:30 -0500
From: "Reinaldo Penno (repenno)" 
To: Sheng Jiang , Ted Lemon 
Thread-Topic: [dhcwg] What sorts of services does DHCP configure?
Thread-Index: AQHOynEUiAXKk6KM3ESJzga2BnKmuZn3s2OAgACxKQCAAC5LgIAABYaAgAABXICAABx3AP///iCA
Date: Thu, 17 Oct 2013 12:35:30 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B7372C4@xmb-rcd-x04.cisco.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AD49A8B@nkgeml512-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.68.203]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 12:35:48 -0000

On 10/16/13 10:42 PM, "Sheng Jiang"  wrote:

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

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


>
>Regards,
>
>Sheng
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg


From Ted.Lemon@nominum.com  Thu Oct 17 06:54:28 2013
Return-Path: 
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 DEA8021F9C4F for ; Thu, 17 Oct 2013 06:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 yXym8PMvhnPt for ; Thu, 17 Oct 2013 06:54:22 -0700 (PDT)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 5B58021F9C10 for ; Thu, 17 Oct 2013 06:54:22 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUl/sDte9iWc/mfpxzSp7YMrM4XxeCeA6@postini.com; Thu, 17 Oct 2013 06:54:22 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E1C0A1B81D8 for ; Thu, 17 Oct 2013 06:54:18 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CF3E119005C; Thu, 17 Oct 2013 06:54:18 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Oct 2013 06:54:18 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AD49A8B@nkgeml512-mbx.china.huawei.com>
Date: Thu, 17 Oct 2013 09:54:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <85FE4890-3622-423E-95A8-BB528B1FA23B@nominum.com>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com> <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com> <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49A8B@nkgeml512-mbx.china.huawei.com>
To: Sheng Jiang 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 13:54:29 -0000

On Oct 17, 2013, at 1:42 AM, Sheng Jiang  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.

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@nominum.com  Thu Oct 17 07:19:38 2013
Return-Path: 
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 155C021F8423 for ; Thu, 17 Oct 2013 07:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 tSkXzh8sj3PP for ; Thu, 17 Oct 2013 07:19:31 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 414AB21F88B4 for ; Thu, 17 Oct 2013 07:19:28 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUl/x4/mB70JKVq+RoUZFXXTsgoabtPm3@postini.com; Thu, 17 Oct 2013 07:19:28 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F356C1B82EB for ; Thu, 17 Oct 2013 07:19:14 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EAF8E19005C; Thu, 17 Oct 2013 07:19:14 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Oct 2013 07:19:08 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B7372C4@xmb-rcd-x04.cisco.com>
Date: Thu, 17 Oct 2013 10:19:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <06BAABF9-E34A-4A1C-B948-1500DBEA4F94@nominum.com>
References: <45A697A8FFD7CF48BCF2BE7E106F06040B7372C4@xmb-rcd-x04.cisco.com>
To: Reinaldo Penno 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 14:19:38 -0000

On Oct 17, 2013, at 8:35 AM, Reinaldo Penno (repenno) =
 wrote:
> Agree. I'm a little puzzled by the first referenced paragraph as well. =
Why
> all this exercise?

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 kre@munnari.OZ.AU  Thu Oct 17 07:58:26 2013
Return-Path: 
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 D1F4C21F8F78 for ; Thu, 17 Oct 2013 07:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
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 k3lMpfKXtpbP for ; Thu, 17 Oct 2013 07:58:20 -0700 (PDT)
Received: from jade.coe.psu.ac.th (unknown [IPv6:2001:3c8:9009:181::2]) by ietfa.amsl.com (Postfix) with ESMTP id CF50311E81CB for ; Thu, 17 Oct 2013 07:57:50 -0700 (PDT)
Received: from perseus.noi.kre.to (jade.coe.psu.AC.TH [IPv6:2001:3c8:9007:1::21]) by jade.coe.psu.ac.th with ESMTP id r9HE1UYf017275; Thu, 17 Oct 2013 21:01:31 +0700 (ICT)
Received: from perseus.noi.kre.to (localhost [127.0.0.1]) by perseus.noi.kre.to (8.14.7/8.14.2) with ESMTP id r9HE1MoR002613; Thu, 17 Oct 2013 21:01:23 +0700 (ICT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.5
From: Robert Elz 
To: Sheng Jiang 
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AD49A8B@nkgeml512-mbx.china.huawei.com>
References: <5D36713D8A4E7348A7E10DF7437A4B923AD49A8B@nkgeml512-mbx.china.huawei.com> <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com> <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com> <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 17 Oct 2013 21:01:22 +0700
Message-ID: <26702.1382018482@perseus.noi.kre.to>
Cc: "dhcwg@ietf.org WG" , Ted Lemon , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 14:58:26 -0000

    Date:        Thu, 17 Oct 2013 05:42:12 +0000
    From:        Sheng Jiang 
    Message-ID:  <5D36713D8A4E7348A7E10DF7437A4B923AD49A8B@nkgeml512-mbx.china.huawei.com>

  | 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 wwwrun@rfc-editor.org  Thu Oct 17 14:57:15 2013
Return-Path: 
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 210A611E8285; Thu, 17 Oct 2013 14:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.182
X-Spam-Level: 
X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 HZJ04v4Ebq0S; Thu, 17 Oct 2013 14:57:14 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2B96D11E82A2; Thu, 17 Oct 2013 14:57:11 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 4F5C5B1E078; Thu, 17 Oct 2013 14:48:56 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20131017214856.4F5C5B1E078@rfc-editor.org>
Date: Thu, 17 Oct 2013 14:48:56 -0700 (PDT)
Cc: drafts-update-ref@iana.org, dhcwg@ietf.org, rfc-editor@rfc-editor.org
Subject: [dhcwg] RFC 7037 on RADIUS Option for the DHCPv6 Relay Agent
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Oct 2013 21:57:15 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7037

        Title:      RADIUS Option for the DHCPv6 
                    Relay Agent 
        Author:     L. Yeh, M. Boucadair
        Status:     Standards Track
        Stream:     IETF
        Date:       October 2013
        Mailbox:    leaf.yeh.sdo@gmail.com, 
                    mohamed.boucadair@orange.com
        Pages:      10
        Characters: 23356
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-dhc-dhcpv6-radius-opt-14.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7037.txt

The DHCPv6 RADIUS option provides a mechanism to exchange
authorization and identification information between the DHCPv6 relay
agent and DHCPv6 server.  This architecture assumes that the Network
Access Server (NAS) acts as both a DHCPv6 relay agent and RADIUS
client.  When receiving messages from the DHCPv6 clients, the NAS
consults the RADIUS server and adds the RADIUS response when
forwarding the DHCPv6 client's messages to the DHCPv6 server.  The
DHCPv6 server then uses that additional information to generate an
appropriate response to the DHCPv6 client's requests.

This document is a product of the Dynamic Host Configuration Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From jiangsheng@huawei.com  Thu Oct 17 18:58:04 2013
Return-Path: 
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 19E1C11E81B1 for ; Thu, 17 Oct 2013 18:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.576
X-Spam-Level: 
X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 2BLMW9rmlRP8 for ; Thu, 17 Oct 2013 18:57:57 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5C03311E813D for ; Thu, 17 Oct 2013 18:57:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWX23620; Fri, 18 Oct 2013 01:57:46 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 02:56:44 +0100
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 18 Oct 2013 02:57:41 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0146.000; Fri, 18 Oct 2013 09:57:37 +0800
From: Sheng Jiang 
To: Robert Elz 
Thread-Topic: [dhcwg] What sorts of services does DHCP configure?
Thread-Index: AQHOynEUQEQ991LaX0ejQZk7nFFTAJn22XWAgAE1vTD//6m3gIAAihww//98xoCAAKEVgIAABtkAgAFEW4A=
Date: Fri, 18 Oct 2013 01:57:37 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD4A6C1@nkgeml512-mbx.china.huawei.com>
References: <5D36713D8A4E7348A7E10DF7437A4B923AD49A8B@nkgeml512-mbx.china.huawei.com> <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com> <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com> <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com> <26702.1382018482@perseus.noi.kre.to>
In-Reply-To: <26702.1382018482@perseus.noi.kre.to>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dhcwg@ietf.org WG" , Ted Lemon , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 01:58:04 -0000

PlNoZW5nPiAgfCBXaHkgREhDIFdHIGNhbm5vdCBzYXkgbm8gdG8gd2hhdCBzaG91bGQgbm90IGJl
IGluIERIQz8NCj4NCj5Xb3VsZCB5b3UgYXNrIHRoZSBzYW1lIHF1ZXN0aW9uIGlmIGl0IHdlcmUg
dGhlIFRDUCB3b3JraW5nIGdyb3VwIGF0dGVtcHRpbmcNCj50byBzdG9wIHNvbWUgYXBwbGljYXRp
b24gcHJvdG9jb2wgYmVjYXVzZSB0aGUgVENQIHBlb3BsZSBkaWRuJ3QgbGlrZSBpdD8NCg0KVGhl
IHF1ZXN0aW9uIGlzIGRpZmZlcmVudCBoZXJlLiBUaGUgYXBwbGljYXRpb24gcHJvdG9jb2wgdXNl
IFRDUCBhcyBhIHRyYW5zcGFyZW50IGRlbGl2ZXIgdG9vbC4gVGhleSBkb2VzIG5vdCByZXF1ZXN0
IGFueXRoaW5nIGZyb20gVENQIHJlc291cmNlLiBUaGUgREhDIFdHIGNhbm5vdCBzdG9wIHBlb3Bs
ZSB0byB1c2UgREhDIHByb3RvY29sIGFzIGEgcGxhdGZvcm0uIEJ1dCB0aGUgREhDIFdHIHNob3Vs
ZCBoYXZlIHRoZSByaWdodCB0byBzYXk6IHlvdSBjYW4gZG8gd2hhdGV2ZXIgeW91IHdhbnQgb3Zl
ciBESENQIHBsYXRmb3JtIGZvciBhbnkgcHVycG9zZXMsIGJ1dCB5b3UgQ0FOTk9UIGdldCBvZmZp
Y2lhbCBESENQIE9wdGlvbiBjb2RlIGFzc2lnbmVkIGJ5IElBTkEgaWYgdGhhdCBkb2VzIG5vdCBh
cHByb3ZlZCBieSBESEMgRGlyZWN0b3JhdGUuIEluIGFub3RoZXIgd29yZCwgREhDIE9wdGlvbiBj
b2RlIGlzIGEgcmVzb3VyY2UsIGNvbnRyb2xsZWQgYnkgREhDIERpcmVjdG9yYXRlIGFuZCBzaG91
bGQgb25seSBiZSBhc3NpZ25lZCB0byB0aGVzZSBjb3JyZWN0IHVzYWdlcy4NCg0KU2hlbmcNCg0K
PlRoZSBESENQIHdvcmtpbmcgZ3JvdXAncyBqb2IgaXMgdG8gbWFrZSBESENQIHdvcmsgLSBpbXBy
b3ZpbmcgYXMgbXVjaA0KPmFzIHBvc3NpYmxlIHRoZSBlZmZpY2llbmN5LCByZWxpYWJpbGl0eSwg
YW5kIHNlY3VyaXR5IC0gYXMgd2l0aCBhbnkgb3RoZXINCj5wcm90b2NvbC4NCj4NCj5JdCBpc24n
dCB0byBkaWN0YXRlIGhvdyBvdGhlcnMgdXNlIHRoZSByZXN1bHQuICAgSWYgc29tZSBvdGhlciBX
RyBoYXMgYQ0KPnVzZSBmb3Igc29tZSBkYXRhLCBhbmQgaGF2aW5nIHRoYXQgZGVsaXZlciBkZWxp
dmVyZWQgYnkgREhDUCBsb29rcyB0byBiZQ0KPnRoZSBiZXN0IHdheSAodG8gdGhlbSkgdGhlbiBw
cm92aWRlZCB0aGUgaWRlYSBzdXJ2aXZlcyBJRVRGIGxhc3QgY2FsbCwNCj5pdCByZWFsbHkgaXMg
bm8tb25lIGVsc2UncyBidXNpbmVzcy4NCj4NCj5PZiBjb3Vyc2UgdGhpcyBXRyAoYW5kIGFueW9u
ZSBlbHNlKSBjYW4gc3VnZ2VzdCBhbHRlcm5hdGl2ZXMsIG9yIGRlc2NyaWJlDQo+cHJvYmxlbXMs
IGFuZCBzdWdnZXN0IGJldHRlciB3YXlzIC0gYnV0IG5vLW9uZSBnZXRzICh1bmlsYXRlcmFsbHkp
IHRvDQo+aW1wb3NlIHJvYWQgYmxvY2tzLiAgICBUZWQgd2FzIHJpZ2h0IGluIHdoYXQgaGUgc2Fp
ZCAtIGlmIHRoZSBwcm9wb3NhbCBpbg0KPnF1ZXN0aW9uIGlzbid0IGEgZ29vZCBpZGVhLCBieSBh
bGwgbWVhbnMgc2F5IHNvLCBidXQgZG9uJ3Qgc3RhcnQgYmVsaWV2aW5nDQo+dGhhdCB0aGlzIGdy
b3VwIGhhcyBhbnkgcmlnaHQgdG8gdGVsbCBhbnkgb3RoZXIgd2hhdCB0aGV5IGNhbiBvciBjYW5u
b3QgZG8uDQo+DQo+a3JlDQoNCg==

From sunqi.csnet.thu@gmail.com  Fri Oct 18 02:31:25 2013
Return-Path: 
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 A1A4C11E810B for ; Fri, 18 Oct 2013 02:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 p7Xs8500wE0z for ; Fri, 18 Oct 2013 02:31:23 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id C413C21F9CE9 for ; Fri, 18 Oct 2013 02:31:22 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id q10so2943027pdj.14 for ; Fri, 18 Oct 2013 02:31:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=1YCHI+9Lrz6q8eKk3HNQhMOH/GVgr9dLVIkRPMNyWIk=; b=E221FVzQB23dT5WXSR+QGZ4naIxCTK70dgIJ3QPiFg59xR26Vi1UJGTTeAIhL16GH+ Ookx/aoZy+4q3CkAVyL94F9MvS+y6vZTx/etEz2rSE5A2U4cgWWQK3V55wmxlw4UnDLT o0b0sMmZmCrDfWSgQpIm8BkU/u9fqaK+iMe2aPTZUx30fzepyUS1YBmclh3Uat3o9Hpt AHzvd2BaJ0NUog+YFRuMgWWUBJpRua/rIsOaL3ZO6lHGWgdY7YPPoJ5ZTFEyiwwwIZ5e MIoqQov/LejHWkWWWfdn7/+QamPZqByQp99S3vs4Ly58iaDaN+ko01w1Xtb57RPR7h74 8gbA==
X-Received: by 10.67.24.7 with SMTP id ie7mr2562749pad.112.1382088682074; Fri, 18 Oct 2013 02:31:22 -0700 (PDT)
Received: from [192.168.199.122] ([166.111.68.231]) by mx.google.com with ESMTPSA id rv9sm1183070pbc.4.2013.10.18.02.31.20 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 02:31:21 -0700 (PDT)
From: Qi Sun 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 Oct 2013 17:31:17 +0800
Message-Id: <29A6DD83-8E2B-45AF-8C60-802FDEDEBC5C@gmail.com>
To: draft-farrer-dhc-shared-address-lease@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Cc: " WG" 
Subject: [dhcwg] Comments on draft-farrer-dhc-shared-address-lease
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 09:31:26 -0000

Dear authors,

I read this document and have some comments on it. Please see whether =
the comments are useful for the document.

Best Regards,
Qi



1. General comments:

1) The port set option is expected to be used by a various of mechanisms =
besides DHCPv4 over DHCPv6, like DHCPv4 over IPv6, DHCPv4 over Softwire, =
etc. If we define this option restricted to the context of DHCPv4 over =
DHCPv6, then in v4configuration draft DHCPv4 over IPv6 and DHCPv4 over =
Softwire are not supposed to support the port set allocation, which is =
not true.
2) Section 7 is discussing another topic. IMHO, it would be clearer to =
put it into another draft.=20

2. Some detailed comments:
1) sec 3.1
The sentence of 'The following message flow is transported within the =
DHCPv6 OPTION_BOOTP_MSG message' indicates that the described message =
flow is within the context of DHCPv4 over DHCPv6. So IMHO, it would be =
not necessary to say again those DHCPv4 messages are within =
BOOTPREQUESTV6/BOOTREPLYV6 messages.

2) sec 3.1, bullet 1
The client MAY insert a non-zero value in the PSID-Len field
       within OPTION_PORTPARAMSV4 to indicate the preferred size of the
       restricted port range allocation to the unified server.
=3D> ... to indicate to the 4o6 Server the preferred size of the =
restricted port range allocation.=20

3) sec 3.2
..., with the client's requested port set being included in the =
DHCPDISCOVER message.
DHCPDISCOVER =3D> DHCPREQUEST

4) sec 4
I think not all the functions are expected to be a DHCP client's. The =
client can configure a NAPT within a restricted port range. The rest =
should be done by the NAPT functionalities.

5) sec 6
"This is to maintain compatibility with existing implementations."
There are various implementation of the port set currently. This =
sentence is not necessary here, IMHO.

client MUST use apply this PSID to the interface... =3D> ... MUST apply =
... (remove use)

6) sec 7
   To provide this function, the DHCPV4oDHCPv6 client MAY implement
   OPTION_DHCPV4_O_DHCPV6_SADDR (defined below).  This option is
   included by the client within OPTION_BOOTP_MSG messages and is used
   alongside the DHCPv4 request process

OPTION_DHCPV4_O_DHCPV6_SADDR is a DHCPv6 option. This option should not =
be included in the OPTION_BOOTP_MSG option, which is used for =
encapsulating DHCPv4 messages. The two options are the same level, IMHO.=20=


3. Some nits:
1) Unified Server -> 4o6 Server
2) sec 3.1, bullet 1
transported within the DHCPv6 BOOTPRELAYV6 message =3D> BOOTPREQUESTV6 =
message




From sunqi.csnet.thu@gmail.com  Fri Oct 18 05:22:12 2013
Return-Path: 
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 14E5D11E8276 for ; Fri, 18 Oct 2013 05:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Svwa4awEjqZ0 for ; Fri, 18 Oct 2013 05:22:11 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA8421F9E0D for ; Fri, 18 Oct 2013 05:22:02 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id fa1so4416174pad.5 for ; Fri, 18 Oct 2013 05:21:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=EIAfjPo5Z52Vn5Hjdqn+z/HBBlc5si/AlhW0rUz836I=; b=FkI5qpd+J1/tnQjpYMTfcf+UWcXKnNNxSp48RY7GKxs2IAXhdHhWTbhK5hdUiD7OU1 PnJ6D/4YhW1QZ/vxzc/5r8u+OCW/XnxtLcnEmXdtA2+0fyRnYdgONCUOdOaKxKf/uaxI p03BqtEwFWw0Q1z1vhNwVDbcMnIG4dxEdH7XgOrrZBoSCm6FKDoxAM/E5GWOW5l9gvmM u9eAPbvcbX9M64jW6iGyzZYj9L/1PRLSECe5mEWMnIAl7Nku+XnwpDMHnrMENsZGQVja rbGirVvpjZj21V5Q20o9VwQHJ+ku16Xw8tLHtbSCSVN1+SZuBNaGmKS9W7+OxaDi1kx3 4B/g==
X-Received: by 10.68.215.4 with SMTP id oe4mr784518pbc.198.1382098919558; Fri, 18 Oct 2013 05:21:59 -0700 (PDT)
Received: from [192.168.199.122] ([166.111.68.231]) by mx.google.com with ESMTPSA id ho3sm2100668pbb.23.2013.10.18.05.21.57 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 05:21:58 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-7-64789045
From: Qi Sun 
X-Priority: 1
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1ACF6595@xmb-rcd-x04.cisco.com>
Date: Fri, 18 Oct 2013 20:21:54 +0800
Message-Id: <6F475D99-B239-41B4-BAF7-CA99F97B03E3@gmail.com>
References: <489D13FBFA9B3E41812EA89F188F018E1ACF6595@xmb-rcd-x04.cisco.com>
To: Bernie Volz (volz) 
X-Mailer: Apple Mail (2.1085)
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] Call for Agenda Items for IETF-88 (Vancouver)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 12:22:12 -0000

--Apple-Mail-7-64789045
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


Dear Chairs,
=20
> If you would like time, please indicate:
> -          Draft name or topic
> -          Who will present
> -          How much time is needed
> -          Why is time needed (tell us why you can=92t get what you =
need by posting on the mailing list) and what will be covered

Name: DHCPv4 over DHCPv6 Transport
Presenter: Qi Sun
Time: 10 min
Why: This draft describes a mechanism about configuring IPv4 over IPv6 =
network, and it's on the milestone of the wg.=20
What will be covered: The issues raised during/after the Berlin meeting =
will be discussed.=20
Link: http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6/

Best Regards,
Qi

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


--Apple-Mail-7-64789045
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252




Dear =
Chairs,
 
          Draft name or topic
          Who will present
          How much time is =
needed
- Why is time needed (tell us why you can=92t get =
what you need by posting on the mailing list) and what will be =
covered

Na=
me: DHCPv4 over DHCPv6 Transport
Presenter: Qi =
Sun
Time: 10 min
Why: This draft describes a =
mechanism about configuring IPv4 over IPv6 network, and it's on the =
milestone of the wg. 
What will be covered: The issues =
raised during/after the Berlin meeting will be =
discussed. 
Link: http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6/

Best Regards,
Qi

dhcwg mailing list
dhcwg@ietf.org

Date: Fri, 18 Oct 2013 09:17:35 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 16:17:38 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Dynamic Host Configuration Working Group =
of the IETF.

	Title           : DHCPv4 over DHCPv6 Transport
	Author(s)       : Qi Sun
                          Yong Cui
                          Marcin Siodelski
                          Suresh Krishnan
                          Ian Farrer
	Filename        : draft-ietf-dhc-dhcpv4-over-dhcpv6-02.txt
	Pages           : 13
	Date            : 2013-10-18

Abstract:
   IPv4 connectivity is still needed as networks migrate towards IPv6.
   Users require IPv4 configuration even if the uplink to their service
   provider supports IPv6 only.  This document describes a mechanism for
   obtaining IPv4 configuration information dynamically in IPv6 networks
   by carrying DHCPv4 messages over DHCPv6 transport.  Two new DHCPv6
   messages as well as a new DHCPv6 option are defined for the purpose
   of conveying DHCPv4 messages through IPv6 networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv4-over-dhcpv6-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From sunqi.csnet.thu@gmail.com  Fri Oct 18 09:36:59 2013
Return-Path: 
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 A8A6E11E8271 for ; Fri, 18 Oct 2013 09:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 GjQyCKX0Z2GQ for ; Fri, 18 Oct 2013 09:36:59 -0700 (PDT)
Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id D71B511E825D for ; Fri, 18 Oct 2013 09:36:58 -0700 (PDT)
Received: by mail-pb0-f51.google.com with SMTP id wz7so3205pbc.38 for ; Fri, 18 Oct 2013 09:36:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=rT71c9p8zyt8dmaAIPz7kBPZtHZf1/N8P6FUNr0IUUs=; b=nOYvpZiSOBbN2EkGmzCQn4chpUTOHZdFE6a6GBXEU6xH3P/xgmmp31wAZgNp+TrhCB HhXiRhg1lClHjqYK+IxugPCsfObYZA/QBQ6mJv2begJdu3khjFQVoaK8eMgwXYZ1K6mN 0MXKpvFnbr5mdnOZX87FnsMqOv7cw4wCoCkN8wswLEXs99eJ8x4J7wsgdIlUU4xIAF12 jCd95eD4Lb/QkwWY6c9uuim4ujlyldcj71f95V/ZpTqRmvnLPDwzWt3wW+soVDNxso/q 2fzV1o0PZMKISA5lrasdZyL0X/lNFKI5kJjnwLGC+OSpWEzWVVO3z+3DzWbqnMf12FwY e00A==
X-Received: by 10.68.244.37 with SMTP id xd5mr3841730pbc.47.1382114218582; Fri, 18 Oct 2013 09:36:58 -0700 (PDT)
Received: from [172.20.10.3] ([219.141.159.50]) by mx.google.com with ESMTPSA id py4sm3367175pbb.33.2013.10.18.09.34.39 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 09:36:57 -0700 (PDT)
From: Qi Sun 
Content-Type: multipart/alternative; boundary=Apple-Mail-11-79937785
Date: Sat, 19 Oct 2013 00:34:23 +0800
References: <20131018161735.4087.55554.idtracker@ietfa.amsl.com>
To: "dhcwg@ietf.org WG" 
Message-Id: <79CAAE76-FCDC-49D2-A079-2E753D1B9E51@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Subject: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Oct 2013 16:36:59 -0000

--Apple-Mail-11-79937785
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


Dear all,=20

We have submitted a new version of draft-ietf-dhc-dhcpv4-over-dhcpv6 to =
address the issues raised during/after the Berlin meeting.

1) Update the format of the two newly defined DHCPv6 messages with a =
'flag' field.
1) Define a Unicast Flag to indicate the wrapped DHCPv4 message should =
be unicast or broadcast as in IPv4 environment.
2) Polish the text & correct a couple of nits

Please can you review the draft. Comments are always welcome.=20

Thanks,
Qi


Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: 2013=E5=B9=B410=E6=9C=8819=E6=97=A5 =
=E4=B8=8A=E5=8D=8812=E6=97=B617=E5=88=8635=E7=A7=92=E6=A0=BC=E6=9E=97=E5=B0=
=BC=E6=B2=BB=E6=A0=87=E5=87=86=E6=97=B6=E9=97=B4+0800
> To: i-d-announce@ietf.org
> Cc: dhcwg@ietf.org
> Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-02.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Dynamic Host Configuration Working =
Group of the IETF.
>=20
> 	Title           : DHCPv4 over DHCPv6 Transport
> 	Author(s)       : Qi Sun
>                          Yong Cui
>                          Marcin Siodelski
>                          Suresh Krishnan
>                          Ian Farrer
> 	Filename        : draft-ietf-dhc-dhcpv4-over-dhcpv6-02.txt
> 	Pages           : 13
> 	Date            : 2013-10-18
>=20
> Abstract:
>   IPv4 connectivity is still needed as networks migrate towards IPv6.
>   Users require IPv4 configuration even if the uplink to their service
>   provider supports IPv6 only.  This document describes a mechanism =
for
>   obtaining IPv4 configuration information dynamically in IPv6 =
networks
>   by carrying DHCPv4 messages over DHCPv6 transport.  Two new DHCPv6
>   messages as well as a new DHCPv6 option are defined for the purpose
>   of conveying DHCPv4 messages through IPv6 networks.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-02
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv4-over-dhcpv6-02
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg


--Apple-Mail-11-79937785
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8




Dear =
all, 

We have submitted a new version of =
draft-ietf-dhc-dhcpv4-over-dhcpv6 to address the issues raised =
during/after the Berlin meeting.
1) Update the format of =
the two newly defined DHCPv6 messages with a 'flag' field.
1) Define a Unicast Flag to indicate the =
wrapped DHCPv4 message should be unicast or broadcast as in IPv4 =
environment.
2) Polish the text =
& correct a couple of nits
Please can you review =
the draft. Comments are always welcome. 

Thanks,
Date: 2013=E5=B9=B410=E6=9C=8819=E6=97=A5 =
=E4=B8=8A=E5=8D=8812=E6=97=B617=E5=88=8635=E7=A7=92=E6=A0=BC=E6=9E=97=E5=B0=
=BC=E6=B2=BB=E6=A0=87=E5=87=86=E6=97=B6=E9=97=B4+0800
To: i-d-announce@ietf.org
=

Subject: [dhcwg] I-D =
Action: =
draft-ietf-dhc-dhcpv4-over-dhcpv6-02.txt


=
A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
 This draft is a work item of the Dynamic Host =
Configuration Working Group of the IETF.

	Title =
          : DHCPv4 =
over DHCPv6 Transport
	Author(s) =
      : Qi Sun
 =
            &n=
bsp;           &nbs=
p;Yong Cui
 =
            &n=
bsp;           &nbs=
p;Marcin Siodelski
 =
            &n=
bsp;           &nbs=
p;Suresh Krishnan
 =
            &n=
bsp;           &nbs=
p;Ian Farrer
	=
Filename        : =
draft-ietf-dhc-dhcpv4-over-dhcpv6-02.txt
	Pages =
          : =
13
	=
Date =
           : =
2013-10-18

Abstract:
   IPv4 connectivity is still =
needed as networks migrate towards IPv6.
   Users require =
IPv4 configuration even if the uplink to their service
 =
  provider supports IPv6 only.  This document describes a =
mechanism for
   obtaining IPv4 configuration information =
dynamically in IPv6 networks
   by carrying DHCPv4 messages =
over DHCPv6 transport.  Two new DHCPv6
   messages as =
well as a new DHCPv6 option are defined for the purpose
 =
  of conveying DHCPv4 messages through IPv6 =
networks.


The IETF datatracker status page for this draft =
is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6
There's also a htmlized version available =
at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-02
=

A diff from the previous version is available =
at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv4-over-dhcpv=
6-02


Please note that it may take a couple of minutes from =
the time of submission
until the htmlized version and diff are =
available at tools.ietf.org.

Internet-Drafts are also available =
by anonymous FTP =
at:
ftp://ftp.ietf.org/internet-drafts/

________________________=
_______________________
dhcwg mailing =
list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
<=
/div>

=

--Apple-Mail-11-79937785--

From mglt.ietf@gmail.com  Sun Oct 20 12:51:48 2013
Return-Path: 
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 7B5FF11E825F; Sun, 20 Oct 2013 12:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 CTEuutPXfr7B; Sun, 20 Oct 2013 12:51:47 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6111E822C; Sun, 20 Oct 2013 12:51:46 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id l12so3033587wiv.9 for ; Sun, 20 Oct 2013 12:51:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jMvdc1bz8EZkUq8stk7zUeXuqrPwk0IknSK8cMpVX7g=; b=HCr8BCueDI2mbog0kckcec5EFF1PeOtrREafl477hz8eHKVmclsPcrZ46sNa+fRHwO lqXFrtHrgf+damzIlakl53jVVH8ypHcWzdoXTfdWYRjk2pCr02AeGYMLh9aE3jEOzlG+ BA8uQP+bL3e0K67r2f5DQkPXZctvI6q0WMxhNGaTLLWFLgTlVJOV8i9VJM6CQD84dsdH eG10oLtTGFe7dFwg4Cv+Dn9WDL+k5CoQ0eZ8hi5Gv6M2nsHFiURXDiym7mD5PNojZdac zKsxCZvj/Pay326apP1EAbbBktzrOCNHv2lm4AULddjyzF+9n+V1iatqIZ1WOUd41PoW ZyVw==
MIME-Version: 1.0
X-Received: by 10.194.110.138 with SMTP id ia10mr10884755wjb.3.1382298706134;  Sun, 20 Oct 2013 12:51:46 -0700 (PDT)
Received: by 10.194.41.138 with HTTP; Sun, 20 Oct 2013 12:51:46 -0700 (PDT)
In-Reply-To: <20131020194121.22779.70469.idtracker@ietfa.amsl.com>
References: <20131020194121.22779.70469.idtracker@ietfa.amsl.com>
Date: Sun, 20 Oct 2013 21:51:46 +0200
Message-ID: 
From: Daniel Migault 
To: homenet@ietf.org
Content-Type: multipart/alternative; boundary=047d7bf10aa85a4ef604e9317f54
Cc: dhcwg@ietf.org
Subject: [dhcwg] Fwd: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 19:51:48 -0000

--047d7bf10aa85a4ef604e9317f54
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Please find a description of DHCP options intended to configure the "IPv6
Home Network Naming Delegation". [1]

Feel free to make comments!

Best Regards,
Daniel

URL:
http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt
Htmlized:
http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00

[1]
http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt



---------- Forwarded message ----------
From: 
Date: Sun, Oct 20, 2013 at 9:41 PM
Subject: New Version Notification for
draft-mglt-homenet-naming-architecture-dhc-options-00.txt
To: Wouter Cloetens , Chris Griffiths <
cgriffiths@dyn.com>, Daniel Migault , Ralf Weber <
ralf.weber@nominum.com>



A new version of I-D,
draft-mglt-homenet-naming-architecture-dhc-options-00.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename:        draft-mglt-homenet-naming-architecture-dhc-options
Revision:        00
Title:           DHCP DNS Public Authoritative Server Options
Creation date:   2013-10-20
Group:           Individual Submission
Number of pages: 35
URL:
http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt
Status:
http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options
Htmlized:
http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00


Abstract:
   The home network naming architecture as described in [I-D.mglt-
   homenet-front-end-naming-delegation] requires a complex naming
   configuration on the CPE.  This configuration MAY not be handled
   easily by the average end user.  Furthermore, such misconfiguration
   MAY result in making home network unreachable.

   This document proposes a DHCP options that provide the CPE all
   necessary parameters to set up the home network naming architecture.

   First, this DHCP options provide automatic configuration and avoid
   most end users' misconfiguration.  Most average end users may not
   require specific configuration, and their ISP default configuration
   MAY fully address their needs.  In that case, the naming homenet
   architecture configuration will be completely transparent to the end
   users.  Then, saving naming configuration outside the CPE, makes it
   resilient to change of CPE or CPE upgrades.  Such configuration may
   also be configured by the end user, via the customer area of their
   ISP.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

--047d7bf10aa85a4ef604e9317f54
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi,=A0

Please find a description of DHC=
P options intended to configure the=A0"IPv6 Home Network Naming Delegation".=A0[1]


Feel free to make comments!

Best Regards,=A0
Daniel
---------- F=
orwarded message ----------
From:  <internet-drafts@ietf.org>


Date: Sun, Oct 20, 2013 at 9:41 PM
Subject: New Version Notification for=
 draft-mglt-homenet-naming-architecture-dhc-options-00.txt
To: Wouter Cl=
oetens <wouter.cloetens@softathome.com>, Chris Griffiths <cgriffiths@dyn.com>, Da=
niel Migault <m=
glt.ietf@gmail.com>, Ralf Weber <ralf.weber@nominum.com>






A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-00=
.txt

has been successfully submitted by Daniel Migault and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-mglt-homenet-naming-architecture-dhc-options=


Revision: =A0 =A0 =A0 =A000

Title: =A0 =A0 =A0 =A0 =A0 DHCP DNS Public Authoritative Server Options

Creation date: =A0 2013-10-20

Group: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 35

URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architectu=
re-dhc-options-00.txt



Status: =A0 =A0 =A0 =A0 =A0http://dat=
atracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options

Htmlized: =A0 =A0 =A0 =A0http://tools.i=
etf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00





Abstract:

=A0 =A0The home network naming architecture as described in [I-D.mglt-

=A0 =A0homenet-front-end-naming-delegation] requires a complex naming

=A0 =A0configuration on the CPE. =A0This configuration MAY not be handled
=A0 =A0easily by the average end user. =A0Furthermore, such misconfiguratio=
n

=A0 =A0MAY result in making home network unreachable.



=A0 =A0This document proposes a DHCP options that provide the CPE all

=A0 =A0necessary parameters to set up the home network naming architecture.=




=A0 =A0First, this DHCP options provide automatic configuration and avoid
=A0 =A0most end users' misconfiguration. =A0Most average end users may =
not

=A0 =A0require specific configuration, and their ISP default configuration<=
br>
=A0 =A0MAY fully address their needs. =A0In that case, the naming homenet
=A0 =A0architecture configuration will be completely transparent to the end=


=A0 =A0users. =A0Then, saving naming configuration outside the CPE, makes i=
t

=A0 =A0resilient to change of CPE or CPE upgrades. =A0Such configuration ma=
y

=A0 =A0also be configured by the end user, via the customer area of their
=A0 =A0ISP.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat







-- 
Daniel Migault
Orange =
Labs -- Security
+33 6 70 72 69 58



--047d7bf10aa85a4ef604e9317f54--

From stenc@s-carlsen.dk  Sun Oct 20 15:19:36 2013
Return-Path: 
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 D4A2D11E8290 for ; Sun, 20 Oct 2013 15:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level: 
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 NObGmCuhlifR for ; Sun, 20 Oct 2013 15:19:34 -0700 (PDT)
Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id CE19C11E82A2 for ; Sun, 20 Oct 2013 15:19:32 -0700 (PDT)
Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 449E451DE for ; Mon, 21 Oct 2013 00:19:29 +0200 (CEST)
Message-ID: <526456F0.6090605@s-carlsen.dk>
Date: Mon, 21 Oct 2013 00:19:28 +0200
From: Sten Carlsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <20131020194121.22779.70469.idtracker@ietfa.amsl.com> 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------030002030904040307010108"
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 22:19:36 -0000

This is a multi-part message in MIME format.
--------------030002030904040307010108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi

Having read this lightly and not thoroughly it strikes me that it almost
amounts to hijacking the customers own naming efforts?  If I read this
wrongly, please excuse, my opinions may not be the general opinions.

The way I see this, is that either I know what I want and make my own
DNS-entries or I don't care, in which case there is no meaning in doing
naming for people, specially as these namings will likely not be
meaningful to people.

Just my 0.02EUR

On 20/10/13 21.51, Daniel Migault wrote:
> Hi, 
>
> Please find a description of DHCP options intended to configure
> the "IPv6 Home Network Naming Delegation". [1]
>
> Feel free to make comments!
>
> Best Regards, 
> Daniel
>  
> URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt
> Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00
>
> [1]  http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt
>
>
>
> ---------- Forwarded message ----------
> From: >
> Date: Sun, Oct 20, 2013 at 9:41 PM
> Subject: New Version Notification for
> draft-mglt-homenet-naming-architecture-dhc-options-00.txt
> To: Wouter Cloetens  >, Chris Griffiths
> >, Daniel Migault
> >, Ralf Weber
> >
>
>
>
> A new version of I-D,
> draft-mglt-homenet-naming-architecture-dhc-options-00.txt
> has been successfully submitted by Daniel Migault and posted to the
> IETF repository.
>
> Filename:        draft-mglt-homenet-naming-architecture-dhc-options
> Revision:        00
> Title:           DHCP DNS Public Authoritative Server Options
> Creation date:   2013-10-20
> Group:           Individual Submission
> Number of pages: 35
> URL:            
> http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt
> Status:        
>  http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options
> Htmlized:      
>  http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00
>
>
> Abstract:
>    The home network naming architecture as described in [I-D.mglt-
>    homenet-front-end-naming-delegation] requires a complex naming
>    configuration on the CPE.  This configuration MAY not be handled
>    easily by the average end user.  Furthermore, such misconfiguration
>    MAY result in making home network unreachable.
>
>    This document proposes a DHCP options that provide the CPE all
>    necessary parameters to set up the home network naming architecture.
>
>    First, this DHCP options provide automatic configuration and avoid
>    most end users' misconfiguration.  Most average end users may not
>    require specific configuration, and their ISP default configuration
>    MAY fully address their needs.  In that case, the naming homenet
>    architecture configuration will be completely transparent to the end
>    users.  Then, saving naming configuration outside the CPE, makes it
>    resilient to change of CPE or CPE upgrades.  Such configuration may
>    also be configured by the end user, via the customer area of their
>    ISP.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org
> .
>
> The IETF Secretariat
>
>
>
>
> -- 
> Daniel Migault
> Orange Labs -- Security
> +33 6 70 72 69 58 
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


--------------030002030904040307010108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi

    

    Having read this lightly and not thoroughly it strikes me that it
    almost amounts to hijacking the customers own naming efforts?  If I
    read this wrongly, please excuse, my opinions may not be the general
    opinions.

    

    The way I see this, is that either I know what I want and make my
    own DNS-entries or I don't care, in which case there is no meaning
    in doing naming for people, specially as these namings will likely
    not be meaningful to people.

    

    Just my 0.02€

    

    
On 20/10/13 21.51, Daniel Migault
      wrote:

    

    

      
Hi, 
        


        

        
Please find a description of DHCP options intended to
          configure the "IPv6
            Home Network Naming Delegation". [1]

          

          Feel free to make comments!

        


        

        
Best Regards, 

        
Daniel

        
 

          URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt

          Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00

          

            

          

          
[1]  http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt

          


          

          


          

          


          

          
---------- Forwarded message
            ----------

            From: <internet-drafts@ietf.org>

            Date: Sun, Oct 20, 2013 at 9:41 PM

            Subject: New Version Notification for
            draft-mglt-homenet-naming-architecture-dhc-options-00.txt

            To: Wouter Cloetens <wouter.cloetens@softathome.com>,
            Chris Griffiths <cgriffiths@dyn.com>,
            Daniel Migault <mglt.ietf@gmail.com>,
            Ralf Weber <ralf.weber@nominum.com>

            

            

            

            A new version of I-D,
            draft-mglt-homenet-naming-architecture-dhc-options-00.txt

            has been successfully submitted by Daniel Migault and posted
            to the

            IETF repository.

            

            Filename:      
             draft-mglt-homenet-naming-architecture-dhc-options

            Revision:        00

            Title:           DHCP DNS Public Authoritative Server
            Options

            Creation date:   2013-10-20

            Group:           Individual Submission

            Number of pages: 35

            URL:             http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt

            Status:          http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options

            Htmlized:        http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00

            

            

            Abstract:

               The home network naming architecture as described in
            [I-D.mglt-

               homenet-front-end-naming-delegation] requires a complex
            naming

               configuration on the CPE.  This configuration MAY not be
            handled

               easily by the average end user.  Furthermore, such
            misconfiguration

               MAY result in making home network unreachable.

            

               This document proposes a DHCP options that provide the
            CPE all

               necessary parameters to set up the home network naming
            architecture.

            

               First, this DHCP options provide automatic configuration
            and avoid

               most end users' misconfiguration.  Most average end users
            may not

               require specific configuration, and their ISP default
            configuration

               MAY fully address their needs.  In that case, the naming
            homenet

               architecture configuration will be completely transparent
            to the end

               users.  Then, saving naming configuration outside the
            CPE, makes it

               resilient to change of CPE or CPE upgrades.  Such
            configuration may

               also be configured by the end user, via the customer area
            of their

               ISP.

            

            

            

            

            Please note that it may take a couple of minutes from the
            time of submission

            until the htmlized version and diff are available at tools.ietf.org.

            

            The IETF Secretariat

            

          

          

          

          


          

          -- 

          Daniel Migault

          Orange Labs -- Security

          +33 6 70 72 69 58
        

      

      

      

      

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


    

    

    
-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


  


--------------030002030904040307010108--

From volz@cisco.com  Sun Oct 20 18:10:04 2013
Return-Path: 
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 1766011E8307; Sun, 20 Oct 2013 18:10:04 -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 2LoZtYtj3F3M; Sun, 20 Oct 2013 18:09:59 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A8E4111E80FB; Sun, 20 Oct 2013 18:09:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13025; q=dns/txt; s=iport; t=1382317798; x=1383527398; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=P455eNF/ebFXJfSyHKf38tVWSD7uYtdpYzDw7C/KS24=; b=DPZhAJPqDb4KqyGro59R1st2mz4hqCQFEFCwBA3+Wp7ErkH2eOa+3Vv4 6EBq+al2fqLWA9lNipNBd+JHcvIzO5YIcmR6BGq+c88U+Rm4dzkbafxxb mN2hBOHqj73FfB7tm4vQ4bm0GMKfAUZIdlPvAo3p5wCPQ862WJE/+P9SH Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlMGAHt+ZFKtJXHB/2dsb2JhbABagkNEOKxNiWaITYElFnSCJQEBAQQBAQFrCQIQAgEIDgMBAgECJAQHIQYLFAMGCAIEDgUJh2sDDw20Aw2Ja4xsgUSBGw0EBgEGA4MWgQoDlh6Ba4EviyGFN4FmgT6Bag
X-IronPort-AV: E=Sophos;i="4.93,535,1378857600";  d="scan'208,217";a="274415247"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 21 Oct 2013 01:09:58 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9L19vwb015815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 01:09:57 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Sun, 20 Oct 2013 20:09:57 -0500
From: "Bernie Volz (volz)" 
To: Daniel Migault 
Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-00.txt
Thread-Index: AQHOzc3YL1Pao1qEC0uGX6iM7/BHRJn+WOcf
Date: Mon, 21 Oct 2013 01:09:56 +0000
Message-ID: 
References: <20131020194121.22779.70469.idtracker@ietfa.amsl.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_E47592E33A164AC6A0B866B30B35E34Aciscocom_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" , "homenet@ietf.org" 
Subject: Re: [dhcwg] Fwd: New Version Notification for	draft-mglt-homenet-naming-architecture-dhc-options-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 01:10:04 -0000

--_000_E47592E33A164AC6A0B866B30B35E34Aciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

These are comments with WG co-chair hat off.

I don't recall providing input to this document:


11.  Acknowledgment

We would like to thank Tomasz Mrugalski and Bernie Volz for their
   comments on the design of the DHCP Options.


And at first glance this looks like encapsulation gone crazy!!

I haven't yet read it carefully enough to determine whether this makes sens=
e to do.

I don't like things like requiring a server to return "empty" options if it=
 "understands" them but they were not configured (or "badly" configured). A=
nd I can't see any benefit to the client for doing this documented (there's=
 no special action the client is specified to take) -- so why do it?

- Bernie (from iPad)

On Oct 20, 2013, at 3:52 PM, "Daniel Migault" > wrote:

Hi,

Please find a description of DHCP options intended to configure the "IPv6 H=
ome Network Naming Delegation". [1]

Feel free to make comments!

Best Regards,
Daniel

URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architec=
ture-dhc-options-00.txt
Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture=
-dhc-options-00

[1]  http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-namin=
g-delegation-03.txt



---------- Forwarded message ----------
From: >
Date: Sun, Oct 20, 2013 at 9:41 PM
Subject: New Version Notification for draft-mglt-homenet-naming-architectur=
e-dhc-options-00.txt
To: Wouter Cloetens >, Chris Griffiths >, Daniel Migault >, R=
alf Weber >



A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-00=
.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename:        draft-mglt-homenet-naming-architecture-dhc-options
Revision:        00
Title:           DHCP DNS Public Authoritative Server Options
Creation date:   2013-10-20
Group:           Individual Submission
Number of pages: 35
URL:             http://www.ietf.org/internet-drafts/draft-mglt-homenet-nam=
ing-architecture-dhc-options-00.txt
Status:          http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-=
architecture-dhc-options
Htmlized:        http://tools.ietf.org/html/draft-mglt-homenet-naming-archi=
tecture-dhc-options-00


Abstract:
   The home network naming architecture as described in [I-D.mglt-
   homenet-front-end-naming-delegation] requires a complex naming
   configuration on the CPE.  This configuration MAY not be handled
   easily by the average end user.  Furthermore, such misconfiguration
   MAY result in making home network unreachable.

   This document proposes a DHCP options that provide the CPE all
   necessary parameters to set up the home network naming architecture.

   First, this DHCP options provide automatic configuration and avoid
   most end users' misconfiguration.  Most average end users may not
   require specific configuration, and their ISP default configuration
   MAY fully address their needs.  In that case, the naming homenet
   architecture configuration will be completely transparent to the end
   users.  Then, saving naming configuration outside the CPE, makes it
   resilient to change of CPE or CPE upgrades.  Such configuration may
   also be configured by the end user, via the customer area of their
   ISP.




Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

--_000_E47592E33A164AC6A0B866B30B35E34Aciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







These are comments with WG =
co-chair hat off.







I don't recall providing in=
put to this document:













Hi, 






Please find a description of DHCP options intended to configure the&nb=
sp;"IPv6 H=
ome Network Naming Delegation". [1]



Feel free to make comments!







Best Regards, 


Daniel


 

URL: http://www.ietf.=
org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.t=
xt

Htmlized: http://tools.ietf.org/ht=
ml/draft-mglt-homenet-naming-architecture-dhc-options-00







[1]  http://www.ietf.o=
rg/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt

















---------- Forwarded message ----------

From: <internet-drafts@ietf.org>

Date: Sun, Oct 20, 2013 at 9:41 PM

Subject: New Version Notification for draft-mglt-homenet-naming-architectur=
e-dhc-options-00.txt

To: Wouter Cloetens <wouter.cloetens@softathome.com>, Chris Griffiths &l=
t;cgriffiths@dyn.co=
m>, Daniel Migault <mglt.ietf@gmail.com>,
 Ralf Weber <ralf.weber@nominum.com>







A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-00=
.txt

has been successfully submitted by Daniel Migault and posted to the

IETF repository.



Filename:        draft-mglt-homenet-naming-architecture=
-dhc-options

Revision:        00

Title:           DHCP DNS Public Authoritative Ser=
ver Options

Creation date:   2013-10-20

Group:           Individual Submission

Number of pages: 35

URL:             
http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-=
dhc-options-00.txt

Status:          http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture=
-dhc-options

Htmlized:        ht=
tp://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options=
-00





Abstract:

   The home network naming architecture as described in [I-D.mglt=
-

   homenet-front-end-naming-delegation] requires a complex naming=


   configuration on the CPE.  This configuration MAY not be =
handled

   easily by the average end user.  Furthermore, such miscon=
figuration

   MAY result in making home network unreachable.



   This document proposes a DHCP options that provide the CPE all=


   necessary parameters to set up the home network naming archite=
cture.



   First, this DHCP options provide automatic configuration and a=
void

   most end users' misconfiguration.  Most average end users=
 may not

   require specific configuration, and their ISP default configur=
ation

   MAY fully address their needs.  In that case, the naming =
homenet

   architecture configuration will be completely transparent to t=
he end

   users.  Then, saving naming configuration outside the CPE=
, makes it

   resilient to change of CPE or CPE upgrades.  Such configu=
ration may

   also be configured by the end user, via the customer area of t=
heir

   ISP.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at 
tools.ietf.org.



The IETF Secretariat














-- 

Daniel Migault

Orange Labs -- Security

+33 6 70 72 69 58











_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.i=
etf.org/mailman/listinfo/dhcwg








--_000_E47592E33A164AC6A0B866B30B35E34Aciscocom_--

From leo.liubing@huawei.com  Mon Oct 21 00:01:50 2013
Return-Path: 
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 8016211E810C for ; Mon, 21 Oct 2013 00:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.448
X-Spam-Level: 
X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 f2hoWs0g6RXS for ; Mon, 21 Oct 2013 00:01:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09211E8178 for ; Mon, 21 Oct 2013 00:01:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZG98917; Mon, 21 Oct 2013 07:01:40 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 08:00:41 +0100
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 08:01:37 +0100
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Mon, 21 Oct 2013 15:01:31 +0800
From: "Liubing (Leo)" 
To: "Bernie Volz (volz)" , "dhcwg@ietf.org" 
Thread-Topic: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends November 11, 2013
Thread-Index: Ac7K6RYO6IlqgYnCS8a24Ug8i2UzUgDQipYg
Date: Mon, 21 Oct 2013 07:01:31 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CADF7@nkgeml506-mbx.china.huawei.com>
References: <489D13FBFA9B3E41812EA89F188F018E1AD20B47@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD20B47@xmb-rcd-x04.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.132]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7CADF7nkgeml506mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends November 11, 2013
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 07:01:50 -0000

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7CADF7nkgeml506mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, All

I'm in favor of adopting it.

B.R.
Bing

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B=
ernie Volz (volz)
Sent: Thursday, October 17, 2013 11:31 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends Nove=
mber 11, 2013


Hi all:



The author has requested a call for adoption by the WG for draft-jiang-dhc-=
sedhcpv6-02. (This document "replaces" http://tools.ietf.org/html/draft-iet=
f-dhc-secure-dhcpv6-07 as that document went to the IESG - see https://data=
tracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ for more details. The ne=
w document is very different so please read it.)



This call is being initiated to confirm whether there is WG consensus to ad=
opt this work as DHC WG draft. Please state whether or not you're in favor =
of the adoption by replying to this mail. If you are not in favor, please a=
lso state your objections in your response. This adoption call will complet=
e on November 11, 2013 - after the IETF meeting as it will likely be on the=
 DHC WG agenda.



The HTML version of the document can be viewed at http://tools.ietf.org/htm=
l/draft-jiang-dhc-sedhcpv6.



Regards,

Tomek & Bernie


--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7CADF7nkgeml506mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi, All


 


I’m in favor of adopting it.


 


B.R.


Bing


 








From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org=
]
On Behalf Of Bernie Volz (volz)

Sent: Thursday, October 17, 2013 11:31 AM

To: dhcwg@ietf.org

Subject: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - En=
ds November 11, 2013






 


Hi all:

 


The author has requested a c=
all for adoption by the WG for draft-jiang-dhc-sedhcpv6-02. (This document =
“replaces”
http=
://tools.ietf.org/html/draft-ietf-dhc-secure-dhcpv6-07 as that document=
 went to the IESG – see
=
https://datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ for more=
 details. The new document is very different so please read it.)=



 


This call is being initiated=
 to confirm whether there is WG consensus to adopt this work as DHC WG draf=
t. Please state whether or not you're in favor of the adoption by replying =
to this mail. If you are not in favor,
 please also state your objections in your response. This adoption call wil=
l complete on November 11, 2013 – after the IETF meeting as it will l=
ikely be on the DHC WG agenda.


 


The HTML version of the docu=
ment can be viewed at
http://tool=
s.ietf.org/html/draft-jiang-dhc-sedhcpv6.


 


Regards,

Tomek & Bernie


 








--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7CADF7nkgeml506mbxchi_--

From internet-drafts@ietf.org  Mon Oct 21 03:18:42 2013
Return-Path: 
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 3C05D11E835B; Mon, 21 Oct 2013 03:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level: 
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 LjQYX9G3Kpv9; Mon, 21 Oct 2013 03:18:41 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4050311E8372; Mon, 21 Oct 2013 03:18:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131021101837.29508.24538.idtracker@ietfa.amsl.com>
Date: Mon, 21 Oct 2013 03:18:37 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-access-network-identifier-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 10:18:42 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Dynamic Host Configuration Working Group =
of the IETF.

	Title           : Access-Network-Identifier Option in DHCP
	Author(s)       : Shwetha Bhandari
                          Sri Gundavelli
                          Jouni Korhonen
                          Mark Grayson
	Filename        : draft-ietf-dhc-access-network-identifier-01.txt
	Pages           : 17
	Date            : 2013-10-21

Abstract:
   This document specifies the format and mechanism for encoding access
   network identifiers in DHCPv4 and DHCPv6 messages by defining new
   access network identifier options and sub-options.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-access-network-identifier=
-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From mglt.ietf@gmail.com  Mon Oct 21 04:21:23 2013
Return-Path: 
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 8915D11E814F for ; Mon, 21 Oct 2013 04:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 whO9d2yr5cu1 for ; Mon, 21 Oct 2013 04:21:20 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C94E811E83A3 for ; Mon, 21 Oct 2013 04:21:10 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id n12so6386697wgh.35 for ; Mon, 21 Oct 2013 04:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IS0R8jtn2HGrPU/jZhecYFDg/NXLZS1nytctEdXTBWA=; b=eTQV4Ma/V4hAwCeRGgIFTezr1LbaLRfc2LYBCAWcuL4sX5MvHEivCbZLx4G93RyCr8 VHm7+igAoteNQHT7uWZCWvyI6Fb22qf5HJhC0uHAnZDjkADx95/kBCVNVAI/vMytlesp pikPk05LbZyCPsc6TY/kn+Qwl2h4Pkyg627muaOVvI/7gMJzwqjwdn1a/dUhptgHBqQW yewDcedvnjr8IELeftFWQkZ0fCegPIz6bIt8jl4gv/QnYoh4W7Xr0Q8Pu3JzUgksR0sZ o8RuenV6CXOxqBcOpMg9UicjoGAg0pU26ZqtoqUQK3lSv4329qcPVhVa71Ogl6tDzEV/ jC2A==
MIME-Version: 1.0
X-Received: by 10.194.248.130 with SMTP id ym2mr1222405wjc.61.1382354468860; Mon, 21 Oct 2013 04:21:08 -0700 (PDT)
Received: by 10.194.41.138 with HTTP; Mon, 21 Oct 2013 04:21:08 -0700 (PDT)
In-Reply-To: <526456F0.6090605@s-carlsen.dk>
References: <20131020194121.22779.70469.idtracker@ietfa.amsl.com>  <526456F0.6090605@s-carlsen.dk>
Date: Mon, 21 Oct 2013 13:21:08 +0200
Message-ID: 
From: Daniel Migault 
To: Sten Carlsen 
Content-Type: multipart/alternative; boundary=089e013d144211f6c504e93e7bbd
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 11:21:23 -0000

--089e013d144211f6c504e93e7bbd
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for reading it even "lightly and not thoroughly" ;-). My response is
in the text below and we will try to make it clearer in the next versions.

On Mon, Oct 21, 2013 at 12:19 AM, Sten Carlsen  wrote:

>  Hi
>
> Having read this lightly and not thoroughly it strikes me that it almost
> amounts to hijacking the customers own naming efforts?  If I read this
> wrongly, please excuse, my opinions may not be the general opinions.
>
> Actually that is the reverse. The DHCP options  makes possible for a user
to define its naming configuration for the homenet and push it to any CPE
that is plugged. This avoids reconfiguration when changing CPE or when the
CPE settups are erased.
Although specific configuration may concern a fraction of end users, we
believe the large portion of end users, prefers a default naming settings
that may be proposed by the DHCP.


> The way I see this, is that either I know what I want and make my own
> DNS-entries or I don't care, in which case there is no meaning in doing
> naming for people, specially as these namings will likely not be meaningf=
ul
> to people.
>
> Well, most of our end users do not really care about configuring DNS
architectures for their home network. At most they want it to work on a
specific domain name "example.com" so they can reach there service like "
myvideo.example.com"  from outside the homenet. This latest name is
meaningful for them, they are interested in the naming service to work
properly. However,  they are not interested in deep understanding of the
naming architecture and most probably not in how to perform key roll over.
It looks these end users are just in between your two alternatives.

Note also that you can also just ignore the DHCP Options.

Just my 0.02=80
>
>
> On 20/10/13 21.51, Daniel Migault wrote:
>
> Hi,
>
>  Please find a description of DHCP options intended to configure the "IPv=
6
> Home Network Naming Delegation". [1]
>
> Feel free to make comments!
>
>  Best Regards,
> Daniel
>
> URL:
> http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architectur=
e-dhc-options-00.txt
> Htmlized:
> http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-opt=
ions-00
>
>  [1]
> http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-d=
elegation-03.txt
>
>
>
>  ---------- Forwarded message ----------
> From: 
> Date: Sun, Oct 20, 2013 at 9:41 PM
> Subject: New Version Notification for
> draft-mglt-homenet-naming-architecture-dhc-options-00.txt
> To: Wouter Cloetens , Chris Griffiths <
> cgriffiths@dyn.com>, Daniel Migault , Ralf Weber <
> ralf.weber@nominum.com>
>
>
>
> A new version of I-D,
> draft-mglt-homenet-naming-architecture-dhc-options-00.txt
> has been successfully submitted by Daniel Migault and posted to the
> IETF repository.
>
> Filename:        draft-mglt-homenet-naming-architecture-dhc-options
> Revision:        00
> Title:           DHCP DNS Public Authoritative Server Options
> Creation date:   2013-10-20
> Group:           Individual Submission
> Number of pages: 35
> URL:
> http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architectur=
e-dhc-options-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dh=
c-options
> Htmlized:
> http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-opt=
ions-00
>
>
> Abstract:
>    The home network naming architecture as described in [I-D.mglt-
>    homenet-front-end-naming-delegation] requires a complex naming
>    configuration on the CPE.  This configuration MAY not be handled
>    easily by the average end user.  Furthermore, such misconfiguration
>    MAY result in making home network unreachable.
>
>    This document proposes a DHCP options that provide the CPE all
>    necessary parameters to set up the home network naming architecture.
>
>    First, this DHCP options provide automatic configuration and avoid
>    most end users' misconfiguration.  Most average end users may not
>    require specific configuration, and their ISP default configuration
>    MAY fully address their needs.  In that case, the naming homenet
>    architecture configuration will be completely transparent to the end
>    users.  Then, saving naming configuration outside the CPE, makes it
>    resilient to change of CPE or CPE upgrades.  Such configuration may
>    also be configured by the end user, via the customer area of their
>    ISP.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
>  --
> Daniel Migault
> Orange Labs -- Security
> +33 6 70 72 69 58
>
>
> _______________________________________________
> dhcwg mailing listdhcwg@ietf.orghttps://www.ietf.org/mailman/listinfo/dhc=
wg
>
>
> --
> Best regards
>
> Sten Carlsen
>
> No improvements come from shouting:
>
>        "MALE BOVINE MANURE!!!"
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>


--=20
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

--089e013d144211f6c504e93e7bbd
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hi, 

Thanks for reading it even "lightly and not thoroughly&q=
uot; ;-). My response is in the text below and we will try to make it clear=
er in the next versions.



On Mon, Oct=
 21, 2013 at 12:19 AM, Sten Carlsen <stenc@s-carlsen.dk> wr=
ote:



 =20
   =20
 =20
  

    Hi

    

    Having read this lightly and not thoroughly it strikes me that it
    almost amounts to hijacking the customers own naming efforts?=A0 If I
    read this wrongly, please excuse, my opinions may not be the general
    opinions.

    
Actually that is the reverse. The DHCP opti=
ons=A0 makes possible for a user to define its naming configuration for the=
 homenet and push it to any CPE that is plugged. This avoids reconfiguratio=
n when changing CPE or when the CPE settups are erased.


Although specific configuration may concern a fraction of end us=
ers, we believe the large portion of end users, prefers a default naming se=
ttings that may be proposed by the DHCP.
=A0



    The way I see this, is that either I know what I want and make my
    own DNS-entries or I don't care, in which case there is no meaning
    in doing naming for people, specially as these namings will likely
    not be meaningful to people.

    
Well, most of our end users do not really c=
are about configuring DNS architectures for their home network. At most the=
y want it to work on a specific domain name "example.com" so they can reach there service like "myvideo.example.com"=A0 from ou=
tside the homenet. This latest name is meaningful for them, they are intere=
sted in the naming service to work properly. However,=A0 they are not inter=
ested in deep understanding of the naming architecture and most probably no=
t in how to perform key roll over. It looks these end users are just in bet=
ween your two alternatives.


Note also that you can also just ignore the DHCP Options.



    Just my 0.02=80


    

    
On 20/10/13 21.51, Daniel Migault
      wrote:

    

    

      
Hi,=A0
        


        

        
Please find a description of DHCP options intended to
          configure the=A0"IPv6
            Home Network Naming Delegation".=A0[1]

          

          Feel free to make comments!

        


        

        
Best Regards,=A0

        
Daniel

        
=A0

          URL:=A0http://ww=
w.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-optio=
ns-00.txt


          Htmlized:=A0http://tools.ietf=
.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00

          

            

          

          
[1]=A0=A0http://www.ie=
tf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.tx=
t


          


          

          


          

          


          

          
---------- Forwarded message
            ----------

            From: <internet-drafts@ietf.org>

            Date: Sun, Oct 20, 2013 at 9:41 PM

            Subject: New Version Notification for
            draft-mglt-homenet-naming-architecture-dhc-options-00.txt

            To: Wouter Cloetens <wouter.cloetens@softathome.com>,
            Chris Griffiths <cgriffiths@dyn.com>,
            Daniel Migault <mglt.ietf@gmail.com>,
            Ralf Weber <ralf.weber@nominum.com>

            

            

            

            A new version of I-D,
            draft-mglt-homenet-naming-architecture-dhc-options-00.txt

            has been successfully submitted by Daniel Migault and posted
            to the

            IETF repository.

            

            Filename: =A0 =A0 =A0
            =A0draft-mglt-homenet-naming-architecture-dhc-options

            Revision: =A0 =A0 =A0 =A000

            Title: =A0 =A0 =A0 =A0 =A0 DHCP DNS Public Authoritative Server
            Options

            Creation date: =A0 2013-10-20

            Group: =A0 =A0 =A0 =A0 =A0 Individual Submission

            Number of pages: 35

            URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-mglt-homenet-namin=
g-architecture-dhc-options-00.txt


            Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dh=
c-options


            Htmlized: =A0 =A0 =A0 =A0ht=
tp://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options=
-00


            

            

            Abstract:

            =A0 =A0The home network naming architecture as described in
            [I-D.mglt-

            =A0 =A0homenet-front-end-naming-delegation] requires a complex
            naming

            =A0 =A0configuration on the CPE. =A0This configuration MAY not =
be
            handled

            =A0 =A0easily by the average end user. =A0Furthermore, such
            misconfiguration

            =A0 =A0MAY result in making home network unreachable.

            

            =A0 =A0This document proposes a DHCP options that provide the
            CPE all

            =A0 =A0necessary parameters to set up the home network naming
            architecture.

            

            =A0 =A0First, this DHCP options provide automatic configuration
            and avoid

            =A0 =A0most end users' misconfiguration. =A0Most average en=
d users
            may not

            =A0 =A0require specific configuration, and their ISP default
            configuration

            =A0 =A0MAY fully address their needs. =A0In that case, the nami=
ng
            homenet

            =A0 =A0architecture configuration will be completely transparen=
t
            to the end

            =A0 =A0users. =A0Then, saving naming configuration outside the
            CPE, makes it

            =A0 =A0resilient to change of CPE or CPE upgrades. =A0Such
            configuration may

            =A0 =A0also be configured by the end user, via the customer are=
a
            of their

            =A0 =A0ISP.

            

            

            

            

            Please note that it may take a couple of minutes from the
            time of submission

            until the htmlized version and diff are available at tools.ietf.org.

            

            The IETF Secretariat

            

          

          

          

          


          

          -- 

          Daniel Migault

          Orange Labs -- Security

          +33 6 70 72 69 58
        

      

      

      

      

      
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/dhcwg


    

    

    
--=20
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"=20


  



_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/dhcwg





-- 
Daniel Migault
O=
range Labs -- Security
+33 6 70 72 69 58



--089e013d144211f6c504e93e7bbd--

From msiodelski@gmail.com  Mon Oct 21 04:25:38 2013
Return-Path: 
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 7BB9311E8190 for ; Mon, 21 Oct 2013 04:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 h2brczM-C3PY for ; Mon, 21 Oct 2013 04:25:32 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2019711E8189 for ; Mon, 21 Oct 2013 04:25:30 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id eh20so389118lab.25 for ; Mon, 21 Oct 2013 04:25:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=rwjHuZxhb3M6c/8G3gUiIKjUrtToaD1iX0pAKEqjm8U=; b=p3CgOsLq4oLpbqiLbyszLRnj3oBT421yDnctzScrPcSAyDhyG/ejPPa4c06CXowuab erVDIBujdKwSZ2cID8TOCYIp+/5PRyMV78zL4Mm5HJFs8jQKsjmZjkjUqtQPyVu50eks dYMGHt9IEG5OP2UsnXA/oAUKoN6bC+4quFTjDW9X10jrp+zHcvYIOInDJYyCPH9UnHQK DugZ2dID8D6yNO1SmRTjGswEKMjfE9b4HWRpBSiMh+JTUm/kRvcNNnhZRGb5WntUjYtW RVUo0hoSNpeZAHbNZY0svmrp76m40My7ALtbf0ScfCBIbEot01UeyBube1UBV3iHJSFh gbtw==
MIME-Version: 1.0
X-Received: by 10.152.44.133 with SMTP id e5mr725343lam.58.1382354729984; Mon, 21 Oct 2013 04:25:29 -0700 (PDT)
Received: by 10.112.72.42 with HTTP; Mon, 21 Oct 2013 04:25:29 -0700 (PDT)
Date: Mon, 21 Oct 2013 13:25:29 +0200
Message-ID: 
From: Marcin Siodelski 
To: "ian.farrer@telekom.de" 
Content-Type: multipart/alternative; boundary=089e0160a478a2697504e93e8a4e
Cc: "" 
Subject: [dhcwg] A few comments about draft-farrer-dhc-shared-address-lease-00
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 11:25:39 -0000

--089e0160a478a2697504e93e8a4e
Content-Type: text/plain; charset=ISO-8859-1

Ian,

I apologize for doing a review so late before IETF. I should have done that
a few weeks ago. A few (hopefully useful) comments...

Abstract

With respect to this:
"This memo describes an update to [RFC2131], which enables the dynamic
leasing of shared IPv4 address and layer 4 source ports to DHCPv4 over
DHCPv6 clients [I-D. etf-dhc-dhcpv4-over-dhcpv6]."

Is it intended to restrict shared addresses functionality to
DHCPv4-over-DHCPv6 clients? It is ok that the draft addresses a specific,
real life use cases, but if it is possible to implement it as a more
generic approach, the document should strive to make it sound generic.

It may be useful to provide a definition of DHCPv4-over-DHCPv6 client
(which is a term used multiple times throughout the document). Although,
there is a reference to the DHCPv4-over-DHCPv6 draft, this draft doesn't
provide a definition for it. Some form of the glossary may be useful.

Introduction:
"[I-D.ietf-dhcp-dhcpv4-over-dhcpv6] introduces a Unified Server..."

After one of the reviews we have changed the terminology in the DHCPv4 over
DHCPv6 draft and we refer to the server processing DHCPv4 requests over
DHCPv6 protocol as "4o6 Server".

3.1 Allocation a Shared, Dynamic IPv4 Address
"The process described below detail...". Should it be "The process
described below details...." ?

Since, the draft is intended to update RFC2131, it should be mentioned what
the server which doesn't support the Dynamic Shared addresses should do
when it receives a message with the OPTION_PORTPARAMSV4. Should it ignore
the message? What should do the server which supports this extension (and
is configured to use it) but haven't received the OPTION_PORTPARAMSV4
option from the client.

3.1.2.
"... within the BOOTPRELAYV6 message  may respond with a DHCPOFFER ...".

Suggest to use MAY instead of "may".

3.1.3. It may be implicitly assumed, because RFC2131 describes the message
exchange process in detail, but IMHO it should be mentioned that client
MUST include yiaddr in DHCPREQUEST to indicate the desired configuration
(besides PSID). Also, the DHCPREQUEST message MUST contain the Client
Identifier (the same that was used to create DHCPDISCOVER).

3.1.5.
In the RFC2131 sections: 2.2 and 3.1 it is said that server SHOULD or MAY
probe that the address being assigned is already in use. The draft is
intended to update RFC2131 so it should be mentioned that server MUST NOT
probe that the address being assigned is in use using ICMP Echo. The text
about client not performing final check is fine obviously.

3.2. Reusing a Previously Allocated Shared, Dynamic IPv4 address

"OPTION_PORTPARAMSV4 MUST be included in the message flow, with the
client's requested port set being included in the DHCPDISCOVER message".

Note that section 3.2 of RFC2131 doesn't mention DISCOVER. The whole
communication is based on 2-way exchange DHCPREQUEST/DHCPACK. Did you mean
DHCPREQUEST?

Although, I support the idea to refer to the draft being updated rather
than rewriting whole sections, but in this case it may be unavoidable. For
example:
- With the standard DHCP, the client will broadcast REQUEST which is not
the case for the Shared Dynamic allocation.
- normally server would broadcast the DHCPNAK if requested binding is
invalid (expired or whatever), it is not the case here.
- Client MUST not perform final check on the assigned address when Shared
Dynamic allocation is used (RFC2131 section 3.2. says it does).

What I mean here is that there are two many disparities between the bare
DHCP protocol described in the RFC2131 and extension described in your
draft to be just able to say: "The RFC2131 is followed with the exception
that OPTION_PORTPARAMSV4 must be included everywhere."

5. Additional Changes to RFC2131 Behvaiour
Neither should server probe IPv4 addresses assigned.

6. Typo: MUST use apply. Should be MUST apply.

7. Specific Behaviour for Softwire Clients
I would rather see this section in the different draft and leave this one a
more generic extension to DHCPv4 to simply allocate IPv4 address + PSID.

8. DHCPv4 over DHCPv6 Source Address Option
The format of the option is wrong. The fields holding lengths of the
variable length fields should be laid before the variable length fields as
typically the server would parse the option from the beginning to the end.

cipv6-prefix-hint is not described

What are the minimal lengths of the prefixes (and minimal length of the
option)? Blank prefix means length=0?

Marcin

--089e0160a478a2697504e93e8a4e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Ian,

I apologize for doing a=
 review so late before IETF. I should have done that a few weeks ago. A few=
 (hopefully useful) comments...=A0

Abstract



With respect to this:
"This memo describes an update to=
 [RFC2131], which enables the dynamic leasing of shared IPv4 address and la=
yer 4 source ports to DHCPv4 over DHCPv6 clients [I-D. etf-dhc-dhcpv4-over-=
dhcpv6]."



Is it intended to restrict shared addresses funct=
ionality to DHCPv4-over-DHCPv6 clients? It is ok that the draft addresses a=
 specific, real life use cases, but if it is possible to implement it as a =
more generic approach, the document should strive to make it sound generic.=




It may be useful to provide a definition of DHCPv=
4-over-DHCPv6 client (which is a term used multiple times throughout the do=
cument). Although, there is a reference to the DHCPv4-over-DHCPv6 draft, th=
is draft doesn't provide a definition for it. Some form of the glossary=
 may be useful.



Introduction:
"[I-D.ietf-dhcp-dhcpv4-ove=
r-dhcpv6] introduces a Unified Server..."

Aft=
er one of the reviews we have changed the terminology in the DHCPv4 over DH=
CPv6 draft and we refer to the server processing DHCPv4 requests over DHCPv=
6 protocol as "4o6 Server".=A0



3.1 Allocation a Shared, Dynamic IPv4 Address
"The process described below detail...". Should it be "The =
process described below details...." ?

Since,=
 the draft is intended to update RFC2131, it should be mentioned what the s=
erver which doesn't support the Dynamic Shared addresses should do when=
 it receives a message with the OPTION_PORTPARAMSV4. Should it ignore the m=
essage? What should do the server which supports this extension (and is con=
figured to use it) but haven't received the OPTION_PORTPARAMSV4 option =
from the client.



3.1.2.=A0
"... within the BOOTPRELAYV6 m=
essage =A0may respond with a DHCPOFFER ...".

=
Suggest to use MAY instead of "may".

3.1=
.3. It may be implicitly assumed, because RFC2131 describes the message exc=
hange process in detail, but IMHO it should be mentioned that client MUST i=
nclude yiaddr in DHCPREQUEST to indicate the desired configuration (besides=
 PSID). Also, the DHCPREQUEST message MUST contain the Client Identifier (t=
he same that was used to create DHCPDISCOVER).=A0



3.1.5.=A0
In the RFC2131 sections: 2.2 and 3.=
1 it is said that server SHOULD or MAY probe that the address being assigne=
d is already in use. The draft is intended to update RFC2131 so it should b=
e mentioned that server MUST NOT probe that the address being assigned is i=
n use using ICMP Echo. The text about client not performing final check is =
fine obviously.



3.2. Reusing a Previously Allocated Shared, Dynamic IPv=
4 address

"OPTION_PORTPARAMSV4 MUST be includ=
ed in the message flow, with the client's requested port set being incl=
uded in the DHCPDISCOVER message".



Note that section 3.2 of RFC2131 doesn't mention DI=
SCOVER. The whole communication is based on 2-way exchange DHCPREQUEST/DHCP=
ACK. Did you mean DHCPREQUEST?

Although, I support=
 the idea to refer to the draft being updated rather than rewriting whole s=
ections, but in this case it may be unavoidable. For example:=A0


- With the standard DHCP, the client will broadcast REQUEST which is n=
ot the case for the Shared Dynamic allocation.
- normally server =
would broadcast the DHCPNAK if requested binding is invalid (expired or wha=
tever), it is not the case here.


- Client MUST not perform final check on the assigned address when Sha=
red Dynamic allocation is used (RFC2131 section 3.2. says it does).

What I mean here is that there are two many disparities b=
etween the bare DHCP protocol described in the RFC2131 and extension descri=
bed in your draft to be just able to say: "The RFC2131 is followed wit=
h the exception that OPTION_PORTPARAMSV4 must be included everywhere."=




5. Additional Changes to RFC2131 Behvaiour
Ne=
ither should server probe IPv4 addresses assigned.

6. Typo: MUST use apply. Should be MUST apply.


7. Specific Behaviour for Softwire Clients
I would rather see thi=
s section in the different draft and leave this one a more generic extensio=
n to DHCPv4 to simply allocate IPv4 address + PSID.



8. DHCPv4 over DHCPv6 Source Address Option
The format of th=
e option is wrong. The fields holding lengths of the variable length fields=
 should be laid before the variable length fields as typically the server w=
ould parse the option from the beginning to the end.



cipv6-prefix-hint is not described

=

What are the minimal lengths of the prefixes (and minimal length of th=
e option)? Blank prefix means length=3D0?

Marcin



--089e0160a478a2697504e93e8a4e--

From mglt.ietf@gmail.com  Mon Oct 21 04:54:25 2013
Return-Path: 
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 0E91011E84AF; Mon, 21 Oct 2013 04:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 xBNzg1jPFggZ; Mon, 21 Oct 2013 04:54:23 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AAAD711E83B0; Mon, 21 Oct 2013 04:54:10 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id cb5so3784091wib.7 for ; Mon, 21 Oct 2013 04:53:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gex2xXdzhRt6b5RbT6RbmTFr0i4t0g/HeffxS/99mdE=; b=MM9H4qt83XnXd/hwdLXPoEAgVeksOp8KbgMRPxV3E4eu/eHjrdQ63CPvY3iYm7LLjD fCs8tHO2faS9ubHDVcADFkWoFdt8X+cuwWaUTZwwD6fvlgv78qTswbMtJrSk5d9fhyJV mOtEiGJ0VEdUSXql601YmYi0UtqOW9BZanrFXa6DH0D9axV+1Kl+13FPwhGehykMTuT4 ryXMwcLyYJrx2KLM5SPPvTNO8w5/VLVz988+30NZsy2vTwVSUX3k/FSHe+nFOk1LQc72 h+yd9ZD7lc1vJxS25KZn2kims9VJiBB3c7XnEXG3I6N/yCrcBosC626n78Puzf8TFIoM y5FA==
MIME-Version: 1.0
X-Received: by 10.180.206.178 with SMTP id lp18mr9495063wic.40.1382356439027;  Mon, 21 Oct 2013 04:53:59 -0700 (PDT)
Received: by 10.194.41.138 with HTTP; Mon, 21 Oct 2013 04:53:58 -0700 (PDT)
In-Reply-To: 
References: <20131020194121.22779.70469.idtracker@ietfa.amsl.com>  
Date: Mon, 21 Oct 2013 13:53:58 +0200
Message-ID: 
From: Daniel Migault 
To: "Bernie Volz (volz)" 
Content-Type: multipart/alternative; boundary=001a11c3844a80586404e93ef0df
Cc: "dhcwg@ietf.org" , "homenet@ietf.org" 
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 11:54:25 -0000

--001a11c3844a80586404e93ef0df
Content-Type: text/plain; charset=ISO-8859-1

Hi Bernie,

Thanks for your feed back. See my comments in the text.

On Mon, Oct 21, 2013 at 3:09 AM, Bernie Volz (volz)  wrote:

>  These are comments with WG co-chair hat off.
>
>  I don't recall providing input to this document:
>
>  11 .  Acknowledgment
>
> We would like to thank Tomasz Mrugalski and Bernie Volz for their
>    comments on the design of the DHCP Options.
>
>
>  We received comments and recommendations from the previous version on
Jul 05 -- Basically splitting the complex option we proposed, and following
(and reading) the guide lines. We expected to present our new design at
IETF87, but ran out schedule.

 And at first glance this looks like encapsulation gone crazy!!
>

This is also my opinion. My understanding of the option guidelines was to
use encapsulation of options instead of specific format. We might have
mis-understood something or gone too far. Either ways I am very glad to
have your feed backs. We can easily remove some encapsulations.


>  I haven't yet read it carefully enough to determine whether this makes
> sense to do.
>
>  There is no complex or hidden reasons for encapsulation. We might have
done it the wrong way. This version is expected to be a document for
discussion. We hope next versions converge quickly.



>  I don't like things like requiring a server to return "empty" options if
> it "understands" them but they were not configured (or "badly" configured).
> And I can't see any benefit to the client for doing this documented
> (there's no special action the client is specified to take) -- so why do it?
>
> The only benefit for the client is that it can decide between sending a
message with "Options not supported" or "Badly configured Homenet Naming
Architectures". We can remove this requirement.


> - Bernie (from iPad)
>
> On Oct 20, 2013, at 3:52 PM, "Daniel Migault"  wrote:
>
>   Hi,
>
>  Please find a description of DHCP options intended to configure the "IPv6
> Home Network Naming Delegation". [1]
>
> Feel free to make comments!
>
>  Best Regards,
> Daniel
>
> URL:
> http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt
> Htmlized:
> http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00
>
>  [1]
> http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt
>
>
>
>  ---------- Forwarded message ----------
> From: 
> Date: Sun, Oct 20, 2013 at 9:41 PM
> Subject: New Version Notification for
> draft-mglt-homenet-naming-architecture-dhc-options-00.txt
> To: Wouter Cloetens , Chris Griffiths <
> cgriffiths@dyn.com>, Daniel Migault , Ralf Weber <
> ralf.weber@nominum.com>
>
>
>
> A new version of I-D,
> draft-mglt-homenet-naming-architecture-dhc-options-00.txt
> has been successfully submitted by Daniel Migault and posted to the
> IETF repository.
>
> Filename:        draft-mglt-homenet-naming-architecture-dhc-options
> Revision:        00
> Title:           DHCP DNS Public Authoritative Server Options
> Creation date:   2013-10-20
> Group:           Individual Submission
> Number of pages: 35
> URL:
> http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options
> Htmlized:
> http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00
>
>
> Abstract:
>    The home network naming architecture as described in [I-D.mglt-
>    homenet-front-end-naming-delegation] requires a complex naming
>    configuration on the CPE.  This configuration MAY not be handled
>    easily by the average end user.  Furthermore, such misconfiguration
>    MAY result in making home network unreachable.
>
>    This document proposes a DHCP options that provide the CPE all
>    necessary parameters to set up the home network naming architecture.
>
>    First, this DHCP options provide automatic configuration and avoid
>    most end users' misconfiguration.  Most average end users may not
>    require specific configuration, and their ISP default configuration
>    MAY fully address their needs.  In that case, the naming homenet
>    architecture configuration will be completely transparent to the end
>    users.  Then, saving naming configuration outside the CPE, makes it
>    resilient to change of CPE or CPE upgrades.  Such configuration may
>    also be configured by the end user, via the customer area of their
>    ISP.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
>  --
> Daniel Migault
> Orange Labs -- Security
> +33 6 70 72 69 58
>
>  _______________________________________________
>
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>


-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

--001a11c3844a80586404e93ef0df
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Bernie, 

<=
div class=3D"gmail_extra">Thanks for your feed back. See my comments in the=
 text.

O=
n Mon, Oct 21, 2013 at 3:09 AM, Bernie Volz (volz) <volz@cisco.com> wrote:










These are comments with WG co-chair hat off.







I don't recall providing input to this document:











11.  Acknowled=
gment





We would like to thank Tomasz Mrugalski and Bernie Volz for th=
eir
   comments on the design of the DHCP Options.







We received comments and recommendations from=
 the previous version on Jul 05 -- Basically splitting the complex option w=
e proposed, and following (and reading) the guide lines. We expected to pre=
sent our new design at IETF87, but ran out schedule. =A0 



=





And at first glance this looks like encapsulation gone crazy!!
=A0
This is also my opinion. My under=
standing of the option guidelines was to use encapsulation of options inste=
ad of specific format. We might have mis-understood something or gone too f=
ar. Either ways I am very glad to have your feed backs. We can easily remov=
e some encapsulations.=A0 









I haven't yet read it carefully enough to determine whether this m=
akes sense to do.



=A0There is no complex or hidd=
en reasons for encapsulation. We might have done it the wrong way. This ver=
sion is expected to be a document for discussion. We hope next versions con=
verge quickly. 

=A0
=A0
<=
div>



I don't like things like requiring a server to return "empty&=
quot; options if it "understands" them but they were not configur=
ed (or "badly" configured). And I can't see any benefit to th=
e client for doing this documented (there's no special action the clien=
t
 is specified to take) -- so why do it?


The only benefit for the client is that i=
t can decide between sending a message with "Options not supported&quo=
t; or "Badly configured Homenet Naming Architectures". We can rem=
ove this requirement.


=A0

- Bernie (from iPad)




On Oct 20, 2013, at 3:52 PM, "Daniel Migault" <mglt.ietf@gmail.com> wrote=
:










Hi,=A0






Please find a description of DHCP options intended to configure the=A0=
"IPv6 Home=
 Network Naming Delegation".=A0[1]



Feel free to make comments!







Best Regards,=A0


Daniel


=A0

URL:=A0http://www.ietf.org=
/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt<=
/a>



Htmlized:=A0http://tools.ietf.org/html/=
draft-mglt-homenet-naming-architecture-dhc-options-00







[1]=A0=A0http://www.ietf.org/int=
ernet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt


















---------- Forwarded message ----------

From: <internet-drafts@ietf.org>

Date: Sun, Oct 20, 2013 at 9:41 PM

Subject: New Version Notification for draft-mglt-homenet-naming-architectur=
e-dhc-options-00.txt

To: Wouter Cloetens <wouter.cloetens@softathome.com>, Chris Griffiths &l=
t;cgriffiths@dyn.co=
m>, Daniel Migault <mglt.ietf@gmail.com>,
 Ralf Weber <ralf.weber@nominum.com>







A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-00=
.txt

has been successfully submitted by Daniel Migault and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-mglt-homenet-naming-architecture-dhc-options=


Revision: =A0 =A0 =A0 =A000

Title: =A0 =A0 =A0 =A0 =A0 DHCP DNS Public Authoritative Server Options

Creation date: =A0 2013-10-20

Group: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 35

URL: =A0 =A0 =A0 =A0 =A0 =A0 
http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-=
dhc-options-00.txt

Status: =A0 =A0 =A0 =A0 =A0http://dat=
atracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options

Htmlized: =A0 =A0 =A0 =A0http://tools.i=
etf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00





Abstract:

=A0 =A0The home network naming architecture as described in [I-D.mglt-

=A0 =A0homenet-front-end-naming-delegation] requires a complex naming

=A0 =A0configuration on the CPE. =A0This configuration MAY not be handled
=A0 =A0easily by the average end user. =A0Furthermore, such misconfiguratio=
n

=A0 =A0MAY result in making home network unreachable.



=A0 =A0This document proposes a DHCP options that provide the CPE all

=A0 =A0necessary parameters to set up the home network naming architecture.=




=A0 =A0First, this DHCP options provide automatic configuration and avoid
=A0 =A0most end users' misconfiguration. =A0Most average end users may =
not

=A0 =A0require specific configuration, and their ISP default configuration<=
br>
=A0 =A0MAY fully address their needs. =A0In that case, the naming homenet
=A0 =A0architecture configuration will be completely transparent to the end=


=A0 =A0users. =A0Then, saving naming configuration outside the CPE, makes i=
t

=A0 =A0resilient to change of CPE or CPE upgrades. =A0Such configuration ma=
y

=A0 =A0also be configured by the end user, via the customer area of their
=A0 =A0ISP.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at 
tools.ietf.org.



The IETF Secretariat














-- 

Daniel Migault

Orange Labs -- Security

+33 6 70 72 69 58











_______________________________________________










-- 
Daniel Migault
Orang=
e Labs -- Security
+33 6 70 72 69 58



--001a11c3844a80586404e93ef0df--

From volz@cisco.com  Mon Oct 21 05:48:14 2013
Return-Path: 
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 1742821F8411 for ; Mon, 21 Oct 2013 05:48:14 -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 SkiTfERzZus7 for ; Mon, 21 Oct 2013 05:48:08 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9F45121F8B4E for ; Mon, 21 Oct 2013 05:48:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8846; q=dns/txt; s=iport; t=1382359682; x=1383569282; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=wn5AITfibAoadarrKp1g4abas/TqItX7jL/QBb1pIgI=; b=f34nQqz0hc0B/L1cFIkGbkrH/bPmtEMVmB0d8qbemaJpelG1zKe34dwu dYb8FEBgcYjf5h0vD8F0W7HTocbCdzML+aWiqd7ej2fHrtdz6Tw8MT4i5 HzDkNnHZYl6hybGIp55pUkT6WGRvsCETOJDWrRMgEmb3RbZM8HzF5VDPj s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8IAHAhZVKtJXG8/2dsb2JhbABZgkNEOLY1iE2BLBZtB4IlAQEBBAEBARoQQRsCAQgRBAEBKAcnCxQJCAEBBBOIBg29XY4jgTUKAYMfgQoDmAmBL5BYgWaBPoFx
X-IronPort-AV: E=Sophos;i="4.93,539,1378857600";  d="scan'208,217";a="274662702"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 21 Oct 2013 12:47:56 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9LCluVP027851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Oct 2013 12:47:56 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 07:47:56 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends November 11, 2013
Thread-Index: Ac7K6RYO6IlqgYnCS8a24Ug8i2UzUgDQipYgAAwguF4=
Date: Mon, 21 Oct 2013 12:47:55 +0000
Message-ID: 
References: <489D13FBFA9B3E41812EA89F188F018E1AD20B47@xmb-rcd-x04.cisco.com>, <8AE0F17B87264D4CAC7DE0AA6C406F453D7CADF7@nkgeml506-mbx.china.huawei.com>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CADF7@nkgeml506-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_EB07F8331CBB46D98F268410DE552438ciscocom_"
MIME-Version: 1.0
Subject: Re: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends November 11, 2013
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 12:48:14 -0000

--_000_EB07F8331CBB46D98F268410DE552438ciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

+1 for adoption (wg co-chair hat off).

- Bernie (from iPad)

On Oct 21, 2013, at 3:01 AM, "Liubing (Leo)" > wrote:

Hi, All

I=92m in favor of adopting it.

B.R.
Bing

From: dhcwg-bounces@ietf.org [mailto:dhcwg-b=
ounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Thursday, October 17, 2013 11:31 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends Nove=
mber 11, 2013


Hi all:



The author has requested a call for adoption by the WG for draft-jiang-dhc-=
sedhcpv6-02. (This document =93replaces=94 http://tools.ietf.org/html/draft=
-ietf-dhc-secure-dhcpv6-07 as that document went to the IESG =96 see https:=
//datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ for more details. =
The new document is very different so please read it.)



This call is being initiated to confirm whether there is WG consensus to ad=
opt this work as DHC WG draft. Please state whether or not you're in favor =
of the adoption by replying to this mail. If you are not in favor, please a=
lso state your objections in your response. This adoption call will complet=
e on November 11, 2013 =96 after the IETF meeting as it will likely be on t=
he DHC WG agenda.



The HTML version of the document can be viewed at http://tools.ietf.org/htm=
l/draft-jiang-dhc-sedhcpv6.



Regards,

Tomek & Bernie

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

--_000_EB07F8331CBB46D98F268410DE552438ciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







+1 for adoption (wg co-chair hat off).



- Bernie (from iPad)




On Oct 21, 2013, at 3:01 AM, "Liubing (Leo)" <leo.liubing@huawei.com> wrote:














Hi, All


 


I=92m in favor of adopting it.


 


B.R.


Bing


 








From:
dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]
On Behalf Of Bernie Volz (volz)

Sent: Thursday, October 17, 2013 11:31 AM

To: dhcwg@ietf.org

Subject: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - En=
ds November 11, 2013






 


Hi all:

 


The author has requested a c=
all for adoption by the WG for draft-jiang-dhc-sedhcpv6-02. (This document =
=93replaces=94
http=
://tools.ietf.org/html/draft-ietf-dhc-secure-dhcpv6-07 as that document=
 went to the IESG =96 see
=
https://datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ for more=
 details. The new document is very different so please read it.)=



 


This call is being initiated=
 to confirm whether there is WG consensus to adopt this work as DHC WG draf=
t. Please state whether or not you're in favor of the adoption by replying =
to this mail. If you are not in favor,
 please also state your objections in your response. This adoption call wil=
l complete on November 11, 2013 =96 after the IETF meeting as it will likel=
y be on the DHC WG agenda.


 


The HTML version of the docu=
ment can be viewed at
http://tool=
s.ietf.org/html/draft-jiang-dhc-sedhcpv6.


 


Regards,

Tomek & Bernie


 












_______________________________________________

dhcwg mailing list

dhcwg@ietf.org

https://www.i=
etf.org/mailman/listinfo/dhcwg








--_000_EB07F8331CBB46D98F268410DE552438ciscocom_--

From stenc@s-carlsen.dk  Mon Oct 21 05:55:15 2013
Return-Path: 
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 40B6811E81B0 for ; Mon, 21 Oct 2013 05:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level: 
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 tzLVriXQctA4 for ; Mon, 21 Oct 2013 05:55:14 -0700 (PDT)
Received: from mail2.s-carlsen.dk (mail2.s-carlsen.dk [IPv6:2001:16d8:dd00:81ac::17]) by ietfa.amsl.com (Postfix) with ESMTP id 0317F11E80E7 for ; Mon, 21 Oct 2013 05:55:12 -0700 (PDT)
Received: from silver3wired.s-carlsen.dk (silver3Wired.s-carlsen.dk [192.168.16.204]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 36B6BDA5B; Mon, 21 Oct 2013 14:55:09 +0200 (CEST)
Message-ID: <5265242D.3070708@s-carlsen.dk>
Date: Mon, 21 Oct 2013 14:55:09 +0200
From: Sten Carlsen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Daniel Migault 
References: <20131020194121.22779.70469.idtracker@ietfa.amsl.com>		<526456F0.6090605@s-carlsen.dk> 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------030701080701070006030903"
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 12:55:15 -0000

This is a multi-part message in MIME format.
--------------030701080701070006030903
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit


On 21/10/13 13.21, Daniel Migault wrote:
>
> Actually that is the reverse. The DHCP options  makes possible for a
> user to define its naming configuration for the homenet and push it to
> any CPE that is plugged. This avoids reconfiguration when changing CPE
> or when the CPE settups are erased.
> Although specific configuration may concern a fraction of end users,
> we believe the large portion of end users, prefers a default naming
> settings that may be proposed by the DHCP.
Good, I did read it and was not sure which way names were pushed - so at
least it was not clear to me.
>  
>
>     The way I see this, is that either I know what I want and make my
>     own DNS-entries or I don't care, in which case there is no meaning
>     in doing naming for people, specially as these namings will likely
>     not be meaningful to people.
>
> Well, most of our end users do not really care about configuring DNS
> architectures for their home network. At most they want it to work on
> a specific domain name "example.com " so they can
> reach there service like "myvideo.example.com
> "  from outside the homenet. This latest
> name is meaningful for them, they are interested in the naming service
> to work properly. However,  they are not interested in deep
> understanding of the naming architecture and most probably not in how
> to perform key roll over. It looks these end users are just in between
> your two alternatives.
I agree very much, this I believe is what most people want. I personally
want to be able to control what can reach into my home and what in the
home can reach outside, so far we are few with that wish.

After some time, privacy concerns may drive people to want more control
over what is accessible on their network from the outside and control of
naming is one step (if it has no name, less chance someone wants to talk
to it). Access control has nothing else to do with DHCP, for that you
must acquire your own firewall.
>
> Note also that you can also just ignore the DHCP Options.
I assume most will do that, unless some setup-wizard will help.
>
>

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


--------------030701080701070006030903
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    
On 21/10/13 13.21, Daniel Migault
      wrote:

    

    

      


        

          

            
Actually that is the reverse. The DHCP options  makes
              possible for a user to define its naming configuration for
              the homenet and push it to any CPE that is plugged. This
              avoids reconfiguration when changing CPE or when the CPE
              settups are erased.

            

            
Although specific configuration may concern a fraction
              of end users, we believe the large portion of end users,
              prefers a default naming settings that may be proposed by
              the DHCP.

            

          

        

      

    

    Good, I did read it and was not sure which way names were pushed -
    so at least it was not clear to me.

    

      

        

          

            
 

            

            

              
 The way I see this,
                is that either I know what I want and make my own
                DNS-entries or I don't care, in which case there is no
                meaning in doing naming for people, specially as these
                namings will likely not be meaningful to people.

                

              

            

            
Well, most of our end users do not really care about
              configuring DNS architectures for their home network. At
              most they want it to work on a specific domain name "example.com"
              so they can reach there service like "myvideo.example.com" 
              from outside the homenet. This latest name is meaningful
              for them, they are interested in the naming service to
              work properly. However,  they are not interested in deep
              understanding of the naming architecture and most probably
              not in how to perform key roll over. It looks these end
              users are just in between your two alternatives.

            

          

        

      

    

    I agree very much, this I believe is what most people want. I
    personally want to be able to control what can reach into my home
    and what in the home can reach outside, so far we are few with that
    wish.

    

    After some time, privacy concerns may drive people to want more
    control over what is accessible on their network from the outside
    and control of naming is one step (if it has no name, less chance
    someone wants to talk to it). Access control has nothing else to do
    with DHCP, for that you must acquire your own firewall.

    

      

        

          

            

              

            

            
Note also that you can also just ignore the DHCP
              Options.

            

          

        

      

    

    I assume most will do that, unless some setup-wizard will help.

    

      

        

          

            


            

            

          

        

      

    

    

    
-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 


  


--------------030701080701070006030903--

From internet-drafts@ietf.org  Mon Oct 21 09:40:34 2013
Return-Path: 
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 47E6E11E85FC; Mon, 21 Oct 2013 09:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 wrvMMuLTssc1; Mon, 21 Oct 2013 09:40:33 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC3D11E8605; Mon, 21 Oct 2013 09:39:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131021163902.32495.37839.idtracker@ietfa.amsl.com>
Date: Mon, 21 Oct 2013 09:39:02 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-08.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 16:40:34 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Dynamic Host Configuration Working Group =
of the IETF.

	Title           : DHCPv4 over IPv6 Transport
	Author(s)       : Yong Cui
                          Peng Wu
                          Jianping Wu
                          Ted Lemon
                          Qi Sun
	Filename        : draft-ietf-dhc-dhcpv4-over-ipv6-08.txt
	Pages           : 14
	Date            : 2013-10-21

Abstract:
   In IPv6 networks, there remains a need to provide IPv4 service for
   some residual devices.  This document describes a mechanism for
   allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6
   transport.  It is done by putting a special relay agent function
   (Client Relay Agent) on the client side, as well as extending the
   behavior of the server; in the case where DHCP server only supports
   IPv4 transport, a relay agent is extended to support IPv6 transport
   (IPv6-Transport Relay Agent) and relay DHCP traffic for the server,
   with a new Relay Agent Information sub-option added to carry the IPv6
   address of the Client Relay Agent.  DHCPv4 over IPv6 has been
   developed in the IETF, and some implementations and deployments have
   been carried out.  But this mechanism is not recommended for future
   implementation or deployment.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-ipv6

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv4-over-ipv6-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From alexandru.petrescu@gmail.com  Mon Oct 21 10:14:35 2013
Return-Path: 
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 2659F11E864C for ; Mon, 21 Oct 2013 10:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.196
X-Spam-Level: 
X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 nPBrnh2k5dTN for ; Mon, 21 Oct 2013 10:14:30 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 676FA11E8527 for ; Mon, 21 Oct 2013 10:14:26 -0700 (PDT)
Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r9LHEOOX024032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Oct 2013 19:14:25 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r9LHEO29031569 for ; Mon, 21 Oct 2013 19:14:24 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r9LHEBT6004043 for ; Mon, 21 Oct 2013 19:14:24 +0200
Message-ID: <526560E3.3030908@gmail.com>
Date: Mon, 21 Oct 2013 19:14:11 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "" 
References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Announcing draft-petrescu-relay-route-pd-problem-00 about route problem at Relay during Prefix Delegation operation
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 17:14:35 -0000

Hello participants to DHC WG,

We have just submitted a drat about the routing problem at Relay during
the Prefix Delegation operation o DHCPv6.

draft-petrescu-relay-route-pd-problem-00

"Route Problem at Relay during DHCPv6 Prefix Delegation"
Mohamed Boucadair 
Leaf Y. Yeh 
Alexandru Petrescu 

http://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00

Please have a look at the draft and comment.

Thank you in advance,

Alex, with co-authors.


From volz@cisco.com  Mon Oct 21 11:26:50 2013
Return-Path: 
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 BF76211E839E for ; Mon, 21 Oct 2013 11:26:49 -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=[AWL=-0.000, 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 2zquWwPUEnjI for ; Mon, 21 Oct 2013 11:26:44 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6F09011E8220 for ; Mon, 21 Oct 2013 11:26:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17689; q=dns/txt; s=iport; t=1382380004; x=1383589604; h=from:to:subject:date:message-id:mime-version; bh=ez2EaKJEtJmUeB4WKJn2rUZvPt6Wpqg0TrXgzkCJOsU=; b=CrtTTCMPxQ66u8ynXDdGFvPK8XEDagH9nWzl9+2HZqNkgi7DsFPduILQ 6em0lJM8DS3OnqtUSwpOE3eRMxzDQXPDule0E2kcTp6PkK12fgP/lkkzd rdfwuKYzcoOSlfDbZ8+5vke5P9Cy5MvPRV4+m+RsJpzpcgUJsCvWfa8Qi A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArEHAHNwZVKtJV2b/2dsb2JhbABZgkNEOFS1Y4hFgS4WbQeCJwEELV4BGhBWFw8BBBsBh30NmFmhTI8qg1eBCgOZOJBYgySCKg
X-IronPort-AV: E=Sophos;i="4.93,541,1378857600";  d="scan'208,217";a="274766354"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 21 Oct 2013 18:26:43 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9LIQhkK009648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Oct 2013 18:26:43 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 13:26:43 -0500
From: "Bernie Volz (volz)" 
To: "dhcwg@ietf.org" 
Thread-Topic: IETF-88 (Vancouver) Meeting Agenda
Thread-Index: Ac7OibAnpC6uRqEXSAeprkgIvOoEnA==
Date: Mon, 21 Oct 2013 18:26:42 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD2E06B@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.212.218]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AD2E06Bxmbrcdx04ciscoc_"
MIME-Version: 1.0
Subject: [dhcwg] IETF-88 (Vancouver) Meeting Agenda
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 18:26:50 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E1AD2E06Bxmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi:

I have posted the DHC WG agenda. It is as follows, as I'm not sure when it =
will be available at http://tools.ietf.org/wg/dhc/agenda?item=3Dagenda-88-d=
hc.html. We have accommodated all of the requests, although we suspect that=
 some of the discussions will run over the requested times and we will not =
get to all presentations. The agenda is still submit to change.

Please be sure to submit your slides! We would like all of these in by Frid=
ay, November 1st.

The agenda is available at http://www.ietf.org/proceedings/88/agenda/agenda=
-88-dhc:

DHC WG Agenda for IETF-88 (Vancouver)

Tuesday, November 5, 0900-1130 PST
Chairs: Tomek Mrugalski & Bernie Volz
Presentations materials: https://datatracker.ietf.org/meeting/88/materials.=
html#wg-dhc

1.  Co-Chairs - Administrivia (WG Status & Agenda Bashing) - 10 minutes
2.  Tomek Mrugalski - RFC-3315bis Design Team Formation - 20 minutes
3.  Qi Sun - DHCPv4 over DHCPv6 Transport - 10 minutes
    draft-ietf-dhc-dhcpv4-over-dhcpv6
4.  Ian Farrer - v4configuration - 15 minutes
    draft-ietf-dhc-v4configuration
5.  Shwetha Bhandari - DHCP access network identifier - 10 minutes
    draft-ietf-dhc-access-network-identifier
6.  Sheng Jiang - Secure DHCPv6 - 10 minutes
    draft-jiang-dhc-sedhcpv6
7.  Qi Sun - Handling Unknown DHCPv6 Messages - 5 minutes
    draft-ietf-dhc-dhcpv6-unknown-msg
8.  Suresh Krishnan - Address Registration - 10 minutes
    draft-ietf-dhc-addr-registration
9.  Sheng Jiang - Stateless Reconfiguration - 15 minutes
    draft-jiang-dhc-stateless-reconfiguration
10. Kim Kinnear or Bernie Volz - DHCPv6 Active Leasequery - 10 minutes*
    draft-raghuvanshi-dhc-dhcpv6-active-leasequery
11. Shwetha Bhandari - DNS Reconfigure - 10 minutes*
    draft-wing-dhc-dns-reconfigure
12. Route Problem at Relay during DHCPv6 Prefix Delegation - 10 minutes*
13. homenet Naming Architecture Options - 5 minutes*
    draft-mglt-homenet-naming-architecture-dhc-options

* There may be insufficient time for these presentations.


-          Tomek & Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E1AD2E06Bxmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi:


 


I have posted the DHC WG agenda. It is as follows, a=
s I’m not sure when it will be available at
h=
ttp://tools.ietf.org/wg/dhc/agenda?item=3Dagenda-88-dhc.html. We have a=
ccommodated all of the requests, although we suspect that some of the discu=
ssions will run over the requested times
 and we will not get to all presentations. The agenda is still submit to ch=
ange.


 


Please be sure to submit your slides! We would li=
ke all of these in by Friday, November 1st.


 


The agenda is available at 
http://www.ietf.org/proceedings/88/agenda/agenda-88-dhc:


 





DHC WG Agenda for IETF-88 (Vancouver)=




 



Tuesday, November 5, 0900-1130 PST



Chairs: Tomek Mrugalski & Bernie Volz<=
o:p>



Presentations materials: https://datatrack=
er.ietf.org/meeting/88/materials.html#wg-dhc



 



1.  Co-Chairs - Administrivia (WG Sta=
tus & Agenda Bashing) - 10 minutes



2.  Tomek Mrugalski - RFC-3315bis Des=
ign Team Formation - 20 minutes



3.  Qi Sun - DHCPv4 over DHCPv6 Trans=
port - 10 minutes



    draft-ietf-dhc-dhcpv4-o=
ver-dhcpv6



4.  Ian Farrer - v4configuration - 15=
 minutes



    draft-ietf-dhc-v4config=
uration



5.  Shwetha Bhandari - DHCP access ne=
twork identifier - 10 minutes



    draft-ietf-dhc-access-n=
etwork-identifier



6.  Sheng Jiang - Secure DHCPv6 - 10 =
minutes



    draft-jiang-dhc-sedhcpv=
6



7.  Qi Sun - Handling Unknown DHCPv6 =
Messages - 5 minutes



    draft-ietf-dhc-dhcpv6-u=
nknown-msg



8.  Suresh Krishnan - Address Registr=
ation - 10 minutes



    draft-ietf-dhc-addr-reg=
istration



9.  Sheng Jiang - Stateless Reconfigu=
ration - 15 minutes



    draft-jiang-dhc-statele=
ss-reconfiguration



10. Kim Kinnear or Bernie Volz - DHCPv6 Ac=
tive Leasequery - 10 minutes*



    draft-raghuvanshi-dhc-d=
hcpv6-active-leasequery



11. Shwetha Bhandari - DNS Reconfigure - 1=
0 minutes*



    draft-wing-dhc-dns-reco=
nfigure



12. Route Problem at Relay during DHCPv6 P=
refix Delegation - 10 minutes*



13. homenet Naming Architecture Options - =
5 minutes*



    draft-mglt-homenet-nami=
ng-architecture-dhc-options



 



* There may be insufficient time for these=
 presentations.




 


-     &=
nbsp;   
Tomek & Bernie






--_000_489D13FBFA9B3E41812EA89F188F018E1AD2E06Bxmbrcdx04ciscoc_--

From internet-drafts@ietf.org  Mon Oct 21 12:51:17 2013
Return-Path: 
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 8985611E870E; Mon, 21 Oct 2013 12:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.574
X-Spam-Level: 
X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 Kg1DJ7hUEmfv; Mon, 21 Oct 2013 12:50:35 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A58AA11E86DF; Mon, 21 Oct 2013 12:46:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131021194625.32574.47205.idtracker@ietfa.amsl.com>
Date: Mon, 21 Oct 2013 12:46:25 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dns-pd-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 19:51:17 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Dynamic Host Configuration Working Group =
of the IETF.

	Title           : Populating the DNS Reverse Tree for DHCP Delegated Prefi=
xes
	Author(s)       : Ted Lemon
	Filename        : draft-ietf-dhc-dns-pd-01.txt
	Pages           : 13
	Date            : 2013-10-21

Abstract:
   This document describes three alternatives for populating the DNS
   reverse tree for prefixes delegated using DHCP, and provides
   mechanisms for implementing each alternative.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dns-pd

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dns-pd-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dns-pd-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From Ted.Lemon@nominum.com  Mon Oct 21 12:51:40 2013
Return-Path: 
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 E702B11E86EB for ; Mon, 21 Oct 2013 12:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.593
X-Spam-Level: 
X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 m6oAx0uNyLeV for ; Mon, 21 Oct 2013 12:51:34 -0700 (PDT)
Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 3771D11E8273 for ; Mon, 21 Oct 2013 12:48:05 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUmWE6bVtCsGma3OtcE4VzEfi1TDzhrwy@postini.com; Mon, 21 Oct 2013 12:48:05 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5B5FC1B82DF for ; Mon, 21 Oct 2013 12:47:52 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3CCAA190052 for ; Mon, 21 Oct 2013 12:47:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Mon, 21 Oct 2013 12:47:52 -0700
From: Ted Lemon 
To: dhcwg WG 
Thread-Topic: draft-ietf-dhc-dns-pd-01 submitted
Thread-Index: AQHOzpZt2jD+5YT9DUmuliKLrPCLmw==
Date: Mon, 21 Oct 2013 19:47:51 +0000
Message-ID: <2D09BB4C-EA96-4D87-AB87-9E90AE40F9B7@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <65A91F5059B0A0439FD69DCA6D50C0FC@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [dhcwg] draft-ietf-dhc-dns-pd-01 submitted
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 19:51:41 -0000

Before this goes any further, I think it needs to be presented in homenet a=
nd dnsop.   However, I can't present it in dnsop.   And I need a co-author =
anyway.   Anybody want to volunteer?


From volz@cisco.com  Mon Oct 21 12:59:42 2013
Return-Path: 
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 395D311E874A for ; Mon, 21 Oct 2013 12:59:42 -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 uZa2AfzQ75UI for ; Mon, 21 Oct 2013 12:59:36 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 08DB211E8282 for ; Mon, 21 Oct 2013 12:57:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24052; q=dns/txt; s=iport; t=1382385455; x=1383595055; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yalLB+L/COh/3lH2Mv8aeJ+soAPzxf7mzEkMsXpY23U=; b=IZPnV7y15WpSMPeryTpxKsZx5AdEv1pDRMNIgFbbFA0YfRMPOpPG5z+z dgt/TzrXvIREgR1lvOu2vdwlYOGyYWxcvSnjVOq3Pv/+7j/tDlc9zMHNh g6WeGsL+8iqMM3G0mtQxEfmUhqWrvX47ZXkMm3zOVPLva9zB8bCCEk1gM Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAG6GZVKtJV2c/2dsb2JhbABZgkNEOFS+K4EvFnSCJQEBAQQtTBACAQgOAwQBAQsWBwcyFAkIAgQBDQUIEQWHaLo4jyoxBgEGgxmBCgOqEIMkgio
X-IronPort-AV: E=Sophos;i="4.93,541,1378857600";  d="scan'208,217";a="274873207"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 21 Oct 2013 19:57:33 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9LJvXgs031849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 19:57:33 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 14:57:32 -0500
From: "Bernie Volz (volz)" 
To: Marcin Siodelski , "ian.farrer@telekom.de" 
Thread-Topic: [dhcwg] A few comments about draft-farrer-dhc-shared-address-lease-00
Thread-Index: AQHOzlBSY5ti80m97UaYOpen2QCa7pn/j/MQ
Date: Mon, 21 Oct 2013 19:57:32 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD2E48F@xmb-rcd-x04.cisco.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.212.218]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AD2E48Fxmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: "" 
Subject: Re: [dhcwg] A few comments about	draft-farrer-dhc-shared-address-lease-00
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Oct 2013 19:59:42 -0000

--_000_489D13FBFA9B3E41812EA89F188F018E1AD2E48Fxmbrcdx04ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Marcin:

"Since, the draft is intended to update RFC2131, it should be mentioned wha=
t the server which doesn't support the Dynamic Shared addresses should do w=
hen it receives a message with the OPTION_PORTPARAMSV4."

These servers would ignore the option as they don't support it. We can't ma=
ke them do anything else as they already exist.

Also, I think it is WRONG for this draft to update 2131. This isn't a chang=
e to all DHCPv4 clients, relays, and servers, so I think we need to be care=
ful here. This extends 2131 with changes into a new space, but that is far =
different than "updating" 2131. We might need to discuss this some dependin=
g on where this work goes - if the intent really is to uplift all clients (=
and servers) to support this, then perhaps the updates is more appropriate =
- but I think this is intended to be used only when it is detected that iet=
f-dhc-dhcpv4-over-dhcpv6 applies?

"Although, I support the idea to refer to the draft being updated rather th=
an rewriting whole sections, but in this case it may be unavoidable."

I don't look forward to a new RFC 2131! Be nice if the differences could be=
 clearly enumerated. I think this would be a win anyway because most likely=
 someone implementing this draft would want to know what to change in an ex=
isting client implementation rather than implementing a new one from scratc=
h? Also, we'd have to be careful that people don't mistake the a new 2131 l=
ike document for a 2131bis.


-          Bernie

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of M=
arcin Siodelski
Sent: Monday, October 21, 2013 7:25 AM
To: ian.farrer@telekom.de
Cc: 
Subject: [dhcwg] A few comments about draft-farrer-dhc-shared-address-lease=
-00

Ian,

I apologize for doing a review so late before IETF. I should have done that=
 a few weeks ago. A few (hopefully useful) comments...

Abstract

With respect to this:
"This memo describes an update to [RFC2131], which enables the dynamic leas=
ing of shared IPv4 address and layer 4 source ports to DHCPv4 over DHCPv6 c=
lients [I-D. etf-dhc-dhcpv4-over-dhcpv6]."

Is it intended to restrict shared addresses functionality to DHCPv4-over-DH=
CPv6 clients? It is ok that the draft addresses a specific, real life use c=
ases, but if it is possible to implement it as a more generic approach, the=
 document should strive to make it sound generic.

It may be useful to provide a definition of DHCPv4-over-DHCPv6 client (whic=
h is a term used multiple times throughout the document). Although, there i=
s a reference to the DHCPv4-over-DHCPv6 draft, this draft doesn't provide a=
 definition for it. Some form of the glossary may be useful.

Introduction:
"[I-D.ietf-dhcp-dhcpv4-over-dhcpv6] introduces a Unified Server..."

After one of the reviews we have changed the terminology in the DHCPv4 over=
 DHCPv6 draft and we refer to the server processing DHCPv4 requests over DH=
CPv6 protocol as "4o6 Server".

3.1 Allocation a Shared, Dynamic IPv4 Address
"The process described below detail...". Should it be "The process describe=
d below details...." ?

Since, the draft is intended to update RFC2131, it should be mentioned what=
 the server which doesn't support the Dynamic Shared addresses should do wh=
en it receives a message with the OPTION_PORTPARAMSV4. Should it ignore the=
 message? What should do the server which supports this extension (and is c=
onfigured to use it) but haven't received the OPTION_PORTPARAMSV4 option fr=
om the client.

3.1.2.
"... within the BOOTPRELAYV6 message  may respond with a DHCPOFFER ...".

Suggest to use MAY instead of "may".

3.1.3. It may be implicitly assumed, because RFC2131 describes the message =
exchange process in detail, but IMHO it should be mentioned that client MUS=
T include yiaddr in DHCPREQUEST to indicate the desired configuration (besi=
des PSID). Also, the DHCPREQUEST message MUST contain the Client Identifier=
 (the same that was used to create DHCPDISCOVER).

3.1.5.
In the RFC2131 sections: 2.2 and 3.1 it is said that server SHOULD or MAY p=
robe that the address being assigned is already in use. The draft is intend=
ed to update RFC2131 so it should be mentioned that server MUST NOT probe t=
hat the address being assigned is in use using ICMP Echo. The text about cl=
ient not performing final check is fine obviously.

3.2. Reusing a Previously Allocated Shared, Dynamic IPv4 address

"OPTION_PORTPARAMSV4 MUST be included in the message flow, with the client'=
s requested port set being included in the DHCPDISCOVER message".

Note that section 3.2 of RFC2131 doesn't mention DISCOVER. The whole commun=
ication is based on 2-way exchange DHCPREQUEST/DHCPACK. Did you mean DHCPRE=
QUEST?

Although, I support the idea to refer to the draft being updated rather tha=
n rewriting whole sections, but in this case it may be unavoidable. For exa=
mple:
- With the standard DHCP, the client will broadcast REQUEST which is not th=
e case for the Shared Dynamic allocation.
- normally server would broadcast the DHCPNAK if requested binding is inval=
id (expired or whatever), it is not the case here.
- Client MUST not perform final check on the assigned address when Shared D=
ynamic allocation is used (RFC2131 section 3.2. says it does).

What I mean here is that there are two many disparities between the bare DH=
CP protocol described in the RFC2131 and extension described in your draft =
to be just able to say: "The RFC2131 is followed with the exception that OP=
TION_PORTPARAMSV4 must be included everywhere."

5. Additional Changes to RFC2131 Behvaiour
Neither should server probe IPv4 addresses assigned.

6. Typo: MUST use apply. Should be MUST apply.

7. Specific Behaviour for Softwire Clients
I would rather see this section in the different draft and leave this one a=
 more generic extension to DHCPv4 to simply allocate IPv4 address + PSID.

8. DHCPv4 over DHCPv6 Source Address Option
The format of the option is wrong. The fields holding lengths of the variab=
le length fields should be laid before the variable length fields as typica=
lly the server would parse the option from the beginning to the end.

cipv6-prefix-hint is not described

What are the minimal lengths of the prefixes (and minimal length of the opt=
ion)? Blank prefix means length=3D0?

Marcin

--_000_489D13FBFA9B3E41812EA89F188F018E1AD2E48Fxmbrcdx04ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Marcin:=



 <=
/p>

“Since, the draft is intended to update RFC213=
1, it should be mentioned what the server which doesn't support the Dynamic=
 Shared addresses should do when it receives a message with the OPTION_PORT=
PARAMSV4.”


 <=
/p>

These servers would ignor=
e the option as they don’t support it. We can’t make them do an=
ything else as they already exist.


 <=
/p>

Also, I think it is WRONG=
 for this draft to update 2131. This isn’t a change to all DHCPv4 cli=
ents, relays, and servers, so I think we need to be careful here.
 This extends 2131 with changes into a new space, but that is far different=
 than “updating” 2131. We might need to discuss this some depen=
ding on where this work goes – if the intent really is to uplift all =
clients (and servers) to support this, then perhaps
 the updates is more appropriate – but I think this is intended to be=
 used only when it is detected that ietf-dhc-dhcpv4-over-dhcpv6 applies?


 <=
/p>

“Although, I support the idea to refer to the =
draft being updated rather than rewriting whole sections, but in this case =
it may be unavoidable.”<=
/p>

 <=
/p>

I don’t look forwar=
d to a new RFC 2131! Be nice if the differences could be clearly enumerated=
. I think this would be a win anyway because most likely someone
 implementing this draft would want to know what to change in an existing c=
lient implementation rather than implementing a new one from scratch? Also,=
 we’d have to be careful that people don’t mistake the a new 21=
31 like document for a 2131bis.


 <=
/p>

- =
        
Bernie=



 <=
/p>

From: dhcwg-bo=
unces@ietf.org [mailto:dhcwg-bounces@ietf.org]
On Behalf Of Marcin Siodelski

Sent: Monday, October 21, 2013 7:25 AM

To: ian.farrer@telekom.de

Cc: <dhcwg@ietf.org>

Subject: [dhcwg] A few comments about draft-farrer-dhc-shared-addres=
s-lease-00


 






Ian,






 






I apologize for doing a review so late before IETF. =
I should have done that a few weeks ago. A few (hopefully useful) comments.=
.. 






 




Abstract




 






With respect to this:






"This memo describes an update to [RFC2131], wh=
ich enables the dynamic leasing of shared IPv4 address and layer 4 source p=
orts to DHCPv4 over DHCPv6 clients [I-D. etf-dhc-dhcpv4-over-dhcpv6]."=







 






Is it intended to restrict shared addresses function=
ality to DHCPv4-over-DHCPv6 clients? It is ok that the draft addresses a sp=
ecific, real life use cases, but if it is possible to implement it as a mor=
e generic approach, the document should
 strive to make it sound generic.






 






It may be useful to provide a definition of DHCPv4-o=
ver-DHCPv6 client (which is a term used multiple times throughout the docum=
ent). Although, there is a reference to the DHCPv4-over-DHCPv6 draft, this =
draft doesn't provide a definition
 for it. Some form of the glossary may be useful.






 






Introduction:






"[I-D.ietf-dhcp-dhcpv4-over-dhcpv6] introduces =
a Unified Server..."






 






After one of the reviews we have changed the termino=
logy in the DHCPv4 over DHCPv6 draft and we refer to the server processing =
DHCPv4 requests over DHCPv6 protocol as "4o6 Server". <=
/o:p>






 






3.1 Allocation a Shared, Dynamic IPv4 Address






"The process described below detail...". S=
hould it be "The process described below details...." ?






 






Since, the draft is intended to update RFC2131, it s=
hould be mentioned what the server which doesn't support the Dynamic Shared=
 addresses should do when it receives a message with the OPTION_PORTPARAMSV=
4. Should it ignore the message? What
 should do the server which supports this extension (and is configured to u=
se it) but haven't received the OPTION_PORTPARAMSV4 option from the client.=







 






3.1.2. 






"... within the BOOTPRELAYV6 message  may =
respond with a DHCPOFFER ...".






 






Suggest to use MAY instead of "may".<=
/o:p>






 






3.1.3. It may be implicitly assumed, because RFC2131=
 describes the message exchange process in detail, but IMHO it should be me=
ntioned that client MUST include yiaddr in DHCPREQUEST to indicate the desi=
red configuration (besides PSID).
 Also, the DHCPREQUEST message MUST contain the Client Identifier (the same=
 that was used to create DHCPDISCOVER). 






 






3.1.5. 






In the RFC2131 sections: 2.2 and 3.1 it is said that=
 server SHOULD or MAY probe that the address being assigned is already in u=
se. The draft is intended to update RFC2131 so it should be mentioned that =
server MUST NOT probe that the address
 being assigned is in use using ICMP Echo. The text about client not perfor=
ming final check is fine obviously.






 






3.2. Reusing a Previously Allocated Shared, Dynamic =
IPv4 address






 






"OPTION_PORTPARAMSV4 MUST be included in the me=
ssage flow, with the client's requested port set being included in the DHCP=
DISCOVER message".






 






Note that section 3.2 of RFC2131 doesn't mention DIS=
COVER. The whole communication is based on 2-way exchange DHCPREQUEST/DHCPA=
CK. Did you mean DHCPREQUEST?






 






Although, I support the idea to refer to the draft b=
eing updated rather than rewriting whole sections, but in this case it may =
be unavoidable. For example: 






- With the standard DHCP, the client will broadcast =
REQUEST which is not the case for the Shared Dynamic allocation.=







- normally server would broadcast the DHCPNAK if req=
uested binding is invalid (expired or whatever), it is not the case here.






- Client MUST not perform final check on the assigne=
d address when Shared Dynamic allocation is used (RFC2131 section 3.2. says=
 it does).






 






What I mean here is that there are two many disparit=
ies between the bare DHCP protocol described in the RFC2131 and extension d=
escribed in your draft to be just able to say: "The RFC2131 is followe=
d with the exception that OPTION_PORTPARAMSV4
 must be included everywhere."






 






5. Additional Changes to RFC2131 Behvaiour






Neither should server probe IPv4 addresses assigned.=







 






6. Typo: MUST use apply. Should be MUST apply.<=
/o:p>






 






7. Specific Behaviour for Softwire Clients






I would rather see this section in the different dra=
ft and leave this one a more generic extension to DHCPv4 to simply allocate=
 IPv4 address + PSID.






 






8. DHCPv4 over DHCPv6 Source Address Option






The format of the option is wrong. The fields holdin=
g lengths of the variable length fields should be laid before the variable =
length fields as typically the server would parse the option from the begin=
ning to the end.






 






cipv6-prefix-hint is not described






 






What are the minimal lengths of the prefixes (and mi=
nimal length of the option)? Blank prefix means length=3D0?






 






Marcin










--_000_489D13FBFA9B3E41812EA89F188F018E1AD2E48Fxmbrcdx04ciscoc_--

From nkong@cnnic.cn  Mon Oct 21 17:48:49 2013
Return-Path: 
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 0C4AC11E8214 for ; Mon, 21 Oct 2013 17:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 GV1T3xmEJiQW for ; Mon, 21 Oct 2013 17:48:44 -0700 (PDT)
Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 68FB511E82C6 for ; Mon, 21 Oct 2013 17:48:12 -0700 (PDT)
Received: from unknown127.0.0.1 (HELO [218.241.103.200]) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 22 Oct 2013 08:48:02 +0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_14FC453F-1399-4437-B47F-4D15D1CD5AE3"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Ning Kong 
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CADF7@nkgeml506-mbx.china.huawei.com>
Date: Tue, 22 Oct 2013 08:48:04 +0800
Message-Id: 
References: <489D13FBFA9B3E41812EA89F188F018E1AD20B47@xmb-rcd-x04.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CADF7@nkgeml506-mbx.china.huawei.com>
To: Liubing (Leo) 
X-Mailer: Apple Mail (2.1510)
Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" 
Subject: Re: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends November 11, 2013
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 00:48:49 -0000

--Apple-Mail=_14FC453F-1399-4437-B47F-4D15D1CD5AE3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


+1

> Hi, All
> =20
> I=E2=80=99m in favor of adopting it.
> =20
> B.R.
> Bing
> =20
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf =
Of Bernie Volz (volz)
> Sent: Thursday, October 17, 2013 11:31 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends =
November 11, 2013
> =20
> Hi all:
> =20
> The author has requested a call for adoption by the WG for =
draft-jiang-dhc-sedhcpv6-02. (This document =E2=80=9Creplaces=E2=80=9D =
http://tools.ietf.org/html/draft-ietf-dhc-secure-dhcpv6-07 as that =
document went to the IESG =E2=80=93 =
seehttps://datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ for =
more details. The new document is very different so please read it.)
> =20
> This call is being initiated to confirm whether there is WG consensus =
to adopt this work as DHC WG draft. Please state whether or not you're =
in favor of the adoption by replying to this mail. If you are not in =
favor, please also state your objections in your response. This adoption =
call will complete on November 11, 2013 =E2=80=93 after the IETF meeting =
as it will likely be on the DHC WG agenda.
> =20
> The HTML version of the document can be viewed at =
http://tools.ietf.org/html/draft-jiang-dhc-sedhcpv6.
> =20
> Regards,
> Tomek & Bernie
> =20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

--Apple-Mail=_14FC453F-1399-4437-B47F-4D15D1CD5AE3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


+1

Hi, All
 
 
 dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz =
(volz)
Sent: Thursday, October 17, 2013 =
11:31 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Adoption Call - =
draft-jiang-dhc-sedhcpv6-02 - Ends November 11, =
2013
 
Hi all:
 
The author has requested a call for adoption by the WG =
for draft-jiang-dhc-sedhcpv6-02. (This document =E2=80=9Creplaces=E2=80=9D=
  as that document went to =
the IESG =E2=80=93 see for more details. The new =
document is very different so please read =
it.)
____________________________=
___________________
dhcwg mailing list
dhcwg@ietf.org

Date: Mon, 21 Oct 2013 20:57:44 -0700
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 03:57:49 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Dynamic Host Configuration Working Group =
of the IETF.

	Title           : Customizing DHCP Configuration on the Basis of Network T=
opology
	Author(s)       : Ted Lemon
                          Tomek Mrugalski
	Filename        : draft-ietf-dhc-topo-conf-00.txt
	Pages           : 10
	Date            : 2013-10-21

Abstract:
   DHCP servers have evolved over the years to provide significant
   functionality beyond that which is described in the DHCP base
   specifications.  One aspect of this functionality is support for
   context-specific configuration information.  This memo describes some
   such features and makes recommendations as to how they can be used.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-topo-conf

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From repenno@cisco.com  Tue Oct 22 03:56:52 2013
Return-Path: 
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 C322D21F9E9D for ; Tue, 22 Oct 2013 03:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 Vz-1vcT3a4rI for ; Tue, 22 Oct 2013 03:56:47 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4923321F9F4F for ; Tue, 22 Oct 2013 03:56:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2464; q=dns/txt; s=iport; t=1382439398; x=1383648998; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=j5bnWlaR3V1D8b1R14PdJTKKXRpD4Y026qi2lWDbg9Y=; b=REUL95qbfRlI6BXLGY0xRzOdNmtglrjIEJArvmlP7dEnpAcX2JhW9LOX BdwICu0+RJs5dTdHSFLSHcxlWjVg2/urGKR2DtmWEt6vXmRdFezwXsKW+ 0gWJF7iZI5nrPqfkYPQ4g7cwd6baWOdqj+ttmnammYJVUZXVRN7I2MEXD g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au8FAOFYZlKtJV2a/2dsb2JhbABZgwc4VL5IgSYWbQeCJwEEAQEBNzQdAQgiFDcLJQIEEwiHfg2ZEqFajxU4gx+BCgOZOJBYgySCKg
X-IronPort-AV: E=Sophos;i="4.93,547,1378857600"; d="scan'208";a="272033632"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 22 Oct 2013 10:56:37 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9MAuaiS026534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Oct 2013 10:56:36 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 05:56:36 -0500
From: "Reinaldo Penno (repenno)" 
To: "dhcwg@ietf.org" 
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
Thread-Index: AQHOztr9CyHJhGQ69kaVnq/uHEmJSpoAa4KA
Date: Tue, 22 Oct 2013 10:56:36 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B73AEFA@xmb-rcd-x04.cisco.com>
In-Reply-To: <20131022035744.9824.93057.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.101.23]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6FF342B06BCECC4CB7E96ED7D87BAC58@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 10:56:52 -0000

Ted/Tomek,

Thanks for this draft. It is very informative. One concern that I have is
that the approach described in figure 3 makes it harder to handle failures.

Another approach is to have the DHCP Server return the same FQDN returned
to all clients. Each client sends a DNS request and gets a DNS reply based
on the source IP of the request. This is the de-facto geo load balancing
which not only allows for locality but also failure. For example, let's
suppose DHCP Server resolves sip.omashu.example.org to 2001:DB8:0:0::2 and
give that IP to the client. Later this SIP Server fails, now what should
the client do? If the client possesses the domain name, it just resolves
it again, gets a different IP address (for a different SIP server) and it
is good to go. If the client only possesses the IP address of the SIP
server, it is stuck until that specific SIP server is online again.

Thanks,

Reinaldo



On 10/21/13 8:57 PM, "internet-drafts@ietf.org" 
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Dynamic Host Configuration Working
>Group of the IETF.
>
>	Title           : Customizing DHCP Configuration on the Basis of Network
>Topology
>	Author(s)       : Ted Lemon
>                          Tomek Mrugalski
>	Filename        : draft-ietf-dhc-topo-conf-00.txt
>	Pages           : 10
>	Date            : 2013-10-21
>
>Abstract:
>   DHCP servers have evolved over the years to provide significant
>   functionality beyond that which is described in the DHCP base
>   specifications.  One aspect of this functionality is support for
>   context-specific configuration information.  This memo describes some
>   such features and makes recommendations as to how they can be used.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-dhc-topo-conf
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-00
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www.ietf.org/mailman/listinfo/dhcwg


From Ted.Lemon@nominum.com  Tue Oct 22 07:19:39 2013
Return-Path: 
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 3842E21E809B for ; Tue, 22 Oct 2013 07:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ddHtiNr5JBhm for ; Tue, 22 Oct 2013 07:19:32 -0700 (PDT)
Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8296F11E83E5 for ; Tue, 22 Oct 2013 07:19:13 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUmaJYWefN4Dbaf3WqaCNHwicBlCmsDyP@postini.com; Tue, 22 Oct 2013 07:19:13 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2B4641B82E0 for ; Tue, 22 Oct 2013 07:19:13 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 242F9190052; Tue, 22 Oct 2013 07:19:13 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Tue, 22 Oct 2013 07:19:07 -0700
From: Ted Lemon 
To: "Reinaldo Penno (repenno)" 
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
Thread-Index: AQHOztr+qeyvH50ZYkS21xtwsh9mdZoBAmMAgAA4lAA=
Date: Tue, 22 Oct 2013 14:19:07 +0000
Message-ID: <5B14C587-4223-4157-AF2B-C9F26C499504@nominum.com>
References: <45A697A8FFD7CF48BCF2BE7E106F06040B73AEFA@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B73AEFA@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1DC076D98862C544A14AF0E4C6EF8019@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 14:19:39 -0000

On Oct 22, 2013, at 6:56 AM, Reinaldo Penno (repenno)  w=
rote:
> For example, let's
> suppose DHCP Server resolves sip.omashu.example.org to 2001:DB8:0:0::2 an=
d
> give that IP to the client. Later this SIP Server fails, now what should
> the client do? If the client possesses the domain name, it just resolves
> it again, gets a different IP address (for a different SIP server) and it
> is good to go. If the client only possesses the IP address of the SIP
> server, it is stuck until that specific SIP server is online again.

It would be helpful if you were to review the discussion that happened on t=
his very mailing list about a week ago about the topic of whether it makes =
sense to configure applications using DHCP.   If you do so, and feel that t=
he question you ask above was not adequately addressed during that discussi=
on, please add to the discussion.

The short answer, though, is that SIP is probably an example of an applicat=
ion that (a) should not be configured by DHCP and (b) if it is configured b=
y DHCP anyway, should probably be configured using an FQDN.


From otroan@employees.org  Tue Oct 22 09:08:05 2013
Return-Path: 
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 8DB2511E81C4 for ; Tue, 22 Oct 2013 09:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level: 
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 kIE6XSqHl9lF for ; Tue, 22 Oct 2013 09:07:59 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id C1C5A11E81D7 for ; Tue, 22 Oct 2013 09:07:58 -0700 (PDT)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AikFAOKhZlKQ/khR/2dsb2JhbABZgwe/VIElFnSCJQEBBAF5BQsLEjRJDgYuh2UGulWPTgeDH4EKA5Atg32VZoMmOg
X-IronPort-AV: E=Sophos;i="4.93,549,1378857600";  d="asc'?scan'208";a="18455457"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 22 Oct 2013 16:07:51 +0000
Received: from dhcp-10-61-107-167.cisco.com (dhcp-10-61-107-167.cisco.com [10.61.107.167]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MG7mFA022398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Oct 2013 16:07:49 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_41D4D93D-D59B-4C0B-A2B8-023C048FF46F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Ole Troan 
In-Reply-To: <3A7ED0DA-EE87-496C-AC7D-C4D3D937FB84@gmx.com>
Date: Tue, 22 Oct 2013 18:07:48 +0200
Message-Id: <73774E7F-38E3-4F41-822C-093444CA99B1@employees.org>
References: <20130930140054.31558.95411.idtracker@ietfa.amsl.com> <6A05E003-42A2-4659-9F23-6F5DFC6A88EF@gmx.com> <2C4C5302-C2CA-4F85-B053-78D317FD7964@employees.org> <3A7ED0DA-EE87-496C-AC7D-C4D3D937FB84@gmx.com>
To: Ian Farrer 
X-Mailer: Apple Mail (2.1510)
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 16:08:05 -0000

--Apple-Mail=_41D4D93D-D59B-4C0B-A2B8-023C048FF46F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Ian,

apologies for the delay. I didn't intend for the review to create more =
work (for me). ;-)

>> MAP provides a data-link layer that supports transport of IPv4. given =
that it uses embedded addresses from
>> IPv6 to algorithmically determine an end-points IPv4 address, you can =
say that IPv4 addressing is inherit=20
>> in the data-link layer. in this model the IPv4 address is tied to =
IPv6. this document proposes to provision IPv4
>> addressing separately with DHCPv4. either this document needs to =
describe how this is supposed to work,
>> or I think make a larger separation between in which cases only =
stateless DHCPv4 can be used, versus
>> which data-links that also stateful DHCPv4 can be used. (I'm only =
aware of Public 4over6 that can support full DHCPv4).
>=20
> [ian] Could we clarify this by extending the introduction to scope the =
document a little more? Something like:
>=20
> In the most basic case of IPv4 provisioning, where the client only =
needs to receive a static IPv4 address and restricted port range =
assignment (with no dynamic address leasing or additional IPv4 =
configuration), DHCPv6 based approaches (such as the one proposed in =
[I-D.ietf-softwire-map-dhcp] may provide a suitable solution. This =
document is concerned with more complex IPv4 configurations scenarios, =
to bring DHCPv4 configuration over IPv6 only networks in line with =
DHCPv4 over IPv4 networks.

yes, I think a clarification in the introduction would help.
stateful DHCPv4 doesn't apply to DS-lite, and it is difficult to see how =
it applies to MAP.
which link-layer did you have in mind for this?
is this work meant to also provide stateful DHCPv4 for MAP tunnels?

e.g. a configured RFC2473 tunnel or Public 4over6, could work.

when it comes to provisioning of a shared IPv4 address, DHCPv4 doesn't =
really do that.
I don't see that described in this document?
I think we need to evaluate if there should be a completely new option =
for IPv4 address and port set, or
a the classic IPv4 address option combined with a new port set option.

>> Section 1.1
>> "2. Extend DHCPv6 with new options for IPv4 configuration, such as
>>  [I-D.ietf-softwire-map-dhcp] describes."
>>=20
>> I think that could be phrased better. MAP DHCP does give the CE =
enough
>> information so that it can calculate it's own IPv4 address. Here it =
reads as if
>> we're adding DHCPv4 options to DHCPv6.
>> I'm not even sure you should have MAP DHCP in this table, it is not a =
solution
>> for passing DHCPv4 options, nor is it a solution to replicate all =
DHCPv4 options
>> in DHCPv6. It is a solution for having the CE calculate it's own IPv4 =
address,
>> shared IPv4 address or prefix. Note that the last two are not even =
supported in DHCPv4.
>> It does not offer any other IPv4 configuration information.
>=20
> [ian] The text at the moment says that 'DHCPv6 has been extended to =
convey the parameters necessary for IPv4 in IPv6 softwire configuration' =
which is true. It doesn't say that MAP DHCP has, or will be, extended =
any further with additional DHCPv4 options.
>=20
> So, as an example of extending DHCPv6 to carry IPv4 configuration, =
it's accurate. However, if we go with the scoping clarification above =
then we could remove the reference here.

thanks.

>> If you have it in the "approaches" list at all:
>> 2. Depend on the setup of data-link (softwire) to offer enough =
information to create IPv4 addressing.
>>     Require no other IPv4 configuration information.
>>=20
>> ** Reading section 1.3. If you want this approach to be "copy =
relevant DHCPv4 options into DHCPv6",
>> then I suggest removing all references to MAP-DHCP.
>>=20
> [ian] See above.
>=20
>> Rename 3. to "stateless DHCPv4" or DHCPINFORM only.
>>=20
> [ian] You mean the approach that's currently called DHCPv6+DHCPv4oSW =
(horrible name:-)? If so, are you proposing 'DHCPv6+stateless DHCPv4 =
over SW' as the new name? I not sure that's much better...

we don't call DHCPv4, "DHCPv4 over Ethernet" today.
"stateless DHCPv4" is most likely the only option available on =
link-layers which have IPv4 address configuration built in.

>> Section 2:
>> Drop requirement 6, I can't see how you can evaluate that.
>=20
> [ian] You can evaluate it on the following basis: If the requirements =
that are described in this document are not your requirements as an =
operator, then you shouldn't be forced to use whatever the conclusion of =
this document is. In practical terms, I see this as 'if MAP DHCP meets =
your requirements, you don't need to bring in DHCPv4 over Foo or =
whatever else'.

I didn't quite understand the implications of that.

>> 8 is empty
>>=20
> [ian] Will fix.
>=20
>> I suggest you add a new requirement:
>> x. Fate sharing. The provisioning of IPv4 addressing and other =
configuration information should be logically tied
>>     to the data-link layer that is uses to provide IPv4 connectivity.
>=20
> [ian] This one's going to be more of a problem, as it pretty much =
directly conflicts with requirement 7, in that the two contradict each =
other. You can only implement data link fate sharing if you've got a hub =
and spoke architecture to locate the hub in (so that if it's not =
available, then IPv4 provisioning also fails)

which link-layer fails that?
I'm dubious about requirement 7 overall. and e.g. DHCPv4 over DHCPv6 is =
restricted to there being a DHCPv6 transport available.

> In the case of a pure mesh network, with no hub and spoke, how could =
you have fate sharing for the data-link layer? The proposed requirement =
pre-supposes a specific underlying architecture.=20

is this the equivalent to the dentist's office case? can you give an =
example of other data link-layers where IPv4 can be provisioned on a =
NBMA link, without a router?

> Can we put this one to the workgroup to ask if this should be included =
as a new req, as it' has not been previously discussed?
>=20
>>=20
>> Section 3:
>> DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing.
>=20
> [ian] Why is it a 'no' for req 4? Section 8 of the DHCPv4 over DHCPv6 =
draft:
>=20
> Additionally, the DHCPv6 relay agent MAY allow the configuration of
>   dedicated DHCPv4 over DHCPv6 specific destination addresses,
>   differing from the addresses of the DHCPv6 only server(s).  To
>   implement this function, the relay checks the received DHCPv6 =
message
>   type and forwards according to the following logic:
>=20
>   1.  If the message type is BOOTREQUESTV6, then the DHCPv6 request is
>       relayed to the configured DHCPv4 aware 4o6 Server's address(es).
>=20
>   2.  For any other DHCPv6 message type, forward according to section
>       20 of [RFC3315].

DHCPv4 over DHCPv6 requires support for transporting DHCPv4 messages in =
DHCPv6 servers and clients.
what do you mean by "independent DHCPv4 and DHCPv6 servers" then?
could you clarify the requirements?
now they do read like they have been reverse engineered.

> For the fate sharing req, as stated above.
>=20
>>=20
>> In the evaluation in section 3.x I suggest dropping the use of =
"complex" and "simple".
>> That appears very subjective.
>>=20
> [ian] OK
>=20
>> 3.4.2 bullet 3. applies to all approaches allowing DHCPv4 leases.
>=20
> [ian] How so? If you have a 'wrapper' type of approach (where DHCPv4 =
is being put into IPv6 or DHCPv6), then the DHCPv4 over xv6 client =
function can be agnostic to what the physical interface is beyond 'it =
must support multicast or unicast'. If the DHCPv4oSW mechanism is not =
linked just to softwires and is essentially a 'vanilla' DHCPv4 client, =
then it must have awareness of the link layer capabilities of the link =
on which it is running and potentially adapt it's behaviour accordingly, =
such as per-client l4 port-restrictions.

I read this bullet to be about the interface to be _provisioned_. =
regardless of how that information reaches the client, the client must =
be aware of the link-layer restrictions. and that I believe apply to all =
mechanisms, regardless.

>=20
>>         bullet 4. please expand.
>=20
> [ian] This was from a question I asked on the ML some time ago, but =
wasn't answered. Does MAP-T support broadcasts through the translator =
function?

I don't see why it wouldn't.

>>         bullet 5. change to "Restricted to a broadcast capable =
link-layer."
>=20
> [ian] Is the hub-and-spoke restriction incorrect? As mentioned above, =
I don't see how this approach can work in a mesh environment. The =
'broadcast capable' restriction is not correct as if a h&s softwire can =
support broadcast, then a ptp mesh softwire can as well. You could =
broadcast DHCPDISCOVERs to peers in a mesh group, but it's not going to =
get you any response.

MAP in mesh mode, still has a point to point tunnel to the BR.
we have not described MAP in a 'pure' mesh mode, i.e. without a BR.

>> 3.5.1 bullet 3. DHCPv4 and DHCPv6 cannot really be separated from =
each other since it=20
>>         it is DHCPv6 that provides transport for DHCPv4. and support =
for the new BOOTP messages
>>         are required in DHCPv6.
>=20
> [ian] But a dedicated DHCPv4 over DHCPv6 server could be deployed =
separate from the DHCPv6 only server. What about changing to read?:
>=20
> 'DHCPv4 and DHCPv6 based provisioning infrastructure can be seperated'

as long as there is a DHCPv4 message capable DHCPv6 server.

>> Minor comments:
>>  Introduction:
>>  "A general trend here is to relocate NAT44 functionality and IPv4
>>  address sharing from the centralized tunnel concentrator to the CPE
>>  in order to achieve better scalability. "
>>=20
>>  I understand what you are trying to say, but unless the reader =
understands that the starting point
>>  are mechanisms like NAT444 and DS-lite, he would find this strange. =
As current deployments
>>  of IPv4 already use distributed NAT.
>=20
> [ian] What about changing the wording to:
>=20
> 'A general trend here is to relocate the translation of privately =
addressed IPv4 traffic to a shared, public external address from the =
centralized tunnel concentrator to the CPE. The distribution of this =
function allows for better scalability.'

that reads better, but I don't agree with the statement that this is a =
general trend.
the trend as I see it from current deployments are centralised NAT. that =
happens in mobile, with NAT444 and with DS-lite.

couldn't you say something along the lines of "In todays residential =
networks, each residential user gets a single global IPv4 address. =
Continuing that model of a decentralised NAT, provides excellent scaling =
properties and combined with stateless functions in the network, simple =
redundancy and logging." modify as you please.

cheers,
Ole

--Apple-Mail=_41D4D93D-D59B-4C0B-A2B8-023C048FF46F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSZqLUAAoJEFuJXizso86g978H/jzSrU1lYu7BCOQYdc5+ewRb
Dmr/A33uNCIKvdfZauZptX5eODstxZwPZJjwoCrEFYU7zOkrYyvVesWwCBB6FxIg
t/45uRzduftq4w3VZaUApKMIa8aAyEA2p3x1zJaIaApicP0ngxEBktFhxkjg0IpF
ObVcGPp5SGdt/Gp1z6f0nxOrQGgV54AOmXUurjn2zRneetaJWMhwYiJ1RTNlva4j
MwnVCQJUQkSvHGntAdPU6dhkx4V/5Qcp5RYfqexUHE3intAofXx+apG0exv/27Q+
VN1Ts6JoJgagtAinGBLSWOy7FBhs6haHaxjmSXlsZ7p/YhuMgRJ4tYPSf7M106Q=
=rpkH
-----END PGP SIGNATURE-----

--Apple-Mail=_41D4D93D-D59B-4C0B-A2B8-023C048FF46F--

From repenno@cisco.com  Tue Oct 22 09:10:41 2013
Return-Path: 
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 8DD3811E81B7 for ; Tue, 22 Oct 2013 09:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.516
X-Spam-Level: 
X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, 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 vLc-tNPNKH+4 for ; Tue, 22 Oct 2013 09:10:36 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1E05711E840A for ; Tue, 22 Oct 2013 09:10:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1863; q=dns/txt; s=iport; t=1382458233; x=1383667833; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gNQoYQVWADzAzkxBNUuJNVIqBK4MAX80zpJCtRAwHhE=; b=ihgll351bbm90glzgHEdnaxLIw0HB6yUOnfisdOTk9PQRxUw4+Haoy7p TRbo6db1skPJUsAVTvN8oB/6PN6S8cCXI7ys1RBdnT8LbMS1AXD0hJDZg XFuOPizdjBJ33OB97lfLojxxtgeOQM+WsPfLABunVozIjIIWmudZ9sem4 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAKqiZlKtJV2Y/2dsb2JhbABZgwc4VL5IgSUWdIInAQQ6NAsSAQgiFEIlAgQOBQiHfrpUjx0xB4MfgQoDmTiQWIMkgio
X-IronPort-AV: E=Sophos;i="4.93,549,1378857600"; d="scan'208";a="275169580"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 22 Oct 2013 16:10:32 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MGAUM9029377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 16:10:31 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 11:10:30 -0500
From: "Reinaldo Penno (repenno)" 
To: Ted Lemon 
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
Thread-Index: AQHOztr9CyHJhGQ69kaVnq/uHEmJSpoAa4KAgACt74D//6nFgA==
Date: Tue, 22 Oct 2013 16:10:30 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B73B14D@xmb-rcd-x04.cisco.com>
In-Reply-To: <5B14C587-4223-4157-AF2B-C9F26C499504@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.101.23]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7DB2670925372942BF4828681890505F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 16:10:41 -0000

Ted,

On 10/22/13 7:19 AM, "Ted Lemon"  wrote:

>On Oct 22, 2013, at 6:56 AM, Reinaldo Penno (repenno) 
>wrote:
>> For example, let's
>> suppose DHCP Server resolves sip.omashu.example.org to 2001:DB8:0:0::2
>>and
>> give that IP to the client. Later this SIP Server fails, now what should
>> the client do? If the client possesses the domain name, it just resolves
>> it again, gets a different IP address (for a different SIP server) and
>>it
>> is good to go. If the client only possesses the IP address of the SIP
>> server, it is stuck until that specific SIP server is online again.
>
>It would be helpful if you were to review the discussion that happened on
>this very mailing list about a week ago about the topic of whether it
>makes sense to configure applications using DHCP.   If you do so, and
>feel that the question you ask above was not adequately addressed during
>that discussion, please add to the discussion.

[RP] that is what I'm doing.

>
>The short answer, though, is that SIP is probably an example of an
>application that (a) should not be configured by DHCP and

[RP] But this draft gives as example in section 5 a DHCP server giving the
address of a SIP server as a DHCP option.

>(b) if it is configured by DHCP anyway, should probably be configured
>using an FQDN.

[RP] And this draft provides the opposite example. In the example in
section 5 the SIP server option is sent as an IP address. This draft says:

"The DHCP server then resolves the domain names listed in the options
   and sends a sip-server option containing the IP addresses that the
   resolver returned for sip.omashu.example.org, and a dns-server option
   containing the IP addresses returned by the resolver for
   dns1.omashu.example.org and dns2.omashu.example.org."


>


From Ted.Lemon@nominum.com  Tue Oct 22 09:15:34 2013
Return-Path: 
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 84AFA11E84DE for ; Tue, 22 Oct 2013 09:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 fuNOCUB9njJ2 for ; Tue, 22 Oct 2013 09:15:26 -0700 (PDT)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4A34C11E840C for ; Tue, 22 Oct 2013 09:15:21 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUmakh+aYWnhmmaI3pRP+DWmEjkxyk6KH@postini.com; Tue, 22 Oct 2013 09:15:24 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C83F81B8152 for ; Tue, 22 Oct 2013 09:15:03 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A775F190052; Tue, 22 Oct 2013 09:15:03 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Tue, 22 Oct 2013 09:14:58 -0700
From: Ted Lemon 
To: "Reinaldo Penno (repenno)" 
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
Thread-Index: AQHOztr+qeyvH50ZYkS21xtwsh9mdZoBAmMAgAA4lACAAB8gAIAAAT6A
Date: Tue, 22 Oct 2013 16:14:58 +0000
Message-ID: 
References: <45A697A8FFD7CF48BCF2BE7E106F06040B73B14D@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B73B14D@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <482C053ED24FFB46B90F51F55FBB338C@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 16:15:34 -0000

On Oct 22, 2013, at 12:10 PM, "Reinaldo Penno (repenno)"  wrote:
> [RP] But this draft gives as example in section 5 a DHCP server giving th=
e
> address of a SIP server as a DHCP option.

Ah, that is the key detail I was missing.   I haven't read the full draft i=
n quite some time; I republished it as a working group draft with comments =
addressed, but didn't do a full review.   And my thinking about SIP servers=
 and DHCP has been informed by recent discussions.

You are right=97we need to find a better example to use.   I'm sorry for mi=
sunderstanding=97I didn't realize that this is what you were saying.


From otroan@employees.org  Tue Oct 22 09:57:09 2013
Return-Path: 
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 F0B5211E81D1 for ; Tue, 22 Oct 2013 09:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level: 
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[AWL=0.499,  BAYES_00=-2.599, 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 MB8jo5RRkcoD for ; Tue, 22 Oct 2013 09:57:04 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5037B11E81BF for ; Tue, 22 Oct 2013 09:56:49 -0700 (PDT)
X-Files: signature.asc : 496
X-IronPort-AV: E=Sophos;i="4.93,549,1378857600";  d="asc'?scan'208";a="160909828"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2013 16:56:44 +0000
Received: from dhcp-10-61-107-167.cisco.com (dhcp-10-61-107-167.cisco.com [10.61.107.167]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MGucYU004491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Oct 2013 16:56:39 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_E296504C-E58B-4FB9-AD36-7CC21118E1CC"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Ole Troan 
In-Reply-To: <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com>
Date: Tue, 22 Oct 2013 18:56:38 +0200
Message-Id: <47131EA3-9EE6-4A10-8A7B-A4897D3078F0@employees.org>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com> <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com> <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1510)
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 16:57:09 -0000

--Apple-Mail=_E296504C-E58B-4FB9-AD36-7CC21118E1CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Ted,

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

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=97e.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-ipv6n=
at-05

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

cheers,
Ole

--Apple-Mail=_E296504C-E58B-4FB9-AD36-7CC21118E1CC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSZq5GAAoJEFuJXizso86gXxUH/0sAlMt0KYdrQ80/Uu8hRv7s
Tha8mY8yDlFGMULAWR07E+k7n9CZVNtnbxu86ix9e276Ca6fnWHfgS1jaqYy0B+B
1NtNfeq+dJko8CZTVVlWPNpunyYVp1AReO2hgfTyg4kqcNzmp8Gqj8ZeOr0JA/Rt
MN8U7vxft0y6IOzfxn6BuD+FpkhOmKl4zMC3bIwjlm7vlgRWSBW3vc15PlYFWcHz
59/WKCIQq4eEhPUFWcBRaSnIPNiU1fXOVoZG/mjJHU6S9kMRIGDWOL+/XKvwyLyy
qK/Yz8UEeJKW/7Ww6KYXRhzJnXqpx6LUXfhIE5wwCnPH8lLUgojB5s0k0Mv2Jic=
=1vHr
-----END PGP SIGNATURE-----

--Apple-Mail=_E296504C-E58B-4FB9-AD36-7CC21118E1CC--

From Ted.Lemon@nominum.com  Tue Oct 22 10:32:48 2013
Return-Path: 
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 7949411E81F0 for ; Tue, 22 Oct 2013 10:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 RQhJFX-Sf5x9 for ; Tue, 22 Oct 2013 10:32:41 -0700 (PDT)
Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 756FA11E81BF for ; Tue, 22 Oct 2013 10:32:35 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUma2s+X/2D1zTzvCzC1o9m3+8sZSpJF+@postini.com; Tue, 22 Oct 2013 10:32:35 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id ABAEE1B82F7 for ; Tue, 22 Oct 2013 10:32:30 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 87B86190052; Tue, 22 Oct 2013 10:32:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Tue, 22 Oct 2013 10:32:30 -0700
From: Ted Lemon 
To: Ole Troan 
Thread-Topic: [dhcwg] What sorts of services does DHCP configure?
Thread-Index: AQHOynEUO3egx6OKW0yTJaZVryMLm5n31OqAgACxKQD//+s9gIAASJSA//++ToCACPedAIAACgSA
Date: Tue, 22 Oct 2013 17:32:29 +0000
Message-ID: 
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com> <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com> <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com> <47131EA3-9EE6-4A10-8A7B-A4897D3078F0@employees.org>
In-Reply-To: <47131EA3-9EE6-4A10-8A7B-A4897D3078F0@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <91BB9D8EE7D2DA45A94C672FB30BAC7F@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 17:32:48 -0000

On Oct 22, 2013, at 12:56 PM, Ole Troan  wrote:
> 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 net=
work to be able to give hosts
> 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 rev=
iew 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 w=
ere somehow accomplished using ND options, probably for the same reason tha=
t people tend to be uncomfortable with default routes coming from DHCPv6 se=
rvers. =20

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


From fluffy@iii.ca  Tue Oct 22 10:56:46 2013
Return-Path: 
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 CC2A711E81ED; Tue, 22 Oct 2013 10:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.643
X-Spam-Level: 
X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599]
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 897YI583Gt3j; Tue, 22 Oct 2013 10:56:36 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9C81411E81F5; Tue, 22 Oct 2013 10:56:35 -0700 (PDT)
Received: from [192.168.4.101] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0119650A88; Tue, 22 Oct 2013 13:56:30 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com>
Date: Tue, 22 Oct 2013 11:58:24 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com>    <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com>   <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com>  <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1510)
X-Mailman-Approved-At: Tue, 22 Oct 2013 11:00:19 -0700
Cc: "dhcwg@ietf.org" , "ietf@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 17:56:47 -0000

Ted, one of the hallmarks of a successful protocol is people use it for =
things it's designers think are an awful idea and it ends up working =
fairly well for them. I think the heart of the issue here is that you =
don't believe that DHCP should be used to configure application-layer =
services, like SIP.  I disagree - I think the text in the draft about =
when to use this is about right=20

   It is necessary to evaluate whether it is
   reasonable for this parameter to be under the control of the
   administrator of whatever network a client is attached to at any
   given time

Furthermore, I don't understand what definition of an application layer =
service you have. Are these application layer services  DNS? NTP? SIP?=20=


I've build small battery powered sensors that use DHCP, DNS and reports =
environmental measurements periodically to a server and have a very good =
handle on the power usage of these devices. I've done ones that use =
ethernet and  802.15.4, (and also ones that don't use DNS or DHCp but =
run over satellite links). On those networks, I have concrete =
measurements that indicate for that system you are wrong about DNS =
making a significant difference to battery life. I realize there might =
be other applications where it does make a difference but so I'm having =
a hard time imagine such an system. The reason why is simple, the bulk =
of traffic a sensor sends over a 30 day period is mostly sensor data not =
DHCP or DNS.=20

On the flip side, for SIP phones we have seen that the level of =
indirection form DNS really helps make the operational issues easier. =20=


I think the draft should not say that IPs are preferred over FQDNs. I =
think it should say the choice of IP or FQDNs depends on the =
applications and factors that should be considered are size, power, =
extra RTT, if a DNS stack is available, code size, and so on. But also =
point out some of the operational management advantages of DNS.=20

Really we are talking about if you have a parameter in some new protocol =
X to control, this BCP is taking the opinion that it knows more about =
protocol X than the protocol X WG and that it thinks the parameter =
should be an IP not FQDN. I think this is wrong, DHCP should deal with =
how transport the configuration parameter that protocol X needs and if =
that is an IP or FQDN is probably a choice best left to experts of =
protocol X.  Heck, I'll go a scope further, I think it is not in charter =
of the DHC working to determine if IP or FQDN are best to configure a =
parameter in some future protocol done by some other WG. =20

bit more inline =85

On Oct 10, 2013, at 9:41 AM, Ted Lemon  wrote:

> On Oct 9, 2013, at 11:49 PM, Cullen Jennings  wrote:
>>> If this argument were correct, we'd expect to see major O.S. vendors =
supporting the NTP option, but we don't=97instead, it's something that =
can be configured in the UI for situations like the one you describe, =
and that otherwise is defaulted to the preconfigured value, which of =
course can be updated when the operating system is updated.
>>=20
>> Right - I am certainly more focused on the devices that don't have an =
administrator that can configure them locally.=20
>=20
> This is great, but that's not all devices.   And devices of this type =
often wind up being very vulnerable to attack precisely because no =
usable escape mechanism is offered.   DHCP may be your only choice for =
configuring such a device, but it's a really lousy choice.

Louse choice? What exactly would you propose that would work better ?

>=20
>>> So where I would expect to see the NTP option used is in devices =
that don't _have_ user interfaces.   Your IP phone might be such a =
device.   I suspect the bias you have toward using a DHCP option has a =
lot to do with where these devices are typically installed: in corporate =
environments.
>>=20
>> Agree I am focused on the VoIP stuff but it is both SP and =
enterprises.=20
>>=20
>>> I don't even know if I could get one to use at home, or if it would =
work.
>>=20
>> They work in residential deployments (which might be a bit different =
than you mean by home) and DHCP can provide some very critical services =
for them. For example rfc5223 is a DHCP options that provides the LOST =
server that provides the mapping to locations that can be used for E911 =
calls and is applicable to residential.=20
>=20
> I challenge you to find a single commonly-used home gateway that =
supports this RFC, and that is not VoIP-specific.   If one does, it's =
hard to see any reason why it matters whether the IP address of the E911 =
location service protocol is delivered directly or through an FQDN.

There are large SPs in some countries that rolled this out across the =
NATs they provide customers. But this argument seems way off the topic =
of one should prefer use of IP addresses over FQDNs

>=20
>> Sure I believe you about what DHCP servers are capable of doing =
(which I will note might be different than how they are commonly =
deployed). I was talking about the issue here of from a protocol design =
point of view, one should prefer the use of an IP address or FQDN in the =
DHCP option for a case like this.=20
>=20
> Commonly deployed by whom?   The ISC DHCP server supported the =
functionality that I'm describing in 1997.   Nominum's DHCP server =
supported it on first release.   Cisco's server supported it back when =
it was still a separate company called American Internet, at least as =
early as 1997.   The only commonly-used server that I think does not =
support this functionality is Microsoft's.   I suppose some enterprise =
environments might use this server, which might explain why you are =
assuming that behavior, but we shouldn't decide how to do things based =
on a single implementation that, if it operates in the way you describe, =
is IMHO broken.

You are off in the weeds here - I never disagreed that there were not =
DHCP servers that implemented this.=20

>=20
>> When I said "move" I'm talking the roughly the same thing as you mean =
here of bring up a new service. So lets take a VoIP provider like AT&T =
or a large enterprise like GE. Let say that have a server called =
time.ge.com in DNS. Figuring out the TTL for that is pretty easy. =
Changing it to reduce down around the time of the move is pretty easy as =
you can chance it one place and DNS sync it to the other DNS servers. =
Now lets consider doing the same thing with DHCP. How many DHCP server =
do you think either of theses have? Consistent tools to manage all them =
from a central location? The admin know when they are moving servers =
they need to deal with the DNS - but do they all even remember to update =
the DHCP?
>>=20
>> The we have the issue of NATs that act as DHCP clients, get an =
option, then re-advertise that option as a DHCP server on the private =
side. I realize that if they advertise it for longer on the private side =
than the lease was valid on the public side is just really broken, but =
none the less I'm sure no one will be shocked to find out there are =
broken NATs.=20
>>=20
>> I've been involved with deployments bitten by every one of of the =
above. That make me prefer FQDN unless it is a case where DNS might not =
be supported or not operational, or a case where the time / power of the =
DNS query makes a significant difference to the  system.=20
>=20
> Right, and I think I already said that (a) SIP is a bad example of a =
use case for DHCP, because it's a node-specific service, not a =
network-specific service, and (b) it's probably fine, if you must use =
DHCP to configure SIP, to use an FQDN, as I already said several =
messages back.

Sure, and why does that same argument not hold for configuring similar =
services which is what I complained about in the draft.=20

>=20
>> I thought about what you wrote here for a long time. I suspect that =
is part of the issue is that people such as myself that are not DHCP =
experts don't know what services are not appropriate to use it for. We =
see it as a hammer and we are off pounding nails, or screws. I view SRV =
as an OK way to control load balancing across a set of servers that have =
different capacity - often due to be deployed on faster computers over =
time. Why would a service with that property not be someone one would =
use DHCP for.=20
>=20
> Well, for example, would you use SRV records to do load balancing on a =
DNS server?   An NTP server?   A router (which in the context of DHCPv6 =
probably means an AFTR)?   I think you would not.

Look, I am not arguing that one should not us IP address in some cases. =
I'm arguing that there are equally good cases where one should use FQDN. =
I realize they are not popular with the layer 2/3 folks but they are =
very popular with the application layer folks because of the flexibility =
and easy of managment they provide.=20

>=20
>>> I would argue that if it makes any sense at all for there to be a =
SRV record, that's a strong argument against using DHCP to configure =
that service.  =20
>>=20
>> tell me more - this one I did not get.=20
>=20
> SRV records are normally used for application-layer services, like =
SIP, which I don't think should be configured with DHCP.   Similarly, =
would you use DHCP to configure the address of an HTTP server? :)

This seems to be the heart of it. You don't think this should be used =
for application layer services but I don't think that ship sailed long =
long ago.=20

>=20
>>> Right, and at the moment they almost certainly have their NTP server =
FQDNs hard-coded, and it works, and you don't even know it's working =
this way, because it's a solid solution in a home network.  The issue =
with DNS on constrained devices is that it's another packet round trip, =
and packets burn battery.  =20
>>=20
>> Give me an example where that makes a difference. When I look at this =
as the power to do a DNS query amortized over the lifetime of the lease =
or uptime of the device I'm just having a hard time thinking of the =
right example to motivate this.=20
>=20
> Any device that has a battery and needs to run unattended for a long =
period of time will pay a penalty for doing DNS queries over and over =
again; requiring it to do so is a bad practice.   If such a device does =
use DHCP, it almost certainly wants to use very long information refresh =
timers.   Using a short TTL in DNS for a service used by such a device =
either will not work, or will cause the device to prematurely drain its =
battery.

Once again, please give me an example where the ext ran DNS traffic from =
the device forms any relevant percentage of the traffic and/or power =
usage.=20

> These devices are real, likely represent a very significant area of IP =
service growth in the coming decade or two, and need to be supported.   =
If such a device uses a service discovery protocol, and that service =
discovery protocol probably were to deliver information via FQDNs, the =
device would have to query the DNS multiple times, at least one for each =
service, in order to resolve those FQDNs, each time it does a service =
discovery refresh.   It would also be well advised to query those FQDNs =
again anytime the TTL on the record returned in the previous query =
expired.

The refresh on DNS TTL is same as refresh on DHCP lease time

>=20
> DHCP does all the queries for you at the same time and hands you a =
single packet with all the information you need to contact all the =
services offered by DHCP.   This can be expected to result in many fewer =
packet round trips, and consequently much less power spent.   This is a =
significant feature; getting rid of it in order to make life a little =
more convenient for operators who do not have to deal with these =
constraints is a poor value proposition for the protocol as a whole.
>=20
> BTW, another example of a constrained device is a network booted =
device, where despite the fact that the node itself is quite capable =
once it's booted, the boot prom is quite constrained.   I think this was =
a primary motivation for the choice of address versus FQDN back in =
DHCPv4 days; I suspect relevant in fewer cases now, but still relevant =
in some.

Again, that's a fine argument why BOOTP should use IP, however it is not =
an argument about why nothing else should use FQDN

>=20
> (I will note, by the way, that you have yet to raise a point that was =
not considered and addressed by the working group.   I think this =
discussion is useful, because it points to clarifications that should be =
made to the document, but I don't yet see anything that would suggest to =
me that the consensus call went the wrong way.)

Well, why don't you come over to RAI and do a presentation on why we =
should not use FQDN in DHCP and see what the consensus is over there. =
I'm sure the ADs could arrange some agenda time in the dispatch meeting =
which is closest things that RAI has to an area meeting at IETF 88.  The =
consensus of a particular WG does not necessarily represent the =
consensus of the IETF.=20





From repenno@cisco.com  Tue Oct 22 11:05:28 2013
Return-Path: 
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 E10F311E8225 for ; Tue, 22 Oct 2013 11:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 rt0OradkKyzU for ; Tue, 22 Oct 2013 11:05:22 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A81D111E81F4 for ; Tue, 22 Oct 2013 11:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1148; q=dns/txt; s=iport; t=1382465122; x=1383674722; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QOn0PGIbq5WUVptGp7d3zIhHqdaR91CKU2pqddy6lHM=; b=XyjMNKTW1ZlaSe55TgtWpjKNPiq0cwwwyM9ff3j1pKfBy2+i8Ur4PsGq wJ1iclOQhZBZknlDtNABIdF+AdyFm6soeLFeTH7PsA7UQxDDuafQgqycP yD35zPcbXxh/YTCEUtbpLkIxtbrZN6p0QYUgwS5XepN7VUIsSn1DboOYX g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAKG9ZlKtJV2Y/2dsb2JhbABZgwc4VL5KgSgWdIIlAQEBBHkSAQgYClYlAgQOBQiHfg26ZI8dMQeDH4EKA5k4kFiDJIIq
X-IronPort-AV: E=Sophos;i="4.93,549,1378857600"; d="scan'208";a="275239386"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 22 Oct 2013 18:05:22 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MI5LLr003327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 18:05:22 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 13:05:21 -0500
From: "Reinaldo Penno (repenno)" 
To: Ted Lemon 
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
Thread-Index: AQHOztr9CyHJhGQ69kaVnq/uHEmJSpoAa4KAgACt74D//6nFgIAAdpkA//+pfgA=
Date: Tue, 22 Oct 2013 18:05:21 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B73C8C1@xmb-rcd-x04.cisco.com>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.101.23]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <4EF2C8BB281A2240AC70700B7F3A6A88@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 18:05:28 -0000

Good that we converged. My suggestion would be to use SIP Servers as an
example of something that should be passed as FQDN (assuming there is a
good reason for a deployment). We can then mention the benefits for client
in terms of Load balancing and failure.

We can replace the SIP option by something that should be returned as an
IP address, for example http://tools.ietf.org/html/rfc5192

Thanks,

Reinaldo

On 10/22/13 9:14 AM, "Ted Lemon"  wrote:

>On Oct 22, 2013, at 12:10 PM, "Reinaldo Penno (repenno)"
> wrote:
>> [RP] But this draft gives as example in section 5 a DHCP server giving
>>the
>> address of a SIP server as a DHCP option.
>
>Ah, that is the key detail I was missing.   I haven't read the full draft
>in quite some time; I republished it as a working group draft with
>comments addressed, but didn't do a full review.   And my thinking about
>SIP servers and DHCP has been informed by recent discussions.
>
>You are right=8Bwe need to find a better example to use.   I'm sorry for
>misunderstanding=8BI didn't realize that this is what you were saying.
>


From Ted.Lemon@nominum.com  Tue Oct 22 11:56:38 2013
Return-Path: 
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 0F8CB11E821B; Tue, 22 Oct 2013 11:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level: 
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 49n3xwvJetwe; Tue, 22 Oct 2013 11:56:29 -0700 (PDT)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3B61311E822A; Tue, 22 Oct 2013 11:55:46 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUmbKHQ/O19uo4sjbHS7wgZNmzoeFxIBr@postini.com; Tue, 22 Oct 2013 11:55:47 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 45B0C1B813B; Tue, 22 Oct 2013 11:55:25 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2CB65190052; Tue, 22 Oct 2013 11:55:25 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.03.0158.001; Tue, 22 Oct 2013 11:55:25 -0700
From: Ted Lemon 
To: Cullen Jennings 
Thread-Topic: Last Call:  (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
Thread-Index: AQHOxG6vvYfRrCcaWUK4N3Cm629TPZns9HaA///CyYCAAGBrgP//wqiAgACIuQD///LeAAANvZ8AAAxP5AACbNgWAAAB/XiA
Date: Tue, 22 Oct 2013 18:55:24 +0000
Message-ID: <44771FA3-5660-45CB-AE84-3458C7DA4D87@nominum.com>
References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com>    <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com>   <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com>  <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <861D4BC8E8ED4B4EA68241C262FA1520@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" , "ietf@ietf.org" 
Subject: Re: [dhcwg] Last Call:  (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 18:56:38 -0000

On Oct 22, 2013, at 1:58 PM, Cullen Jennings  wrote:
> Ted, one of the hallmarks of a successful protocol is people use it for t=
hings it's designers think are an awful idea and it ends up working fairly =
well for them. I think the heart of the issue here is that you don't believ=
e that DHCP should be used to configure application-layer services, like SI=
P.  I disagree - I think the text in the draft about when to use this is ab=
out right=20

Argh.   No.   The hallmark of a successful protocol is not that it attracts=
 barnacles and gets used in ways that ultimately fail, either due to a real=
ly bad security model, or a bad fit, or other reasons.

DHCP in fact has been very successful in the IETF as a place to add barnacl=
es.   There are lots of DHCP option extensions that do all kinds of really =
exciting things.   Most of them were implemented once, shortly after public=
ation, never deployed, and now, if they exist at all, exist only as an atta=
ck surface that nobody has yet exploited hard enough to cause the feature t=
o be removed from the client implementation.

The actual success of DHCP is its core ability to configure devices with th=
e information they need to get online.   If you look at a typical DHCP pack=
et from a typical host, it doesn't ask for SIP servers.   It doesn't ask fo=
r printers.   It doesn't ask about SMTP or IMAP or POP.

My DHCPv4 client asks for: Subnet Mask, Default Gateway, Domain Name Server=
, Domain Name, Domain Search List, LDAP Server Address, WPAD Proxy URL, Net=
bios Name Server and Netbios Node Type.   My DHCPv6 client requests DNS Ser=
ver address and Domain Search List.

You will notice that it doesn't ask for an NTP option, even though it uses =
NTP.   This is because asking for an NTP option will generate support calls=
.  It doesn't ask for a printer address.   This is because although DHCPv4 =
provides a way to deliver printer addresses, nobody uses it.   Bonjour is e=
asier and more convenient, and generates fewer support calls.   Even though=
 I have an email client running, it doesn't ask for IMAP server, SMTP serve=
r or POP server, because that would be ridiculous.

So yes, DHCP is a successful protocol.   And yes, application protocol desi=
gners have attempted to use it to configure their protocols.   But they hav=
en't succeeded, in the large, because it's a bad idea.   It is not a succes=
sful _applications service discovery_ protocol.   It is a successful _host =
configuration_ protocol.

> I've build small battery powered sensors that use DHCP, DNS and reports e=
nvironmental measurements periodically to a server and have a very good han=
dle on the power usage of these devices. I've done ones that use ethernet a=
nd  802.15.4, (and also ones that don't use DNS or DHCp but run over satell=
ite links). On those networks, I have concrete measurements that indicate f=
or that system you are wrong about DNS making a significant difference to b=
attery life. I realize there might be other applications where it does make=
 a difference but so I'm having a hard time imagine such an system. The rea=
son why is simple, the bulk of traffic a sensor sends over a 30 day period =
is mostly sensor data not DHCP or DNS.=20

Indeed, in this scenario, power consumed by DNS and DHCP will not be an iss=
ue.

> On the flip side, for SIP phones we have seen that the level of indirecti=
on form DNS really helps make the operational issues easier.

Yes, and SIP is a lousy example, because it's not generally configured usin=
g DHCP=97it's generally configured through a user interface.   When it _is_=
 configured using DHCP, it's done in a constrained environment.   The confi=
guration model used in that environment would be a security disaster on the=
 open internet.

> I think the draft should not say that IPs are preferred over FQDNs. I thi=
nk it should say the choice of IP or FQDNs depends on the applications and =
factors that should be considered are size, power, extra RTT, if a DNS stac=
k is available, code size, and so on. But also point out some of the operat=
ional management advantages of DNS.=20

I agree that these are all good things to mention.   However, I think the d=
ocument should steer people away from using FQDNs, because if they need to =
use FQDNs, they will regardless of what direction the document tries to ste=
er them.

> Really we are talking about if you have a parameter in some new protocol =
X to control, this BCP is taking the opinion that it knows more about proto=
col X than the protocol X WG and that it thinks the parameter should be an =
IP not FQDN. I think this is wrong, DHCP should deal with how transport the=
 configuration parameter that protocol X needs and if that is an IP or FQDN=
 is probably a choice best left to experts of protocol X.  Heck, I'll go a =
scope further, I think it is not in charter of the DHC working to determine=
 if IP or FQDN are best to configure a parameter in some future protocol do=
ne by some other WG.

It is in the charter to recommend best practices for DHCP.

> On Oct 10, 2013, at 9:41 AM, Ted Lemon  wrote:
>> On Oct 9, 2013, at 11:49 PM, Cullen Jennings  wrote:
>>>> If this argument were correct, we'd expect to see major O.S. vendors s=
upporting the NTP option, but we don't=97instead, it's something that can b=
e configured in the UI for situations like the one you describe, and that o=
therwise is defaulted to the preconfigured value, which of course can be up=
dated when the operating system is updated.
>>>=20
>>> Right - I am certainly more focused on the devices that don't have an a=
dministrator that can configure them locally.=20
>>=20
>> This is great, but that's not all devices.   And devices of this type of=
ten wind up being very vulnerable to attack precisely because no usable esc=
ape mechanism is offered.   DHCP may be your only choice for configuring su=
ch a device, but it's a really lousy choice.
>=20
> Louse choice? What exactly would you propose that would work better ?

What would be better would be a secure mechanism for configuring them.   E.=
g., going to a well-known URL and downloading a configuration signed using =
a tool that allows the device to validate the configuration.   This is what=
 e.g. Microsoft Exchange clients do.   It works quite well.

>> Right, and I think I already said that (a) SIP is a bad example of a use=
 case for DHCP, because it's a node-specific service, not a network-specifi=
c service, and (b) it's probably fine, if you must use DHCP to configure SI=
P, to use an FQDN, as I already said several messages back.
>=20
> Sure, and why does that same argument not hold for configuring similar se=
rvices which is what I complained about in the draft.=20

In general, configuring similar services using DHCP won't work.   I'm not c=
onvinced it works for SIP.   I'm fairly sure it doesn't work for configurin=
g NTP.

> Look, I am not arguing that one should not us IP address in some cases. I=
'm arguing that there are equally good cases where one should use FQDN. I r=
ealize they are not popular with the layer 2/3 folks but they are very popu=
lar with the application layer folks because of the flexibility and easy of=
 managment they provide.=20

Can you give me an example of a use case that is _not_ an APPS-area protoco=
l?

BTW, you mentioned that you think NTP and DNS are application layer, but th=
ey are in the INT area for a reason.   I mean a protocol that's in the APPS=
 area, for an equally good reason.

>> SRV records are normally used for application-layer services, like SIP, =
which I don't think should be configured with DHCP.   Similarly, would you =
use DHCP to configure the address of an HTTP server? :)
>=20
> This seems to be the heart of it. You don't think this should be used for=
 application layer services but I don't think that ship sailed long long ag=
o.=20

The ship sailed long ago, and sank out at sea, yes.   I was on it at the ti=
me=97like you, I used to think DHCP was for configuring applications.   I d=
id not arrive at my current opinion accidentally.

> Once again, please give me an example where the ext ran DNS traffic from =
the device forms any relevant percentage of the traffic and/or power usage.=
=20

Any time the frequency of reports from the device is similar in frequency t=
o refreshes required by the DNS TTL expiring.

> The refresh on DNS TTL is same as refresh on DHCP lease time

Yes, and if you have to do six DNS queries per DHCP renewal, that's six mor=
e packet exchanges.

>> DHCP does all the queries for you at the same time and hands you a singl=
e packet with all the information you need to contact all the services offe=
red by DHCP.   This can be expected to result in many fewer packet round tr=
ips, and consequently much less power spent.   This is a significant featur=
e; getting rid of it in order to make life a little more convenient for ope=
rators who do not have to deal with these constraints is a poor value propo=
sition for the protocol as a whole.
>>=20
>> BTW, another example of a constrained device is a network booted device,=
 where despite the fact that the node itself is quite capable once it's boo=
ted, the boot prom is quite constrained.   I think this was a primary motiv=
ation for the choice of address versus FQDN back in DHCPv4 days; I suspect =
relevant in fewer cases now, but still relevant in some.
>=20
> Again, that's a fine argument why BOOTP should use IP, however it is not =
an argument about why nothing else should use FQDN

I don't think you said what you meant here.   BOOTP is a predecessor to DHC=
P=97what does that have to do with this conversation?

>> (I will note, by the way, that you have yet to raise a point that was no=
t considered and addressed by the working group.   I think this discussion =
is useful, because it points to clarifications that should be made to the d=
ocument, but I don't yet see anything that would suggest to me that the con=
sensus call went the wrong way.)
>=20
> Well, why don't you come over to RAI and do a presentation on why we shou=
ld not use FQDN in DHCP and see what the consensus is over there. I'm sure =
the ADs could arrange some agenda time in the dispatch meeting which is clo=
sest things that RAI has to an area meeting at IETF 88.  The consensus of a=
 particular WG does not necessarily represent the consensus of the IETF.=20


(a) I can't.
(b) It would be useless.   Of course RAI is going to say DHCP should suppor=
t configuring application protocols.   Why not?   It's a cost-free assertio=
n from your perspective.
(c) This document is saying what the DHC working group recommends.   RAI wo=
rking groups are free to go against these recommendations.   So this docume=
nt shouldn't say what RAI recommends.   It should say what DHC recommends. =
  If a working group doesn't want to follow the advice, they don't have to,=
 because it's just advice, not a requirement.=

From otroan@employees.org  Tue Oct 22 12:03:54 2013
Return-Path: 
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 4043011E83AF for ; Tue, 22 Oct 2013 12:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.266
X-Spam-Level: 
X-Spam-Status: No, score=-10.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, 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 B+nguaBOb-si for ; Tue, 22 Oct 2013 12:03:47 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 939EE11E823A for ; Tue, 22 Oct 2013 12:01:29 -0700 (PDT)
X-Files: signature.asc : 496
X-IronPort-AV: E=Sophos;i="4.93,549,1378857600";  d="asc'?scan'208";a="18459483"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 22 Oct 2013 19:01:21 +0000
Received: from dhcp-10-61-107-167.cisco.com (dhcp-10-61-107-167.cisco.com [10.61.107.167]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9MJ1FLa022247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Oct 2013 19:01:16 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_1307B6CA-CD5B-49A8-9AED-D07176B45BD1"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Ole Troan 
In-Reply-To: 
Date: Tue, 22 Oct 2013 21:01:15 +0200
Message-Id: <94D7FDC2-ADAE-4D93-85CF-95B66B5FDB6D@employees.org>
References: <0CAF13FF2DE695F55BFEEB8BD88E542A@thehobsons.co.uk> <489D13FBFA9B3E41812EA89F188F018E1AD1E42C@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD49863@nkgeml512-mbx.china.huawei.com> <8E7FD62B-550F-4A71-AF31-1B2DCB53AF0F@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AD499E3@nkgeml512-mbx.china.huawei.com> <6B818FA6-79AD-41DA-93C0-47556DFD18E7@nominum.com> <47131EA3-9EE6-4A10-8A7B-A4897D3078F0@employees.org> 
To: Ted Lemon 
X-Mailer: Apple Mail (2.1510)
Cc: "dhcwg@ietf.org WG" , "Bernie Volz \(volz\)" 
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: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Oct 2013 19:03:54 -0000

--Apple-Mail=_1307B6CA-CD5B-49A8-9AED-D07176B45BD1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Ted,

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

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


--Apple-Mail=_1307B6CA-CD5B-49A8-9AED-D07176B45BD1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSZst7AAoJEFuJXizso86glHwIAKmi88rOL46q2v7wMwHH1VJM
U1A2Aaz3M24NH3Atdloqc7FAvmklUFy5TPUvHoqK+inLCUIDyAhfAGYAywAkt5K0
FllvXSknpOUY4hc9KNZ0mzrp8TDEDjHjxGGLrT7IfxhMvCMeAU5+m+P//t572b3F
niHRTVis1e5ZKK3+qmPhM5rxyrrh1N4XYUT3Sl6XE5xyy1EBScW0U94pwh1KA/Gc
C/6wQTmRetJBEaQZx4VfTB37b8Tei+LKDw429ltQBri7q0blRbGtGyuuBPWh7cCZ
RPMFZxmDzVf4B+omkESqn6aLlZ7AfkDT4OwhnrsKnckvDy/X2RIiv7YAY43lvPY=
=bPEK
-----END PGP SIGNATURE-----

--Apple-Mail=_1307B6CA-CD5B-49A8-9AED-D07176B45BD1--

From wwwrun@rfc-editor.org  Wed Oct 23 04:25:24 2013
Return-Path: 
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 2E32A11E8360 for ; Wed, 23 Oct 2013 04:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.395
X-Spam-Level: 
X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 9bjL7dgqvkRe for ; Wed, 23 Oct 2013 04:25:23 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 04AAE11E839E for ; Wed, 23 Oct 2013 04:25:17 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id D01E8726001; Wed, 23 Oct 2013 04:16:41 -0700 (PDT)
To: john_brzozowski@cable.comcast.com, kkinnear@cisco.com, volz@cisco.com, szeng@cisco.com, brian@innovationslab.net, ted.lemon@nominum.com, volz@cisco.com, tomasz.mrugalski@gmail.com
From: RFC Errata System 
Message-Id: <20131023111641.D01E8726001@rfc-editor.org>
Date: Wed, 23 Oct 2013 04:16:41 -0700 (PDT)
X-Mailman-Approved-At: Wed, 23 Oct 2013 04:34:50 -0700
Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org
Subject: [dhcwg] [Technical Errata Reported] RFC5007 (3763)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 11:25:24 -0000

The following errata report has been submitted for RFC5007,
"DHCPv6 Leasequery".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5007&eid=3763

--------------------------------------
Type: Technical
Reported by: Darpan Malhotra 

Section: GLOBAL

Original Text
-------------
4.3.3. Receipt of LEASEQUERY-REPLY

1.  If the server had bindings for the requested client, the message
    includes an OPTION_CLIENT_DATA option and the requestor extracts
    the client data from the LEASEQUERY-REPLY and updates its binding
    information database.  If the OPTION_CLIENT_DATA contains no
    OPTION_CLT_TIME, the requestor SHOULD silently discard the
    OPTION_CLIENT_DATA option.

4.3.4. Handling DHCPv6 Client Data from Multiple Sources

   The requestor SHOULD use the OPTION_CLT_TIME to resolve data
   conflicts originated from different servers, and SHOULD accept data
   with most recent OPTION_CLT_TIME.

Corrected Text
--------------
4.3.3. Receipt of LEASEQUERY-REPLY

1.  If the server had bindings for the requested client, the message
    includes an OPTION_CLIENT_DATA option and the requestor extracts
    the client data from the LEASEQUERY-REPLY and updates its binding
    information database.  

4.3.4. Handling DHCPv6 Client Data from Multiple Sources

   The requestor SHOULD use the OPTION_CLT_TIME to resolve data
   conflicts originated from different servers, and SHOULD accept data
   with most recent OPTION_CLT_TIME. If OPTION_CLT_TIME is not
   present in a response, then response from other servers having
   OPTION_CLT_TIME should be preferred.


Notes
-----
Consider the scenario of DHCPv6 Failover (as mentioned in RFC 7031), there will be cases where only one server (Main) would have communicated with the client. Bindings for the client will be present on both servers, but the partner server (Backup) will not have Client Last Transaction Time. When a requestor sends Leasequery to the backup server, the response should not contain OPTION_CLT_TIME.

Further, consider the following scenarios:
1. Requestor gets response for Leasequery from both servers (main and backup).
In this scenario, response having OPTION_CLT_TIME should be preferred by the requestor. This is the justification for adding the text in Section 4.3.4.

2. Requestor gets response for Leasequery from only from one server (as other server is down).
Consider main to be down. So, the requestor gets response only from Backup. The requestor should still accept this data. This is justification of removing the text from Section 4.3.3.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5007 (draft-ietf-dhc-dhcpv6-leasequery-01)
--------------------------------------
Title               : DHCPv6 Leasequery
Publication Date    : September 2007
Author(s)           : J. Brzozowski, K. Kinnear, B. Volz, S. Zeng
Category            : PROPOSED STANDARD
Source              : Dynamic Host Configuration
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

From sunqi.csnet.thu@gmail.com  Wed Oct 23 06:58:02 2013
Return-Path: 
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 4E85811E839B for ; Wed, 23 Oct 2013 06:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level: 
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, GB_ABOUTYOU=0.5, J_CHICKENPOX_53=0.6]
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 NQqZ1JBQscIn for ; Wed, 23 Oct 2013 06:58:01 -0700 (PDT)
Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2A85F11E838B for ; Wed, 23 Oct 2013 06:58:01 -0700 (PDT)
Received: by mail-pb0-f43.google.com with SMTP id md12so699232pbc.16 for ; Wed, 23 Oct 2013 06:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YmWAisqnbdAaIkSpFxTagRrj9FmmJfLY8RYntjCxSk4=; b=y1HCuz68QxTIs6tmKdjmPHc2e7chkSTugcHXRMLe/Z0dvbxprXDQkI+wa7tFilhF2E Mvh1VtpCKM7SDK0xblm8xUcB7zsdG0Sax2MttmGWREKQbI0dn+nSLSmuw1WnSVPr9uWH mWyKBRvkDtQHCWQzl2TRZvFpoEBPxO4FmQpycHjkSZctMpZLkVXUr+ArNGR1oMY+hvzc Wxqy455lM1wHjVq86Rq/gsttKqKP1ZgLS3kGRys5YGoeMO0MTZFf3tjPvkgvpU4eTtjt IOSRUscEWHN0Ps8zUX3cF9G0wcFqEw1dbKfX9fNIMy3rxf+fMilcb3Tz5TpCxMkMjpbH 0dFQ==
X-Received: by 10.68.91.3 with SMTP id ca3mr1885291pbb.20.1382536680950; Wed, 23 Oct 2013 06:58:00 -0700 (PDT)
Received: from [192.168.199.122] ([166.111.68.231]) by mx.google.com with ESMTPSA id xn12sm41457377pac.12.2013.10.23.06.57.57 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 06:57:59 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Qi Sun 
In-Reply-To: <73774E7F-38E3-4F41-822C-093444CA99B1@employees.org>
Date: Wed, 23 Oct 2013 21:57:52 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130930140054.31558.95411.idtracker@ietfa.amsl.com> <6A05E003-42A2-4659-9F23-6F5DFC6A88EF@gmx.com> <2C4C5302-C2CA-4F85-B053-78D317FD7964@employees.org> <3A7ED0DA-EE87-496C-AC7D-C4D3D937FB84@gmx.com> <73774E7F-38E3-4F41-822C-093444CA99B1@employees.org>
To: Ole Troan 
X-Mailer: Apple Mail (2.1085)
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 13:58:02 -0000

Dear Ole ,

I have some thinkings about your message. Please see inline.

>>> MAP provides a data-link layer that supports transport of IPv4. =
given that it uses embedded addresses from
>>> IPv6 to algorithmically determine an end-points IPv4 address, you =
can say that IPv4 addressing is inherit=20
>>> in the data-link layer. in this model the IPv4 address is tied to =
IPv6. this document proposes to provision IPv4
>>> addressing separately with DHCPv4. either this document needs to =
describe how this is supposed to work,
>>> or I think make a larger separation between in which cases only =
stateless DHCPv4 can be used, versus
>>> which data-links that also stateful DHCPv4 can be used. (I'm only =
aware of Public 4over6 that can support full DHCPv4).
>>=20
>> [ian] Could we clarify this by extending the introduction to scope =
the document a little more? Something like:
>>=20
>> In the most basic case of IPv4 provisioning, where the client only =
needs to receive a static IPv4 address and restricted port range =
assignment (with no dynamic address leasing or additional IPv4 =
configuration), DHCPv6 based approaches (such as the one proposed in =
[I-D.ietf-softwire-map-dhcp] may provide a suitable solution. This =
document is concerned with more complex IPv4 configurations scenarios, =
to bring DHCPv4 configuration over IPv6 only networks in line with =
DHCPv4 over IPv4 networks.

[Qi] Why static IPv4 address and port-set assignment is 'the most basic =
case of IPv4 provisioning'? For DHCPv4 (_Dynamic_ Host Configuration =
Protocol), dynamic assignment of IPv4 is the 'most basic case', IMO.

>=20
> yes, I think a clarification in the introduction would help.
> stateful DHCPv4 doesn't apply to DS-lite, and it is difficult to see =
how it applies to MAP.
> which link-layer did you have in mind for this?

[Qi] What is the 'link-layer' you mentioned? Do you mean IPv6 can be =
seen as the 'link-layer' for IPv4 in the context of IPv4-over-IPv6 =
scenario? Sorry if I mis-understood you.

> is this work meant to also provide stateful DHCPv4 for MAP tunnels?
>=20
> e.g. a configured RFC2473 tunnel or Public 4over6, could work.
>=20
> when it comes to provisioning of a shared IPv4 address, DHCPv4 doesn't =
really do that.
> I don't see that described in this document?
> I think we need to evaluate if there should be a completely new option =
for IPv4 address and port set, or
> a the classic IPv4 address option combined with a new port set option.

[Qi] AFAIK, in DHCPv4, IPv4 address is not put in an option. So to =
support the assignment of a shared IPv4 address, port-set is the =
information that needs to go to an option.

Actually there have been mechanisms to describe the usage.=20

>=20
>>> Section 1.1
>>> "2. Extend DHCPv6 with new options for IPv4 configuration, such as
>>> [I-D.ietf-softwire-map-dhcp] describes."
>>>=20
>>> I think that could be phrased better. MAP DHCP does give the CE =
enough
>>> information so that it can calculate it's own IPv4 address. Here it =
reads as if
>>> we're adding DHCPv4 options to DHCPv6.
>>> I'm not even sure you should have MAP DHCP in this table, it is not =
a solution
>>> for passing DHCPv4 options, nor is it a solution to replicate all =
DHCPv4 options
>>> in DHCPv6. It is a solution for having the CE calculate it's own =
IPv4 address,
>>> shared IPv4 address or prefix. Note that the last two are not even =
supported in DHCPv4.
>>> It does not offer any other IPv4 configuration information.

[Qi] MAP-dhcp is _not_ the solution for having the CE calculate IPv4 =
info. MAP does. MAP-dhcp only provisions information.=20

//A side note: I don't understand why map-dhcp needs to support to =
assign IPv4 prefix. It was not even supported when IPv4 addresses were =
sufficient. At the time we are running out of IPv4 addresses, but we =
need to assign IPv4 prefixes...
Sorry if I mis-lead the discussion...

>>=20
>> [ian] The text at the moment says that 'DHCPv6 has been extended to =
convey the parameters necessary for IPv4 in IPv6 softwire configuration' =
which is true. It doesn't say that MAP DHCP has, or will be, extended =
any further with additional DHCPv4 options.
>>=20
>> So, as an example of extending DHCPv6 to carry IPv4 configuration, =
it's accurate. However, if we go with the scoping clarification above =
then we could remove the reference here.
>=20
> thanks.

[Qi] =46rom my reading, the reference here is reasonable. map-dhcp does =
extend DHCPv6 with new options for IPv4 configuration. Further more, if =
there are needs to support other IPv4 configuration information using =
purely DHCPv6, the new mechanisms should be used together with map-dhcp, =
or update map-dhcp. Because map-dhcp is the base for configuring IPv4 =
using purely DHCPv6.


>=20
>>> If you have it in the "approaches" list at all:
>>> 2. Depend on the setup of data-link (softwire) to offer enough =
information to create IPv4 addressing.
>>>    Require no other IPv4 configuration information.
>>>=20
>>> ** Reading section 1.3. If you want this approach to be "copy =
relevant DHCPv4 options into DHCPv6",
>>> then I suggest removing all references to MAP-DHCP.
>>>=20
>> [ian] See above.
>>=20
>>> Rename 3. to "stateless DHCPv4" or DHCPINFORM only.
>>>=20
>> [ian] You mean the approach that's currently called DHCPv6+DHCPv4oSW =
(horrible name:-)? If so, are you proposing 'DHCPv6+stateless DHCPv4 =
over SW' as the new name? I not sure that's much better...
>=20
> we don't call DHCPv4, "DHCPv4 over Ethernet" today.
> "stateless DHCPv4" is most likely the only option available on =
link-layers which have IPv4 address configuration built in.
[Qi] Could you please explain what 'stateless DHCPv4' is? Is this a term =
that I missed? Thanks!

>=20
>>> Section 2:
>>> Drop requirement 6, I can't see how you can evaluate that.
>>=20
>> [ian] You can evaluate it on the following basis: If the requirements =
that are described in this document are not your requirements as an =
operator, then you shouldn't be forced to use whatever the conclusion of =
this document is. In practical terms, I see this as 'if MAP DHCP meets =
your requirements, you don't need to bring in DHCPv4 over Foo or =
whatever else'.
>=20
> I didn't quite understand the implications of that.
>=20
>>> 8 is empty
>>>=20
>> [ian] Will fix.
>>=20
>>> I suggest you add a new requirement:
>>> x. Fate sharing. The provisioning of IPv4 addressing and other =
configuration information should be logically tied
>>>    to the data-link layer that is uses to provide IPv4 connectivity.
>>=20
>> [ian] This one's going to be more of a problem, as it pretty much =
directly conflicts with requirement 7, in that the two contradict each =
other. You can only implement data link fate sharing if you've got a hub =
and spoke architecture to locate the hub in (so that if it's not =
available, then IPv4 provisioning also fails)
>=20
> which link-layer fails that?
> I'm dubious about requirement 7 overall. and e.g. DHCPv4 over DHCPv6 =
is restricted to there being a DHCPv6 transport available.
>=20
>> In the case of a pure mesh network, with no hub and spoke, how could =
you have fate sharing for the data-link layer? The proposed requirement =
pre-supposes a specific underlying architecture.=20
>=20
> is this the equivalent to the dentist's office case? can you give an =
example of other data link-layers where IPv4 can be provisioned on a =
NBMA link, without a router?
>=20
>> Can we put this one to the workgroup to ask if this should be =
included as a new req, as it' has not been previously discussed?
>>=20
>>>=20
>>> Section 3:
>>> DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing.
>>=20
>> [ian] Why is it a 'no' for req 4? Section 8 of the DHCPv4 over DHCPv6 =
draft:
>>=20
>> Additionally, the DHCPv6 relay agent MAY allow the configuration of
>>  dedicated DHCPv4 over DHCPv6 specific destination addresses,
>>  differing from the addresses of the DHCPv6 only server(s).  To
>>  implement this function, the relay checks the received DHCPv6 =
message
>>  type and forwards according to the following logic:
>>=20
>>  1.  If the message type is BOOTREQUESTV6, then the DHCPv6 request is
>>      relayed to the configured DHCPv4 aware 4o6 Server's address(es).
>>=20
>>  2.  For any other DHCPv6 message type, forward according to section
>>      20 of [RFC3315].
>=20
> DHCPv4 over DHCPv6 requires support for transporting DHCPv4 messages =
in DHCPv6 servers and clients.
> what do you mean by "independent DHCPv4 and DHCPv6 servers" then?

[Qi] IMHO, the intended meaning here is: the process of DHCPv4 and =
DHCPv6 are independent in DHCPv4-over-DHCPv6.=20
Besides what Ian has quoted, DHCPv4 over DHCPv6 support the client to =
communicate with a dedicated 4o6 Server for IPv4 configuration =
information (with the help of 4o6 Servers Addresses Option).

> could you clarify the requirements?
> now they do read like they have been reverse engineered.
>=20
>> For the fate sharing req, as stated above.
>>=20
>>>=20
>>> In the evaluation in section 3.x I suggest dropping the use of =
"complex" and "simple".
>>> That appears very subjective.
>>>=20
>> [ian] OK
>>=20
>>> 3.4.2 bullet 3. applies to all approaches allowing DHCPv4 leases.
>>=20
>> [ian] How so? If you have a 'wrapper' type of approach (where DHCPv4 =
is being put into IPv6 or DHCPv6), then the DHCPv4 over xv6 client =
function can be agnostic to what the physical interface is beyond 'it =
must support multicast or unicast'. If the DHCPv4oSW mechanism is not =
linked just to softwires and is essentially a 'vanilla' DHCPv4 client, =
then it must have awareness of the link layer capabilities of the link =
on which it is running and potentially adapt it's behaviour accordingly, =
such as per-client l4 port-restrictions.
>=20
> I read this bullet to be about the interface to be _provisioned_. =
regardless of how that information reaches the client, the client must =
be aware of the link-layer restrictions. and that I believe apply to all =
mechanisms, regardless.
>=20
>>=20
>>>        bullet 4. please expand.
>>=20
>> [ian] This was from a question I asked on the ML some time ago, but =
wasn't answered. Does MAP-T support broadcasts through the translator =
function?
>=20
> I don't see why it wouldn't.
>=20
>>>        bullet 5. change to "Restricted to a broadcast capable =
link-layer."
>>=20
>> [ian] Is the hub-and-spoke restriction incorrect? As mentioned above, =
I don't see how this approach can work in a mesh environment. The =
'broadcast capable' restriction is not correct as if a h&s softwire can =
support broadcast, then a ptp mesh softwire can as well. You could =
broadcast DHCPDISCOVERs to peers in a mesh group, but it's not going to =
get you any response.
>=20
> MAP in mesh mode, still has a point to point tunnel to the BR.
> we have not described MAP in a 'pure' mesh mode, i.e. without a BR.
>=20
>>> 3.5.1 bullet 3. DHCPv4 and DHCPv6 cannot really be separated from =
each other since it=20
>>>        it is DHCPv6 that provides transport for DHCPv4. and support =
for the new BOOTP messages
>>>        are required in DHCPv6.
>>=20
>> [ian] But a dedicated DHCPv4 over DHCPv6 server could be deployed =
separate from the DHCPv6 only server. What about changing to read?:
>>=20
>> 'DHCPv4 and DHCPv6 based provisioning infrastructure can be =
seperated'
>=20
> as long as there is a DHCPv4 message capable DHCPv6 server.
>=20
>>> Minor comments:
>>> Introduction:
>>> "A general trend here is to relocate NAT44 functionality and IPv4
>>> address sharing from the centralized tunnel concentrator to the CPE
>>> in order to achieve better scalability. "
>>>=20
>>> I understand what you are trying to say, but unless the reader =
understands that the starting point
>>> are mechanisms like NAT444 and DS-lite, he would find this strange. =
As current deployments
>>> of IPv4 already use distributed NAT.
>>=20
>> [ian] What about changing the wording to:
>>=20
>> 'A general trend here is to relocate the translation of privately =
addressed IPv4 traffic to a shared, public external address from the =
centralized tunnel concentrator to the CPE. The distribution of this =
function allows for better scalability.'
>=20
> that reads better, but I don't agree with the statement that this is a =
general trend.
> the trend as I see it from current deployments are centralised NAT. =
that happens in mobile, with NAT444 and with DS-lite.

[Qi] IMHO, Ian's new wording is precise enough. The centralized NAT has =
the problem of scalability which is known to all. So the trend _is_ to =
relocate the NAT function to CPE.

Best Regards,
Qi

>=20
> couldn't you say something along the lines of "In todays residential =
networks, each residential user gets a single global IPv4 address. =
Continuing that model of a decentralised NAT, provides excellent scaling =
properties and combined with stateless functions in the network, simple =
redundancy and logging." modify as you please.
>=20
> cheers,
> Ole
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg


From Ted.Lemon@nominum.com  Wed Oct 23 11:00:57 2013
Return-Path: 
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 8024521F9C53 for ; Wed, 23 Oct 2013 11:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.588
X-Spam-Level: 
X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 h4IlKE6Ht3Vu for ; Wed, 23 Oct 2013 11:00:50 -0700 (PDT)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1729211E81F7 for ; Wed, 23 Oct 2013 11:00:47 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUmgOz489jJNIKt60G8eRq07pV09Y4LSi@postini.com; Wed, 23 Oct 2013 11:00:47 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D15191B82C9 for ; Wed, 23 Oct 2013 11:00:46 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B6974190043; Wed, 23 Oct 2013 11:00:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Wed, 23 Oct 2013 11:00:41 -0700
From: Ted Lemon 
To: Qi Sun 
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
Thread-Index: AQHOveV9LdCzDkpH2UaCUq+BUQ8x75neyEgAgAq37ICAAvvOgIAU/z8AgAFuBwCAAEPYgA==
Date: Wed, 23 Oct 2013 18:00:41 +0000
Message-ID: <84AB4B8F-8F42-4BC7-A80E-BB42AFE8AE20@nominum.com>
References: <20130930140054.31558.95411.idtracker@ietfa.amsl.com> <6A05E003-42A2-4659-9F23-6F5DFC6A88EF@gmx.com> <2C4C5302-C2CA-4F85-B053-78D317FD7964@employees.org> <3A7ED0DA-EE87-496C-AC7D-C4D3D937FB84@gmx.com> <73774E7F-38E3-4F41-822C-093444CA99B1@employees.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Oct 2013 18:00:57 -0000

On Oct 23, 2013, at 9:57 AM, Qi Sun  wrote:
> [Qi] Why static IPv4 address and port-set assignment is 'the most basic c=
ase of IPv4 provisioning'? For DHCPv4 (_Dynamic_ Host Configuration Protoco=
l), dynamic assignment of IPv4 is the 'most basic case', IMO.

I think it's really important not to find controversy where none exists.   =
My understanding is that what Ole is saying here is simply that in cases wh=
ere no dynamic allocation or extra IPv4 service configuration is needed, DH=
CPv4 is not needed.   AFAIK that's the consensus expressed by the working g=
roup.   Am I missing something here?


From phdgang@gmail.com  Wed Oct 23 22:03:50 2013
Return-Path: 
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 19B1811E82C4 for ; Wed, 23 Oct 2013 22:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 X6-WnQlLPRQ6 for ; Wed, 23 Oct 2013 22:03:49 -0700 (PDT)
Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EA75211E82BC for ; Wed, 23 Oct 2013 22:03:48 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id k15so4816880qaq.13 for ; Wed, 23 Oct 2013 22:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/IuMOKxJuRMujrfIn6zEKRZkmLuwJX7nWgqnDbcCU1Y=; b=sxYtwYstIq46te0qvc/yI/pAaMRjso661s+Zxg22ZFX5KDX+LCwJGIPi5xM3Vj5gAr IsucCfJx4b7yyNCb1dCyCHupvLGEPbTrxjPU+Vu4uxNJuFBU6qUQ6BPkt42ltLuHuZQU VLW52kUxMwXvZMcXpPYqnXAAfbCoD6qgm8KpW53Ky0jD8kj0oq6RNYe1Lq0c2mNBbjPB 9ZWiPwkOZjJC4YOl9xk856lsxa2v12hwBov2Rk6+ioehEyVNUJz8KpjYteEmlr1+tGqo H7cmy1fHXCKUMxh2oPDRQ0GG25oDiwmcyvxmJ1ZDCSpEQNISy+0esjFh4oZqglPRNebd eSrw==
MIME-Version: 1.0
X-Received: by 10.49.5.231 with SMTP id v7mr997660qev.58.1382591028239; Wed, 23 Oct 2013 22:03:48 -0700 (PDT)
Received: by 10.224.204.4 with HTTP; Wed, 23 Oct 2013 22:03:48 -0700 (PDT)
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD20B47@xmb-rcd-x04.cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E1AD20B47@xmb-rcd-x04.cisco.com>
Date: Thu, 24 Oct 2013 13:03:48 +0800
Message-ID: 
From: GangChen 
To: "Bernie Volz (volz)" , "dhcwg@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [dhcwg] WG Adoption Call - draft-jiang-dhc-sedhcpv6-02 - Ends November 11, 2013
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 05:03:50 -0000

wg,

I support to adopt the draft-jiang-dhc-sedhcpv6-02 as the wg draft

BRs

Gang

2013/10/17, Bernie Volz (volz) :
> Hi all:
>
>
>
> The author has requested a call for adoption by the WG for
> draft-jiang-dhc-sedhcpv6-02. (This document "replaces"
> http://tools.ietf.org/html/draft-ietf-dhc-secure-dhcpv6-07 as that document
> went to the IESG - see
> https://datatracker.ietf.org/doc/draft-ietf-dhc-secure-dhcpv6/ for more
> details. The new document is very different so please read it.)
>
>
>
> This call is being initiated to confirm whether there is WG consensus to
> adopt this work as DHC WG draft. Please state whether or not you're in favor
> of the adoption by replying to this mail. If you are not in favor, please
> also state your objections in your response. This adoption call will
> complete on November 11, 2013 - after the IETF meeting as it will likely be
> on the DHC WG agenda.
>
>
>
> The HTML version of the document can be viewed at
> http://tools.ietf.org/html/draft-jiang-dhc-sedhcpv6.
>
>
>
> Regards,
>
> Tomek & Bernie
>
>

From sunqi.csnet.thu@gmail.com  Wed Oct 23 22:19:20 2013
Return-Path: 
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 DFE6211E8103 for ; Wed, 23 Oct 2013 22:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.415
X-Spam-Level: 
X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184,  BAYES_00=-2.599]
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 sIbkqT1zwPmO for ; Wed, 23 Oct 2013 22:19:20 -0700 (PDT)
Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9D81711E82C7 for ; Wed, 23 Oct 2013 22:19:17 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id up7so1650730pbc.26 for ; Wed, 23 Oct 2013 22:19:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WryuXb47swz5THLQEN0Awc13fuI378xE4Nf4k/A0EmU=; b=FKnOX3HmPYEQb+mAhNq8E25mAYJh7RMdQ633vIX5e5mmwLEOfFvhPoObETN40MaYup aI8tmjlgA+GYkVEySSwX/IO7Aj6+iHFc/TX5O4+pNvgPtXV9m8akn224hQHUDA3SC/3B nBA3FzIqhWEmqUfFEILSNhvQz23AfMVGlZ0CCWet/11CRqbnhjX2HaAXuinBHYBNaUs5 dd9P5XR0rhx58R29NWeYFccN3sSNmP1JnjwuC/bwjDxy5xKTUf3UGOx4FHOV9CGwXB7z pfTYQ9J7tJrRGraCku8KP3gHuLzVRAlDvO5Ur+receM37NXmYGV2dFAaxCg/h6Qqmxfh NjQw==
X-Received: by 10.68.244.2 with SMTP id xc2mr1052246pbc.58.1382591957221; Wed, 23 Oct 2013 22:19:17 -0700 (PDT)
Received: from [192.168.199.122] ([166.111.68.231]) by mx.google.com with ESMTPSA id er3sm8488104pbb.40.2013.10.23.22.19.15 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 22:19:16 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=utf-8
From: Qi Sun 
In-Reply-To: <84AB4B8F-8F42-4BC7-A80E-BB42AFE8AE20@nominum.com>
Date: Thu, 24 Oct 2013 13:19:12 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C8013EA-7A15-4787-B4C0-A282CA02CE4A@gmail.com>
References: <20130930140054.31558.95411.idtracker@ietfa.amsl.com> <6A05E003-42A2-4659-9F23-6F5DFC6A88EF@gmx.com> <2C4C5302-C2CA-4F85-B053-78D317FD7964@employees.org> <3A7ED0DA-EE87-496C-AC7D-C4D3D937FB84@gmx.com> <73774E7F-38E3-4F41-822C-093444CA99B1@employees.org>  <84AB4B8F-8F42-4BC7-A80E-BB42AFE8AE20@nominum.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1085)
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 05:19:21 -0000

Dear Ted,

Thanks for the explanation.=20


Best Regards,
Qi


On 2013-10-24, at =E4=B8=8A=E5=8D=882:00, Ted Lemon wrote:

> On Oct 23, 2013, at 9:57 AM, Qi Sun  wrote:
>> [Qi] Why static IPv4 address and port-set assignment is 'the most =
basic case of IPv4 provisioning'? For DHCPv4 (_Dynamic_ Host =
Configuration Protocol), dynamic assignment of IPv4 is the 'most basic =
case', IMO.
>=20
> I think it's really important not to find controversy where none =
exists.   My understanding is that what Ole is saying here is simply =
that in cases where no dynamic allocation or extra IPv4 service =
configuration is needed, DHCPv4 is not needed.   AFAIK that's the =
consensus expressed by the working group.   Am I missing something here?
>=20


From otroan@employees.org  Thu Oct 24 00:49:08 2013
Return-Path: 
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 3152C11E80F9 for ; Thu, 24 Oct 2013 00:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.349
X-Spam-Level: 
X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, 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 euAKa7i2Wg-o for ; Thu, 24 Oct 2013 00:49:02 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3E811E82E3 for ; Thu, 24 Oct 2013 00:48:58 -0700 (PDT)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAA7QaFKQ/khM/2dsb2JhbABZgwe/W4EaFnSCJQEBBAF5EAtGVwaIEwa7IY9OB4MfgQsDkC2ZY4MmOg
X-IronPort-AV: E=Sophos;i="4.93,560,1378857600";  d="asc'?scan'208";a="18974859"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 24 Oct 2013 07:48:56 +0000
Received: from dhcp-lys01-vla250-10-147-112-183.cisco.com (dhcp-lys01-vla250-10-147-112-183.cisco.com [10.147.112.183]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9O7msHf022498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Oct 2013 07:48:54 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_7014417C-F1DD-4260-AE44-5AE05D88127E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Ole Troan 
In-Reply-To: 
Date: Thu, 24 Oct 2013 09:48:54 +0200
Message-Id: <5308F91F-24D8-44B3-B374-80C8EA5C1693@employees.org>
References: <20130930140054.31558.95411.idtracker@ietfa.amsl.com> <6A05E003-42A2-4659-9F23-6F5DFC6A88EF@gmx.com> <2C4C5302-C2CA-4F85-B053-78D317FD7964@employees.org> <3A7ED0DA-EE87-496C-AC7D-C4D3D937FB84@gmx.com> <73774E7F-38E3-4F41-822C-093444CA99B1@employees.org> 
To: Qi Sun 
X-Mailer: Apple Mail (2.1816)
Cc: "dhcwg@ietf.org" 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 07:49:08 -0000

--Apple-Mail=_7014417C-F1DD-4260-AE44-5AE05D88127E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Qi,

answering mainly your questions of clarification below.

[...]

>> yes, I think a clarification in the introduction would help.
>> stateful DHCPv4 doesn't apply to DS-lite, and it is difficult to see =
how it applies to MAP.
>> which link-layer did you have in mind for this?
>=20
> [Qi] What is the 'link-layer' you mentioned? Do you mean IPv6 can be =
seen as the 'link-layer' for IPv4 in the context of IPv4-over-IPv6 =
scenario? Sorry if I mis-understood you.

correct. a tunnel provides a data link-layer to the network layer =
protocol running over it.

[...]

>>>> Rename 3. to "stateless DHCPv4" or DHCPINFORM only.
>>>>=20
>>> [ian] You mean the approach that's currently called DHCPv6+DHCPv4oSW =
(horrible name:-)? If so, are you proposing 'DHCPv6+stateless DHCPv4 =
over SW' as the new name? I not sure that's much better...
>>=20
>> we don't call DHCPv4, "DHCPv4 over Ethernet" today.
>> "stateless DHCPv4" is most likely the only option available on =
link-layers which have IPv4 address configuration built in.
> [Qi] Could you please explain what 'stateless DHCPv4' is? Is this a =
term that I missed? Thanks!

when DHCPv4 is not used for address assignment, but only other =
configuration information.
as in DHCPINFORM. similar in function to RFC3736 for DHCPv6.

[...]

>> DHCPv4 over DHCPv6 requires support for transporting DHCPv4 messages =
in DHCPv6 servers and clients.
>> what do you mean by "independent DHCPv4 and DHCPv6 servers" then?
>=20
> [Qi] IMHO, the intended meaning here is: the process of DHCPv4 and =
DHCPv6 are independent in DHCPv4-over-DHCPv6.=20
> Besides what Ian has quoted, DHCPv4 over DHCPv6 support the client to =
communicate with a dedicated 4o6 Server for IPv4 configuration =
information (with the help of 4o6 Servers Addresses Option).

I see. perhaps make that clearer? that a DHCPv6 server has to be =
extended to support transport of DHCPv4 messages.
but all processing of them, including leases etc is done by the existing =
DHCPv4 server.

[...]

>>> 'A general trend here is to relocate the translation of privately =
addressed IPv4 traffic to a shared, public external address from the =
centralized tunnel concentrator to the CPE. The distribution of this =
function allows for better scalability.'
>>=20
>> that reads better, but I don't agree with the statement that this is =
a general trend.
>> the trend as I see it from current deployments are centralised NAT. =
that happens in mobile, with NAT444 and with DS-lite.
>=20
> [Qi] IMHO, Ian's new wording is precise enough. The centralized NAT =
has the problem of scalability which is known to all. So the trend _is_ =
to relocate the NAT function to CPE.

trend - a general direction in which something is developing or =
changing.
do you mean there is a 'trend' in standardisation? a trend in =
deployment? if so can you show data indicating that?
I'm sure there is someone on the list than can show trends in the sale =
of CGNs, so that we can compare.

cheers,
Ole

--Apple-Mail=_7014417C-F1DD-4260-AE44-5AE05D88127E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSaNDmAAoJEFuJXizso86g2GkIAJDZwdz41/x982iEeBr177aj
k7X0gRUhdsJk27nbc1YgNrtC3AYNTPWKztUD4v6L05KhKhnJjD1b5jJA9h/fv1Ch
NNvYVsWrNUS3fRGCnpf+He5BuHG34zuAHN++tLsBgqkGiztHUh8tWIn0SbIAzslS
E/njFbWoAwTnjYQ9o95pe9VadEmBMqMW0E56JWoF55TH76n7kpYvuVnUT6bGY8Qn
gKO6krH5nSLI+azEwEmbElJeNO4qiUXDSUs79k1o18b3A9q2Z0U2CTxS6HstZgB+
yULzA8MviDCJJD8bTw6phf9NepBI8HE4rYb9ReKT45AdLLVbTgJxR82bpLv2jCY=
=J9lc
-----END PGP SIGNATURE-----

--Apple-Mail=_7014417C-F1DD-4260-AE44-5AE05D88127E--

From Ted.Lemon@nominum.com  Fri Oct 25 04:04:12 2013
Return-Path: 
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 C88FC11E8387; Fri, 25 Oct 2013 04:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.589
X-Spam-Level: 
X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 LYIUFag65hW0; Fri, 25 Oct 2013 04:04:06 -0700 (PDT)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id F0C8D11E80F8; Fri, 25 Oct 2013 04:04:05 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUmpQJS6+MqwzC2Em+A70QsW7IQH5eByP@postini.com; Fri, 25 Oct 2013 04:04:06 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 70A7AF800A; Fri, 25 Oct 2013 04:04:05 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 503EA190060; Fri, 25 Oct 2013 04:04:05 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 04:04:05 -0700
From: Ted Lemon 
To: Cullen Jennings 
Thread-Topic: Last Call:  (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
Thread-Index: AQHOxG6vvYfRrCcaWUK4N3Cm629TPZns9HaA///CyYCAAGBrgP//wqiAgACIuQD///LeAAANvZ8AAAxP5AACbNgWAAAB/XiAAHuzzQAACrXQAA==
Date: Fri, 25 Oct 2013 11:04:05 +0000
Message-ID: 
References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com>    <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com>   <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com>  <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com>  <44771FA3-5660-45CB-AE84-3458C7DA4D87@nominum.com> <63557975-9AE8-4C5C-A120-9E3C7E5C84A1@iii.ca>
In-Reply-To: <63557975-9AE8-4C5C-A120-9E3C7E5C84A1@iii.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <9C122D80633319488AB4EEC497A016FC@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org WG" , "ietf@ietf.org Discuss" , The IESG 
Subject: Re: [dhcwg] Last Call:  (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 11:04:12 -0000

On Oct 25, 2013, at 1:57 AM, Cullen Jennings  wrote:
> Ted, as an IESG member, are you really sticking to a that the meaning of =
a BCP?

Working groups are where IETF consensus comes from.   The IETF mailing list=
 review is there to see if the IETF disagrees with the working group consen=
sus.   I'm trying to explain to you, the only (late) dissenter in the IETF =
last call, why I think the IETF should have consensus to publish the DHC wo=
rking group's advice about how to implement DHCP options as a BCP.   I'm do=
ing this because I think that it is the right thing.   If you think it's th=
e wrong thing, at least do me the courtesy of walking me through your reaso=
ning.

Can you make a clear argument for why some RAI working group, and not the D=
HC working group, should be the one to offer advice on how to do DHCP optio=
ns?   Would you, for example, want sipping to be where advice on how to do =
new DNS RRtypes comes from?


From barryleiba@gmail.com  Fri Oct 25 08:36:24 2013
Return-Path: 
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 C589011E818E; Fri, 25 Oct 2013 08:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.968
X-Spam-Level: 
X-Spam-Status: No, score=-101.968 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 e3+eBinE4ioS; Fri, 25 Oct 2013 08:36:23 -0700 (PDT)
Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D6F6D11E819B; Fri, 25 Oct 2013 08:36:14 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id x12so2318891qcv.0 for ; Fri, 25 Oct 2013 08:36:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gfT44Qn0ZTBcExal0hG8XrNz/AXNcqEOROLxsWbPN5M=; b=rqMx21OMCADixCWo9ccjQgzEpE1L/sw5dD0ocMI+Ma5uuwaN6Bosa554n4fGTBIB1n C1GZeK4GAgAYB79W6Av0RwNs0i5PwCquk6PHzQ6wVPU4T5mgze0VA3NwUyV9wEBHe6xS GXOulRrZAOD0jSiUOxmm9H0E3jh3QxQAY+Fb5FKuM3QL7nVYAf30Zv9b+Abm455LoLai cqXLbPeCWc4XEwcrRVCVVgKSrvLfNbIt3C/dCeOOiEMVQuAA+K626C4M0dggAPRrk1+Q YDYhQPZ+/Ed3K7jph8eq4UiDEAa5NVfGdT1vu+ZMJaJyuhr2+zPAd8kHQUWgOLXsNa0d /fBg==
MIME-Version: 1.0
X-Received: by 10.49.127.179 with SMTP id nh19mr11360766qeb.1.1382715370622; Fri, 25 Oct 2013 08:36:10 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.67.130 with HTTP; Fri, 25 Oct 2013 08:36:10 -0700 (PDT)
In-Reply-To: 
References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com>    <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com>   <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com>  <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com>  <44771FA3-5660-45CB-AE84-3458C7DA4D87@nominum.com> <63557975-9AE8-4C5C-A120-9E3C7E5C84A1@iii.ca> 
Date: Fri, 25 Oct 2013 11:36:10 -0400
X-Google-Sender-Auth: 1H6CfcFaLkFVXmJAmMwkEjICD3g
Message-ID: 
From: Barry Leiba 
To: Ted Lemon 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "dhcwg@ietf.org WG" , "ietf@ietf.org Discuss" , Cullen Jennings , The IESG 
Subject: Re: [dhcwg] Last Call:  (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 15:36:24 -0000

>> Ted, as an IESG member, are you really sticking to a that the meaning of a BCP?
>
> Working groups are where IETF consensus comes from.   The IETF mailing
> list review is there to see if the IETF disagrees with the working
> group consensus.   I'm trying to explain to you, the only (late)
> dissenter in the IETF last call, why I think the IETF should have
> consensus to publish the DHC working group's advice about how to
> implement DHCP options as a BCP.   I'm doing this because I think that
> it is the right thing.   If you think it's the wrong thing, at least
> do me the courtesy of walking me through your reasoning.
>
> Can you make a clear argument for why some RAI working group, and not
> the DHC working group, should be the one to offer advice on how to do
> DHCP options?   Would you, for example, want sipping to be where
> advice on how to do new DNS RRtypes comes from?

Really, now, this is over the top.

First, BCPs have IETF consensus, and are applicable across the IETF.
When you said that "RAI working groups are free to go against these
recommendations," you were completely wrong, and the IESG should and
would slap them down if they did.

Second, anyone who participates in the IETF can bring up issues, as
IETF consensus is built.  The output of working groups doesn't have
any magical force field protecting it from challenges from others.
The working group consensus means a lot, of course, but reasonable and
reasoned arguments still have to be addressed.

Third, your second paragraph above is really out of line.  So let's
back away a bit and look at the picture we're painting.

No one has tried to say that some other working group should be
telling people how to use DHCP.

What several of us have said, and what Cullen is saying, is that
various protocols (including some in the RAI area) are using DHCP to
get their configuration information.  Nothing theoretical: they ARE.
And that use has already been approved with IETF consensus.  So IF the
DHC working group means to say that such use by those protocols in
that way is ill advised, it needs to be explicitly clear about that,
and the issue needs to be discussed and have IETF consensus.
Otherwise, the document's recommendations need to be clarified to say
that this is legitimately done to configure application-layer
protocols, and different recommendations may apply to those.  Ideally,
it would give those recommendations as well.

So, one or the other:
- say "don't do that; it's bad, and here's why," *and get IETF
consensus on that*, or
- say "different recommendations apply in those situations, and here
are those recommendations," *and get IETF consensus on that*.

Barry

From sm@resistor.net  Fri Oct 25 10:33:41 2013
Return-Path: 
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 CCB0011E81B6; Fri, 25 Oct 2013 10:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level: 
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 t22FaPaCu1B2; Fri, 25 Oct 2013 10:33:39 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A11311E819F; Fri, 25 Oct 2013 10:33:39 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9PHXXJs012554; Fri, 25 Oct 2013 10:33:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1382722418; bh=2Wkhy77LY9rFbF4koa1tfjCvm84er36cGWsVSMdZ21Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HCC076MAUgaNEBby5IPbFHhsJ6I6bYHEE86x4dJXdDKlZgK6di3K7hAxq6ge16lT1 oHRzM0CORbJvWKxfgsRod70QAVY+YP5XcDY/NHsrVnNKCLzmyRm4MuZtw9BiLq6WRW QRn4p9oPhWbjE6Ld52aZvloUYjQnRBWeguzQ7xZM=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1382722418; i=@resistor.net; bh=2Wkhy77LY9rFbF4koa1tfjCvm84er36cGWsVSMdZ21Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r7hE+4DTMs6bAG3SDzMfIUaYDgDl5KsEjEq4GTkS7AW80d0vHxWdCUUu4f5QKDisq hPSsqawtjHT/fpY3CrgC9Hg/1NB0Ncukqn0PF7MjU4vpjkQHFgVYEzfGXKeQjw2WCB H9Txnfyh8OsgIvnFDhxcKQymj2Bnmb2u8hToUR0g=
Message-Id: <6.2.5.6.2.20131025092401.0d13fed0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 25 Oct 2013 10:32:26 -0700
To: ietf@ietf.org
From: SM 
In-Reply-To: 
References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com>    <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com>   <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com>  <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com>  <44771FA3-5660-45CB-AE84-3458C7DA4D87@nominum.com> <63557975-9AE8-4C5C-A120-9E3C7E5C84A1@iii.ca>  
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Fri, 25 Oct 2013 10:59:34 -0700
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Last Call:  (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 17:33:41 -0000

Hello,

I took a quick look at draft-ietf-dhc-option-guidelines-14.  In Section 8:

   "FQDN imposes a number of additional failure modes and issues that
    should be dealt with:

    1.  The client must have a knowledge about available DNS servers.
        That typically means that option DNS_SERVERS is mandatory.  This
        should be mentioned in the draft that defines new option.  It is
        possible that the server will return FQDN option, but not the DNS
        Servers option.  There should be a brief discussion about it;

    2.  The DNS may not be reachable;

    3.  DNS may be available, but may not have appropriate information
        (e.g. no AAAA records for specified FQDN);"

The draft recommends using IP addresses unless there is a good reason 
to use an FQDN.  I understand that everything breaks when a FQDN 
cannot be resolved.  One of the principles which is not usually 
mentioned nowadays ia that "user applications should use names rather 
than addresses".  I'll comment quickly about the above points.

The client would have to perform DNS resolution (Item 1) for the 
system to work.  There are cases where one can get away with using IP 
addresses.

When the DNS is not reachable (Item 2) people complain.  One of the 
arguments for redundancy is that the network will keep working if a 
system fails.  A person would usually see that there is some DNS 
service which is reachable.

Item 3 is odd.  The person putting in the appropriate information 
would have to think about whether the network will support, for 
example, IPv6-only hosts.

In Section 9:

   "There is no such ambiguity in DHCPv6 (with the unfortunate exception
    of [RFC5908],which was published without following the advice provided
    during the DHC working group review, and contains many errors."

This sounds like a case of a working group doing work which is not 
part of its charter (see https://datatracker.ietf.org/wg/ntp/charter/ 
).  The approval message mentioned that "This document has received 
in-depth review from both the NTP and DHC working groups and has 
strong support for advancement". Anyway, the above text does not 
sound politically correct. :-)

Section 13 discusses about chartering requirements and advice for 
Responsible ADs.  I don't think that it belongs in a document about 
guidance to prospective DHCPv6 Option developers.

Section 22 provides advice about updating existing RFCs.  I don't 
think that it belongs in a document about DHCPv6 Option guidelines.

There is advice for authors of drafts in the Security Considerations 
section.  I'll assume that authors are a security risk. :-)

Regards,
-sm


From fluffy@iii.ca  Thu Oct 24 22:57:40 2013
Return-Path: 
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 3032911E82B1; Thu, 24 Oct 2013 22:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.624
X-Spam-Level: 
X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599]
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 wyxYlUOSpOgs; Thu, 24 Oct 2013 22:57:33 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4C64511E82B0; Thu, 24 Oct 2013 22:57:31 -0700 (PDT)
Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7CABF22E2C9; Fri, 25 Oct 2013 01:57:24 -0400 (EDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Cullen Jennings 
In-Reply-To: <44771FA3-5660-45CB-AE84-3458C7DA4D87@nominum.com>
Date: Thu, 24 Oct 2013 23:57:22 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <63557975-9AE8-4C5C-A120-9E3C7E5C84A1@iii.ca>
References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com>    <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com>   <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com>  <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com>  <44771FA3-5660-45CB-AE84-3458C7DA4D87@nominum.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1510)
X-Mailman-Approved-At: Fri, 25 Oct 2013 10:59:34 -0700
Cc: dhcwg@ietf.org, "ietf@ietf.org Discuss" , The IESG 
Subject: Re: [dhcwg] Last Call:  (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 05:57:40 -0000

On Oct 22, 2013, at 12:55 PM, Ted Lemon  wrote:

> (c) This document is saying what the DHC working group recommends.   =
RAI working groups are free to go against these recommendations.   So =
this document shouldn't say what RAI recommends.   It should say what =
DHC recommends.   If a working group doesn't want to follow the advice, =
they don't have to, because it's just advice, not a requirement.

Ted, as an IESG member, are you really sticking to a that the meaning of =
a BCP?



From tomasz.mrugalski@gmail.com  Mon Oct 28 08:30:52 2013
Return-Path: 
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 06A9011E814C for ; Mon, 28 Oct 2013 08:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 j9o+0dl2Bsr6 for ; Mon, 28 Oct 2013 08:30:51 -0700 (PDT)
Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id E772711E8185 for ; Mon, 28 Oct 2013 08:30:47 -0700 (PDT)
Received: by mail-ea0-f178.google.com with SMTP id a15so2262133eae.23 for ; Mon, 28 Oct 2013 08:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=LabZd1/RAY5QtXxi8Wl7UXsWMMdwwZscgxQv8+z58h4=; b=kdPGfD4BRhOeA7KWYdH4mBWH68GsHu1ZrvXQ6inFJxge7NzVD8GW70A8jGXvqCyz2v 8IqWMaV69RAlazLUubYro43Hzp5Z3kU5t356NfI3E6xNBzkQoo4kvZed/et0n9Cj537c loxZU529q6LOlAlYptGKQNO4C7RwM01ghBPBEQ3pOkHX6Au4H9XDbQZW0hCs+z7yNf7H GNg4muC95nD35M4iq1lvUN0+jiAjcsrE2W30pM3lM2zLIrtKXKSG7zQAQ1SFqhswsr5a jy8iYxRHVJjpFK36b0me5zSc8LlQgkD5IamHcrSqkV9ar3val0JPDV0aVCHF8gPzfRpa U1+A==
X-Received: by 10.15.33.198 with SMTP id c46mr228032eev.115.1382974246967; Mon, 28 Oct 2013 08:30:46 -0700 (PDT)
Received: from ?IPv6:2001:470:6061:0:f66d:4ff:fe96:58f2? ([2001:470:6061:0:f66d:4ff:fe96:58f2]) by mx.google.com with ESMTPSA id x47sm58508876eea.16.2013.10.28.08.30.44 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Oct 2013 08:30:46 -0700 (PDT)
Message-ID: <526E8323.7030701@gmail.com>
Date: Mon, 28 Oct 2013 16:30:43 +0100
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: dhcwg 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Vancouver meeting preparation: scribe & note taker wanted
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Oct 2013 15:30:52 -0000

We're looking for two volunteers: a Jabber scribe and a note taker. We
will go with etherpad as we did last time with minutes, so everyone will
be able to contribute or correct, but there should be one leading person
taking the notes. Please volunteer. This is much appreciated.

As a reminder, we would like to ask presenters to send their slides a
bit earlier than usual. Please send your slides by Friday (Nov. 1st).
Make sure you have slide numbers on your slide deck.

Thanks a lot and hope to see you all in Vancouver,
Bernie and Tomek


From ian.farrer@telekom.de  Tue Oct 29 06:44:07 2013
Return-Path: 
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 473BE11E823D for ; Tue, 29 Oct 2013 06:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level: 
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1]
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 qTL6CszuwYMx for ; Tue, 29 Oct 2013 06:44:02 -0700 (PDT)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7151211E815F for ; Tue, 29 Oct 2013 06:44:01 -0700 (PDT)
Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 29 Oct 2013 14:43:59 +0100
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.39]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 29 Oct 2013 14:43:59 +0100
From: 
To: 
Date: Tue, 29 Oct 2013 14:43:53 +0100
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
Thread-Index: Ac7UrOwipq5L1w9BRw2fnEJuQyKLNQ==
Message-ID: 
In-Reply-To: <73774E7F-38E3-4F41-822C-093444CA99B1@employees.org>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Oct 2013 13:44:07 -0000

Hi Ole,


Thanks for the review. I=B9ve updated the draft based on your comments. And
some more answers in line.

Cheers,
Ian


>
>yes, I think a clarification in the introduction would help.
>stateful DHCPv4 doesn't apply to DS-lite, and it is difficult to see how
>it applies to MAP.
>which link-layer did you have in mind for this?
>is this work meant to also provide stateful DHCPv4 for MAP tunnels?

[ian] It=B9s not meant to be limited to any particular softwire or other v4
type. If someone was to have a reason for using stateful DHCPv4 for MAP at
some point in the future, then this IPv4 configuration

>
>e.g. a configured RFC2473 tunnel or Public 4over6, could work.
>
>when it comes to provisioning of a shared IPv4 address, DHCPv4 doesn't
>really do that.
>I don't see that described in this document?

[ian] The draft=B9s concerned with how IPv4 configuration is transported,
not what the specific v4 configuration is.

>I think we need to evaluate if there should be a completely new option
>for IPv4 address and port set, or
>a the classic IPv4 address option combined with a new port set option.

[ian] There=B9s a couple of drafts out there that do this at the moment:
draft-sun-dhc-port-set-option & draft-farrer-dhc-shared-address-lease. I
think that it=B9s better to handle the format and other considerations
around option formats and shared address leasing separate from the
transport question covered in this draft.

>
>>> Section 2:
>>> Drop requirement 6, I can't see how you can evaluate that.
>>=20
>> [ian] You can evaluate it on the following basis: If the requirements
>>that are described in this document are not your requirements as an
>>operator, then you shouldn't be forced to use whatever the conclusion of
>>this document is. In practical terms, I see this as 'if MAP DHCP meets
>>your requirements, you don't need to bring in DHCPv4 over Foo or
>>whatever else'.
>
>I didn't quite understand the implications of that.

[ian] During the discussion in Atlanta that led up to writing this
document, an opinion voiced by several operators was: If I can provision
everything I need using simple, static DHCPv6 (I.e. Option map), why
should I have the additional overhead of a DHCPv4 providing additional
DHCPv4 options and dynamic leasing which is unnecessary to me?

The requirement is there to evaluate whether a solution allows you to do
that.

>
>>> 8 is empty
>>>=20
>> [ian] Will fix.
>>=20
>>> I suggest you add a new requirement:
>>> x. Fate sharing. The provisioning of IPv4 addressing and other
>>>configuration information should be logically tied
>>>     to the data-link layer that is uses to provide IPv4 connectivity.
>>=20
>> [ian] This one's going to be more of a problem, as it pretty much
>>directly conflicts with requirement 7, in that the two contradict each
>>other. You can only implement data link fate sharing if you've got a hub
>>and spoke architecture to locate the hub in (so that if it's not
>>available, then IPv4 provisioning also fails)
>
>which link-layer fails that?
>I'm dubious about requirement 7 overall. and e.g. DHCPv4 over DHCPv6 is
>restricted to there being a DHCPv6 transport available.

[ian] There=B9s a slot for this draft in Vancouver. Can we discuss it there
as this has a direct effect on the outcome?

>
>> In the case of a pure mesh network, with no hub and spoke, how could
>>you have fate sharing for the data-link layer? The proposed requirement
>>pre-supposes a specific underlying architecture.
>
>is this the equivalent to the dentist's office case? can you give an
>example of other data link-layers where IPv4 can be provisioned on a NBMA
>link, without a router?

[ian] Not familiar with the Dentist office in this particular context.

The obvious example would be a single Ethernet segment with a DHCP server
attached, but I=B9m not sure how that=B9s relevant to this discussion.

>
>> Can we put this one to the workgroup to ask if this should be included
>>as a new req, as it' has not been previously discussed?
>>=20
>>>=20
>>> Section 3:
>>> DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing.
>>=20
>> [ian] Why is it a 'no' for req 4? Section 8 of the DHCPv4 over DHCPv6
>>draft:
>>=20
>> Additionally, the DHCPv6 relay agent MAY allow the configuration of
>>   dedicated DHCPv4 over DHCPv6 specific destination addresses,
>>   differing from the addresses of the DHCPv6 only server(s).  To
>>   implement this function, the relay checks the received DHCPv6 message
>>   type and forwards according to the following logic:
>>=20
>>   1.  If the message type is BOOTREQUESTV6, then the DHCPv6 request is
>>       relayed to the configured DHCPv4 aware 4o6 Server's address(es).
>>=20
>>   2.  For any other DHCPv6 message type, forward according to section
>>       20 of [RFC3315].
>
>DHCPv4 over DHCPv6 requires support for transporting DHCPv4 messages in
>DHCPv6 servers and clients.

[ian] Or, you could add a minimal DHCPv6 encapsulation to a DHCPv4 server.

>what do you mean by "independent DHCPv4 and DHCPv6 servers" then?

[ian] if you wanted to deploy DHCPv6 servers and DHCPv4overDHCPv6 servers
as separate instances, you can. Given how complex the DHCPv6 server logic
can become, there=B9s some good reasons no to overload the DHCPv6 server
with DHCPv4 functions as well.

>could you clarify the requirements?
>now they do read like they have been reverse engineered.

[ian] Extended the definition with an explanation.

>
>> For the fate sharing req, as stated above.
>>=20
>>>=20
>>> In the evaluation in section 3.x I suggest dropping the use of
>>>"complex" and "simple".
>>> That appears very subjective.
>>>=20
>> [ian] OK
>>=20
>>> 3.4.2 bullet 3. applies to all approaches allowing DHCPv4 leases.
>>=20
>> [ian] How so? If you have a 'wrapper' type of approach (where DHCPv4 is
>>being put into IPv6 or DHCPv6), then the DHCPv4 over xv6 client function
>>can be agnostic to what the physical interface is beyond 'it must
>>support multicast or unicast'. If the DHCPv4oSW mechanism is not linked
>>just to softwires and is essentially a 'vanilla' DHCPv4 client, then it
>>must have awareness of the link layer capabilities of the link on which
>>it is running and potentially adapt it's behaviour accordingly, such as
>>per-client l4 port-restrictions.
>
>I read this bullet to be about the interface to be _provisioned_.
>regardless of how that information reaches the client, the client must be
>aware of the link-layer restrictions. and that I believe apply to all
>mechanisms, regardless.
>
>>=20
>>>         bullet 4. please expand.
>>=20
>> [ian] This was from a question I asked on the ML some time ago, but
>>wasn't answered. Does MAP-T support broadcasts through the translator
>>function?
>
>I don't see why it wouldn't.

[ian] OK, removed the con.

>
>>>         bullet 5. change to "Restricted to a broadcast capable
>>>link-layer."
>>=20
>> [ian] Is the hub-and-spoke restriction incorrect? As mentioned above, I
>>don't see how this approach can work in a mesh environment. The
>>'broadcast capable' restriction is not correct as if a h&s softwire can
>>support broadcast, then a ptp mesh softwire can as well. You could
>>broadcast DHCPDISCOVERs to peers in a mesh group, but it's not going to
>>get you any response.
>
>MAP in mesh mode, still has a point to point tunnel to the BR.
>we have not described MAP in a 'pure' mesh mode, i.e. without a BR.

[ian] This document isn=B9t meant to be limited to MAP mesh. E.g. RFC5565.

>
>>> 3.5.1 bullet 3. DHCPv4 and DHCPv6 cannot really be separated from each
>>>other since it=20
>>>         it is DHCPv6 that provides transport for DHCPv4. and support
>>>for the new BOOTP messages
>>>         are required in DHCPv6.
>>=20
>> [ian] But a dedicated DHCPv4 over DHCPv6 server could be deployed
>>separate from the DHCPv6 only server. What about changing to read?:
>>=20
>> 'DHCPv4 and DHCPv6 based provisioning infrastructure can be seperated'
>
>as long as there is a DHCPv4 message capable DHCPv6 server.

[ian] Sure. But if you didn=B9t have a DHCPv4 capable server, then you
wouldn=B9t have sent the DHCPv4pDHCPv6 client the option to tell it to
attempt DHCPv4oDHCPv6 configuration.

>


From otroan@employees.org  Wed Oct 30 05:58:03 2013
Return-Path: 
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 9A57311E81D6 for ; Wed, 30 Oct 2013 05:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.433
X-Spam-Level: 
X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, 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 jzaF5O6AXyaE for ; Wed, 30 Oct 2013 05:57:57 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id A219D11E8227 for ; Wed, 30 Oct 2013 05:57:44 -0700 (PDT)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAMABcVKQ/khN/2dsb2JhbABZgwfAWYEmFnSCJQEBBAF5BQsLEjRJDgYuh2YGun6OEIE/B4MfgQ0DkC2ZZoMnO4Es
X-IronPort-AV: E=Sophos;i="4.93,601,1378857600";  d="asc'?scan'208";a="19125708"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 30 Oct 2013 12:57:43 +0000
Received: from dhcp-lys01-vla250-10-147-113-158.cisco.com (dhcp-lys01-vla250-10-147-113-158.cisco.com [10.147.113.158]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9UCvd9k032242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Oct 2013 12:57:40 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_BF1B5561-2784-4BB8-BBB4-C104F275E569"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Ole Troan 
In-Reply-To: 
Date: Wed, 30 Oct 2013 13:57:39 +0100
Message-Id: <475F6A13-002D-481A-A73A-CDC36F9A0AD8@employees.org>
References: 
To: " Farrer" 
X-Mailer: Apple Mail (2.1816)
Cc: "dhcwg@ietf.org WG" 
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Oct 2013 12:58:03 -0000

--Apple-Mail=_BF1B5561-2784-4BB8-BBB4-C104F275E569
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi Ian,

> Thanks for the review. I=B9ve updated the draft based on your =
comments. And
> some more answers in line.

thanks, some more comments inline.

>> yes, I think a clarification in the introduction would help.
>> stateful DHCPv4 doesn't apply to DS-lite, and it is difficult to see =
how
>> it applies to MAP.
>> which link-layer did you have in mind for this?
>> is this work meant to also provide stateful DHCPv4 for MAP tunnels?
>=20
> [ian] It=B9s not meant to be limited to any particular softwire or =
other v4
> type. If someone was to have a reason for using stateful DHCPv4 for =
MAP at
> some point in the future, then this IPv4 configuration

the analogy to doing address assignment with DHCPv4 on a MAP tunnel,
would be to do DHCPv4 address assignment on top of IPCP for a PPP =
link-layer.
MAP already provides the IPv4 address, so I can't quite see how stateful =
DHCPv4
makes sense with MAP. can you explain?

>> e.g. a configured RFC2473 tunnel or Public 4over6, could work.
>>=20
>> when it comes to provisioning of a shared IPv4 address, DHCPv4 =
doesn't
>> really do that.
>> I don't see that described in this document?
>=20
> [ian] The draft=B9s concerned with how IPv4 configuration is =
transported,
> not what the specific v4 configuration is.

understood.

>> I think we need to evaluate if there should be a completely new =
option
>> for IPv4 address and port set, or
>> a the classic IPv4 address option combined with a new port set =
option.
>=20
> [ian] There=B9s a couple of drafts out there that do this at the =
moment:
> draft-sun-dhc-port-set-option & draft-farrer-dhc-shared-address-lease. =
I
> think that it=B9s better to handle the format and other considerations
> around option formats and shared address leasing separate from the
> transport question covered in this draft.

OK.

>>>> Section 2:
>>>> Drop requirement 6, I can't see how you can evaluate that.
>>>=20
>>> [ian] You can evaluate it on the following basis: If the =
requirements
>>> that are described in this document are not your requirements as an
>>> operator, then you shouldn't be forced to use whatever the =
conclusion of
>>> this document is. In practical terms, I see this as 'if MAP DHCP =
meets
>>> your requirements, you don't need to bring in DHCPv4 over Foo or
>>> whatever else'.
>>=20
>> I didn't quite understand the implications of that.
>=20
> [ian] During the discussion in Atlanta that led up to writing this
> document, an opinion voiced by several operators was: If I can =
provision
> everything I need using simple, static DHCPv6 (I.e. Option map), why
> should I have the additional overhead of a DHCPv4 providing additional
> DHCPv4 options and dynamic leasing which is unnecessary to me?
>=20
> The requirement is there to evaluate whether a solution allows you to =
do
> that.

OK, so the requirement is to not make DHCPv4 mandatory, for the cases
where the underlaying mechanism provides the required information.
isn't that a no-op? if you don't care about DHCPv4 then don't use it...?

>>>> 8 is empty
>>>>=20
>>> [ian] Will fix.
>>>=20
>>>> I suggest you add a new requirement:
>>>> x. Fate sharing. The provisioning of IPv4 addressing and other
>>>> configuration information should be logically tied
>>>>    to the data-link layer that is uses to provide IPv4 =
connectivity.
>>>=20
>>> [ian] This one's going to be more of a problem, as it pretty much
>>> directly conflicts with requirement 7, in that the two contradict =
each
>>> other. You can only implement data link fate sharing if you've got a =
hub
>>> and spoke architecture to locate the hub in (so that if it's not
>>> available, then IPv4 provisioning also fails)
>>=20
>> which link-layer fails that?
>> I'm dubious about requirement 7 overall. and e.g. DHCPv4 over DHCPv6 =
is
>> restricted to there being a DHCPv6 transport available.
>=20
> [ian] There=B9s a slot for this draft in Vancouver. Can we discuss it =
there
> as this has a direct effect on the outcome?

I'm not going to be there physically, but we're trying to do a remote =
participant experiment.

>>> In the case of a pure mesh network, with no hub and spoke, how could
>>> you have fate sharing for the data-link layer? The proposed =
requirement
>>> pre-supposes a specific underlying architecture.
>>=20
>> is this the equivalent to the dentist's office case? can you give an
>> example of other data link-layers where IPv4 can be provisioned on a =
NBMA
>> link, without a router?
>=20
> [ian] Not familiar with the Dentist office in this particular context.
>=20
> The obvious example would be a single Ethernet segment with a DHCP =
server
> attached, but I=B9m not sure how that=B9s relevant to this discussion.
>=20

indeed, I don't think we need to consider the mesh case without a BR for =
MAP.

>>> Can we put this one to the workgroup to ask if this should be =
included
>>> as a new req, as it' has not been previously discussed?
>>>=20
>>>>=20
>>>> Section 3:
>>>> DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing.
>>>=20
>>> [ian] Why is it a 'no' for req 4? Section 8 of the DHCPv4 over =
DHCPv6
>>> draft:
>>>=20
>>> Additionally, the DHCPv6 relay agent MAY allow the configuration of
>>>  dedicated DHCPv4 over DHCPv6 specific destination addresses,
>>>  differing from the addresses of the DHCPv6 only server(s).  To
>>>  implement this function, the relay checks the received DHCPv6 =
message
>>>  type and forwards according to the following logic:
>>>=20
>>>  1.  If the message type is BOOTREQUESTV6, then the DHCPv6 request =
is
>>>      relayed to the configured DHCPv4 aware 4o6 Server's =
address(es).
>>>=20
>>>  2.  For any other DHCPv6 message type, forward according to section
>>>      20 of [RFC3315].
>>=20
>> DHCPv4 over DHCPv6 requires support for transporting DHCPv4 messages =
in
>> DHCPv6 servers and clients.
>=20
> [ian] Or, you could add a minimal DHCPv6 encapsulation to a DHCPv4 =
server.

right, but then the DHCPv6 relay would have to support sending DHCPv6 =
messages
to multiple servers.

>> what do you mean by "independent DHCPv4 and DHCPv6 servers" then?
>=20
> [ian] if you wanted to deploy DHCPv6 servers and DHCPv4overDHCPv6 =
servers
> as separate instances, you can. Given how complex the DHCPv6 server =
logic
> can become, there=B9s some good reasons no to overload the DHCPv6 =
server
> with DHCPv4 functions as well.

absolutely. that applies even more to running DHCPv4 over the link-layer =
directly.

>=20
>> could you clarify the requirements?
>> now they do read like they have been reverse engineered.
>=20
> [ian] Extended the definition with an explanation.

ack.

[...]

>>>>        bullet 5. change to "Restricted to a broadcast capable
>>>> link-layer."
>>>=20
>>> [ian] Is the hub-and-spoke restriction incorrect? As mentioned =
above, I
>>> don't see how this approach can work in a mesh environment. The
>>> 'broadcast capable' restriction is not correct as if a h&s softwire =
can
>>> support broadcast, then a ptp mesh softwire can as well. You could
>>> broadcast DHCPDISCOVERs to peers in a mesh group, but it's not going =
to
>>> get you any response.
>>=20
>> MAP in mesh mode, still has a point to point tunnel to the BR.
>> we have not described MAP in a 'pure' mesh mode, i.e. without a BR.
>=20
> [ian] This document isn=B9t meant to be limited to MAP mesh. E.g. =
RFC5565.

yes, my point was that you don't need to create the corner case for MAP,
where there is no BR. we haven't described that anywhere, so don't use
that as a reason why MAP cannot provide a link-layer that you can run
DHCPv4 on top of.

>>>> 3.5.1 bullet 3. DHCPv4 and DHCPv6 cannot really be separated from =
each
>>>> other since it=20
>>>>        it is DHCPv6 that provides transport for DHCPv4. and support
>>>> for the new BOOTP messages
>>>>        are required in DHCPv6.
>>>=20
>>> [ian] But a dedicated DHCPv4 over DHCPv6 server could be deployed
>>> separate from the DHCPv6 only server. What about changing to read?:
>>>=20
>>> 'DHCPv4 and DHCPv6 based provisioning infrastructure can be =
seperated'
>>=20
>> as long as there is a DHCPv4 message capable DHCPv6 server.
>=20
> [ian] Sure. But if you didn=B9t have a DHCPv4 capable server, then you
> wouldn=B9t have sent the DHCPv4pDHCPv6 client the option to tell it to
> attempt DHCPv4oDHCPv6 configuration.

from an architectural point of view, I don't really like signalling in =
IPv6 how IPv4 should be provisioned
and vice versa. Mark Townsley and I have an expired draft showing the =
complex state machine
that results in. I'd much rather prefer ships in the night.

cheers,
Ole


--Apple-Mail=_BF1B5561-2784-4BB8-BBB4-C104F275E569
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJScQJDAAoJEFuJXizso86gHikH+wanv5ApfSvZvxrgClsOInUG
qQX9tsz4P8XdLrJhYT9qFteJ3BVUJZXH6vngZq8tA3+6eM1f62i6DBlxer8Npr/T
tFmEJXFBpXdRyMhEqzHcZS4wxTbKMZ0X024JpRTkCP/sQ/4bnKJVwrK27WKBU6vK
gtDKv5bYfhkF9c1elQ1ljjZZRqJDwiTOHMwH8h8oQ3fKhkHXhF9P82oE4vbJe5BX
jykZIC9KE7oAa1o4n6vCClqWppxDOeD1Li/cT4660DrH7IGK06JKaooe4zfl3vfE
/vrJ7OgWogVuWmoxvHKCXLlptb1OQ4uHueN5hzZVvmAyeLXBfvUEyWolszFIlUg=
=7eNU
-----END PGP SIGNATURE-----

--Apple-Mail=_BF1B5561-2784-4BB8-BBB4-C104F275E569--