From ietf@meetecho.com Thu Aug 2 11:04:44 2012 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 79CF911E81C7 for ; Thu, 2 Aug 2012 11:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.542 X-Spam-Level: X-Spam-Status: No, score=-0.542 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 97BnlkehS4+q for ; Thu, 2 Aug 2012 11:04:44 -0700 (PDT) Received: from smtplq03.aruba.it (smtplq-out5.aruba.it [62.149.158.25]) by ietfa.amsl.com (Postfix) with SMTP id 635E811E81BF for ; Thu, 2 Aug 2012 11:04:43 -0700 (PDT) Received: (qmail 21783 invoked by uid 89); 2 Aug 2012 18:04:41 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq03.aruba.it with SMTP; 2 Aug 2012 18:04:41 -0000 Received: (qmail 14456 invoked by uid 89); 2 Aug 2012 18:04:41 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp1.ad.aruba.it with ESMTPA; 2 Aug 2012 18:04:41 -0000 Message-ID: <501AC131.3090508@meetecho.com> Date: Thu, 02 Aug 2012 20:04:33 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Subject: [dhcwg] Meetecho session recording available 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, 02 Aug 2012 18:04:44 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of DHC session at IETF-84 is available. You can watch it by accessing the following URL: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_DHC For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From wwwrun@rfc-editor.org Thu Aug 2 12:02:15 2012 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 675B211E8270; Thu, 2 Aug 2012 12:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.992 X-Spam-Level: X-Spam-Status: No, score=-101.992 tagged_above=-999 required=5 tests=[AWL=0.008, 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 SKZ5gWRgbh5P; Thu, 2 Aug 2012 12:02:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C576411E826B; Thu, 2 Aug 2012 12:02:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D55F272E038; Thu, 2 Aug 2012 12:01:28 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120802190129.D55F272E038@rfc-editor.org> Date: Thu, 2 Aug 2012 12:01:28 -0700 (PDT) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6704 on Forcerenew Nonce Authentication 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, 02 Aug 2012 19:02:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6704 Title: Forcerenew Nonce Authentication Author: D. Miles, W. Dec, J. Bristow, R. Maglione Status: Standards Track Stream: IETF Date: August 2012 Mailbox: davidmiles@google.com, wdec@cisco.com, James.Bristow@swisscom.com, roberta.maglione@telecomitalia.it Pages: 12 Characters: 26538 Updates: RFC3203 I-D Tag: draft-ietf-dhc-forcerenew-nonce-07.txt URL: http://www.rfc-editor.org/rfc/rfc6704.txt Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In the Forcerenew Nonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. [STANDARDS-TRACK] This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. 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/rfcsearch.html. 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 alexandru.petrescu@gmail.com Thu Aug 2 13:37:02 2012 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 8A4BC21F8960 for ; Thu, 2 Aug 2012 13:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, 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 ZwKNwZEVwbFS for ; Thu, 2 Aug 2012 13:37:02 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E072421F894B for ; Thu, 2 Aug 2012 13:37:01 -0700 (PDT) Received: by yhq56 with SMTP id 56so9941247yhq.31 for ; Thu, 02 Aug 2012 13:37:01 -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=gx+/s+VshD/s4p6nvsYen6shgl0VI0ePmohMO8caH/w=; b=mT2aC7ygC1lc4Uk3d/dBwwEGcweWghx4/cr6WQN+Zdc369jxOtU4YEuBHOh7wz3jYb IcLLJrTJCHATPNWAOC3zCtjO2z7LMqdgiTvrGSDeAs9X/vkY/iorfW1dcVfAgg6+HFer yq2jNZb0G5ti86o4JKHkwooIuk3UPQb6eXn2xRUkpuU4FjKJgpSauWc5Cow1ZTI+xq8/ VXjOGhyWAtygzF3eZFcwPJsGXbglJDexaCuXWDXfRR3mnaeuKjKl4IfPTW3J2unSrCf5 PjhsJ6IDkIKWicKXMyyG7zHHq96pZstP39dKhRK1h2KoY3FzkzsFpitzyGpa7boM0yzr 1hcg== Received: by 10.60.19.232 with SMTP id i8mr39666421oee.35.1343939821407; Thu, 02 Aug 2012 13:37:01 -0700 (PDT) Received: from [130.129.19.61] (dhcp-133d.meeting.ietf.org. [130.129.19.61]) by mx.google.com with ESMTPS id hd10sm7044964obc.8.2012.08.02.13.37.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 13:37:00 -0700 (PDT) Message-ID: <501AE4E1.10100@gmail.com> Date: Thu, 02 Aug 2012 13:36:49 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "dhcwg@ietf.org" References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> In-Reply-To: <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dhcwg] [RTG-DIR] DHCPv6 Prefix Pool Option 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, 02 Aug 2012 20:37:02 -0000 Responding to this is on my todo list since MAastricht I believe - sorry for having missed other opportunities. On a DHCP Relay, there would be a need to set up a route relative to a delegated prefix. I need to better understand the context and then I will give more review of this document. Alex Le 02/08/2012 12:47, Acee Lindem a écrit : > Hi, I'm not sure what I was thinking this morning when I said that > the DHCP server should run a routing daemon and advertise the > aggregate route. Rather, the BRAS server that is maintaining > subscriber DHCP state should have a configured aggregation policy for > the DHCP prefix pool route. This problem has already been solved in > commercial BRAS servers and there is no need to add a generic route > advertisement mechanism to DHCP. Thanks, Acee > > On Aug 2, 2012, at 3:34 PM, Adrian Farrel wrote: > >> Hi, >> >> At the Routing Area meeting this morning, Ted raised some potential >> DHCP work that routing folk should look at. Comments ideally go to >> the DHC working group or back to Ted. >> >> Adrian >> >>> -----Original Message----- From: Ted Lemon >>> [mailto:Ted.Lemon@nominum.com] Sent: 02 August 2012 20:11 To: >>> adrian@olddog.co.uk Subject: DHCPv6 Prefix Pool Option >>> >>> Thanks for the time at the mic this morning. The document I >>> wanted you to comment on or solicit comment on is the DHCPv6 >>> Prefix Pool Option draft: >>> >>> http://tools.ietf.org/html/draft-yeh-dhc-dhcpv6-prefix-pool-opt >>> >>> There was a question at the mic about why the DHCP server >>> wouldn't inject the route itself, which I think is a good >>> question, and could be argued to be the >> right >>> thing to do. However, operationally there are a lot of missing >>> pieces to >> this-the >>> DHCP server now becomes, in addition to being a DHCP server, also >>> a publisher >> of >>> routes, and has to have information about the routing topology of >>> the ISP that >> I >>> think might be nontrivial to maintain. >>> >>> The advantage of the current approach, which is improved by this >>> new draft, is that it piggybacks on top of the existing >>> relationship between the relay agent >> and >>> the DHCP server, which is required for DHCP to work. The DHCP >>> server now does not have to know the topology of the network-it >>> sends the prefix aggregation information to the router, which >>> presumably already has that information, by way of the DHCP >>> relay, which is typically co-located in the >> router. >>> >>> So despite my protestations of innocence at the mic, I suppose I >>> do really >> think >>> it's a reasonable way to solve this particular problem. >> > > > > _______________________________________________ routing-discussion > mailing list routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > From leaf.y.yeh@huawei.com Sat Aug 4 06:18:45 2012 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 922B221F87BE for ; Sat, 4 Aug 2012 06:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.160, 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 nDfCv-gH1PmB for ; Sat, 4 Aug 2012 06:18:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 574D621F87AD for ; Sat, 4 Aug 2012 06:18:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AIX02946; Sat, 04 Aug 2012 05:18:43 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 4 Aug 2012 06:18:39 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 4 Aug 2012 06:18:36 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 4 Aug 2012 21:18:33 +0800 From: Leaf yeh To: Alexandru Petrescu , "dhcwg@ietf.org" Thread-Topic: [dhcwg] [RTG-DIR] DHCPv6 Prefix Pool Option Thread-Index: AQHNcO6eZ9B3mZM9706ftAS6ZRc3c5dJnkEggAAHKMs= Date: Sat, 4 Aug 2012 13:18:32 +0000 Message-ID: References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com>, <501AE4E1.10100@gmail.com> In-Reply-To: <501AE4E1.10100@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: multipart/alternative; boundary="_000_DED5BA56FEEA46028A079E4D32495402mimectl_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] [RTG-DIR] DHCPv6 Prefix Pool Option 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, 04 Aug 2012 13:18:45 -0000 --_000_DED5BA56FEEA46028A079E4D32495402mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alexandru - On a DHCP Relay, there would be a need to set up a route relati= ve to a delegated prefix. Definitely there should be a route associated to the delegated prefix on PE= router for the customer/subscriber network. Here the draft (OPTION_PREFIX_= POOL) is talking about how to aggregate those routes for customer networks = as per the information of the prefix pool, when the PE router acts as the D= HCPv6 relay agent. Acee - the BRAS server that is maintaining > subscriber DHCP state should have a configured aggregation policy for > the DHCP prefix pool route. This problem has already been solved in > commercial BRAS servers... Yes, BRAS can do the route aggragation per the information of prefix pool w= hen it has the distributed DHCPv6 server running on it. But unfortunately it hasn't the explicit information about the prefix pool = when it acts as the DHCPv6 relay. The information of the prefix pool are ma= intained in the centralized DHCPv6 server in the target scenario case discu= ssed in the draft (OPTION_PREFIX_POOL). I suppose many operator including t= he major of MSO metwork and some Telecom network, employ this scenario case= in their deployed network. Best Regards, Leaf ________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] on behalf of Alexandr= u Petrescu [alexandru.petrescu@gmail.com] Sent: Friday, August 03, 2012 4:36 To: dhcwg@ietf.org Subject: Re: [dhcwg] [RTG-DIR] DHCPv6 Prefix Pool Option Responding to this is on my todo list since MAastricht I believe - sorry for having missed other opportunities. On a DHCP Relay, there would be a need to set up a route relative to a delegated prefix. I need to better understand the context and then I will give more review of this document. Alex Le 02/08/2012 12:47, Acee Lindem a =E9crit : > Hi, I'm not sure what I was thinking this morning when I said that > the DHCP server should run a routing daemon and advertise the > aggregate route. Rather, the BRAS server that is maintaining > subscriber DHCP state should have a configured aggregation policy for > the DHCP prefix pool route. This problem has already been solved in > commercial BRAS servers and there is no need to add a generic route > advertisement mechanism to DHCP. Thanks, Acee > > On Aug 2, 2012, at 3:34 PM, Adrian Farrel wrote: > >> Hi, >> >> At the Routing Area meeting this morning, Ted raised some potential >> DHCP work that routing folk should look at. Comments ideally go to >> the DHC working group or back to Ted. >> >> Adrian >> >>> -----Original Message----- From: Ted Lemon >>> [mailto:Ted.Lemon@nominum.com] Sent: 02 August 2012 20:11 To: >>> adrian@olddog.co.uk Subject: DHCPv6 Prefix Pool Option >>> >>> Thanks for the time at the mic this morning. The document I >>> wanted you to comment on or solicit comment on is the DHCPv6 >>> Prefix Pool Option draft: >>> >>> http://tools.ietf.org/html/draft-yeh-dhc-dhcpv6-prefix-pool-opt >>> >>> There was a question at the mic about why the DHCP server >>> wouldn't inject the route itself, which I think is a good >>> question, and could be argued to be the >> right >>> thing to do. However, operationally there are a lot of missing >>> pieces to >> this-the >>> DHCP server now becomes, in addition to being a DHCP server, also >>> a publisher >> of >>> routes, and has to have information about the routing topology of >>> the ISP that >> I >>> think might be nontrivial to maintain. >>> >>> The advantage of the current approach, which is improved by this >>> new draft, is that it piggybacks on top of the existing >>> relationship between the relay agent >> and >>> the DHCP server, which is required for DHCP to work. The DHCP >>> server now does not have to know the topology of the network-it >>> sends the prefix aggregation information to the router, which >>> presumably already has that information, by way of the DHCP >>> relay, which is typically co-located in the >> router. >>> >>> So despite my protestations of innocence at the mic, I suppose I >>> do really >> think >>> it's a reasonable way to solve this particular problem. >> > > > > _______________________________________________ routing-discussion > mailing list routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_DED5BA56FEEA46028A079E4D32495402mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9EDB286735FA3E439BB10D21414F1D4C@huawei.com> Content-Transfer-Encoding: quoted-printable

Alexandru - On a DHCP Relay, there would be a need to set up a route rel= ative to a delegated prefix.


Definitely there should be a route associated to the delegated prefix = on PE router for the customer/subscriber network. Here the draft (OPTION_PR= EFIX_POOL) is talking about how to aggregate those routes for cus= tomer networks as per the information of the prefix pool, when the PE router acts as the DHCPv6 relay agent.

 

 

Acee - the BRAS server that is maintaining
> subscriber DHCP state should have a configured aggregation policy for<= br> > the DHCP prefix pool route. This problem has already been solved in > commercial BRAS servers...

 

 

Yes, BRAS can do the route aggragation per the information of = prefix pool when it has the distributed DHCPv6 server running on = it.

 

But unfortunately it hasn't the explicit information about the prefix po= ol when it acts as the DHCPv6 relay. The information of the prefix poo= l are maintained in the centralized DHCPv6 server in the target scenar= io case discussed in the draft (OPTION_PREFIX_POOL). I suppose many operator including the major of MSO metwork and&n= bsp;some Telecom network, employ this scenario case in their deployed netwo= rk.

 

 

Best Regards,

Leaf

 

 

 

 

From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] on behalf = of Alexandru Petrescu [alexandru.petrescu@gmail.com]
Sent: Friday, August 03, 2012 4:36
To: dhcwg@ietf.org
Subject: Re: [dhcwg] [RTG-DIR] DHCPv6 Prefix Pool Option

Responding to this is on my todo list since MAastr= icht I believe - sorry
for having missed other opportunities.

On a DHCP Relay, there would be a need to set up a route relative to a
delegated prefix.

I need to better understand the context and then I will give more review of this document.

Alex

Le 02/08/2012 12:47, Acee Lindem a =E9crit :
> Hi, I'm not sure what I was thinking this morning when I said that
> the DHCP server should run a routing daemon and advertise the
> aggregate route. Rather, the BRAS server that is maintaining
> subscriber DHCP state should have a configured aggregation policy for<= br> > the DHCP prefix pool route. This problem has already been solved in > commercial BRAS servers and there is no need to add a generic route > advertisement mechanism to DHCP. Thanks, Acee
>
> On Aug 2, 2012, at 3:34 PM, Adrian Farrel wrote:
>
>> Hi,
>>
>> At the Routing Area meeting this morning, Ted raised some potentia= l
>> DHCP work that routing folk should look at. Comments ideally go to=
>> the DHC working group or back to Ted.
>>
>> Adrian
>>
>>> -----Original Message----- From: Ted Lemon
>>> [ma= ilto:Ted.Lemon@nominum.com] Sent: 02 August 2012 20:11 To:
>>> adrian@olddog.co.uk Subject: DHCPv6 Prefix Pool Option
>>>
>>> Thanks for the time at the mic this morning.   The d= ocument I
>>> wanted you to comment on or solicit comment on is the DHCPv6 >>> Prefix Pool Option draft:
>>>
>>> http://tools.ietf.org/html/draft-yeh-dhc-dhcpv6-prefix-pool-opt
>>>
>>> There was a question at the mic about why the DHCP server
>>> wouldn't inject the route itself, which I think is a good
>>> question, and could be argued to be the
>> right
>>> thing to do.   However, operationally there are a lo= t of missing
>>> pieces to
>> this-the
>>> DHCP server now becomes, in addition to being a DHCP server, a= lso
>>> a publisher
>> of
>>> routes, and has to have information about the routing topology= of
>>> the ISP that
>> I
>>> think might be nontrivial to maintain.
>>>
>>> The advantage of the current approach, which is improved by th= is
>>> new draft, is that it piggybacks on top of the existing
>>> relationship between the relay agent
>> and
>>> the DHCP server, which is required for DHCP to work. &nbs= p; The DHCP
>>> server now does not have to know the topology of the network-i= t
>>> sends the prefix aggregation information to the router, which<= br> >>> presumably already has that information, by way of the DHCP >>> relay, which is typically co-located in the
>> router.
>>>
>>> So despite my protestations of innocence at the mic, I suppose= I
>>> do really
>> think
>>> it's a reasonable way to solve this particular problem.
>>
>
>
>
> _______________________________________________ routing-discussion
> mailing list routing-discussion@ietf.org
> https://www.ietf.org/mailman/listinfo/routing-discussion
>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg
--_000_DED5BA56FEEA46028A079E4D32495402mimectl_-- From john_brzozowski@cable.comcast.com Tue Aug 7 14:45:01 2012 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 AC4D421F86B8 for ; Tue, 7 Aug 2012 14:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 RacoMgO8hQGI for ; Tue, 7 Aug 2012 14:45:01 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 0523E21F86B3 for ; Tue, 7 Aug 2012 14:45:00 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.28428288; Tue, 07 Aug 2012 15:25:28 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.168]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0309.002; Tue, 7 Aug 2012 17:44:56 -0400 From: "Brzozowski, John" To: dhc WG Thread-Topic: ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) Thread-Index: AQHNdOXirwovxf8CZEyPfdn6AipKZg== Date: Tue, 7 Aug 2012 21:44:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.55.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <89B3B3EBF78D3642AA8D27BC249C1CD1@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc Chairs , Haberman Brian , Ralph Droms Subject: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 07 Aug 2012 21:45:01 -0000 Folks, The following draft was discussed during dhcwg meeting during IETF83. The = draft was recently updated after being expired for a short period. Based o= n the identified need and interest in this topic I have conferred with Ted = and our ADs regarding next steps. As such I would like to initiate a call = to adopt this draft as a working group work item: http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-solmaxrt-update-03 If there are any questions or concerns regarding adopting this draft as a w= ork item for the dhcwg please send mail no later than August 21, 2012 5PM E= DT. Thank you, John= From Ted.Lemon@nominum.com Tue Aug 7 14:54:53 2012 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 4FC8F21F8715 for ; Tue, 7 Aug 2012 14:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Xicu0HNPoXf9 for ; Tue, 7 Aug 2012 14:54:52 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 4F11521F8713 for ; Tue, 7 Aug 2012 14:54:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUCGOq1qtbgcYkfdUjpbFWjgV+mJn1ZTq@postini.com; Tue, 07 Aug 2012 14:54:52 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 3977B1B82F4 for ; Tue, 7 Aug 2012 14:54:51 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 2CC77190060; Tue, 7 Aug 2012 14:54:51 -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.02.0247.003; Tue, 7 Aug 2012 14:54:51 -0700 From: Ted Lemon To: "Brzozowski, John" Thread-Topic: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) Thread-Index: AQHNdOXirwovxf8CZEyPfdn6AipKZpdPWhSA Date: Tue, 7 Aug 2012 21:54:50 +0000 Message-ID: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> References: 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: multipart/alternative; boundary="_000_479C8CA3A0BE41C3A9861F6F3DB1C99Bnominumcom_" MIME-Version: 1.0 Cc: dhc WG , dhc Chairs , Haberman Brian , Ralph Droms Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 07 Aug 2012 21:54:53 -0000 --_000_479C8CA3A0BE41C3A9861F6F3DB1C99Bnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 7, 2012, at 5:44 PM, Brzozowski, John wrote: If there are any questions or concerns regarding adopting this draft as a w= ork item for the dhcwg please send mail no later than August 21, 2012 5PM E= DT. Er, also if you favor adopting the draft please send mail! I'm in favor of adopting. --_000_479C8CA3A0BE41C3A9861F6F3DB1C99Bnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 7, 2012, at 5:44 PM, Brzozowski, John wrote:
If there are any questions or concerns regarding adopting this draft as a wor= k item for the dhcwg please send mail no later than August 21, 2012 5PM EDT= .

Er, also if you favor adopting the draft please send mail!

I'm in favor of adopting.

--_000_479C8CA3A0BE41C3A9861F6F3DB1C99Bnominumcom_-- From Carl.Wuyts@technicolor.com Tue Aug 7 22:45:33 2012 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 AA82011E812B for ; Tue, 7 Aug 2012 22:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.988 X-Spam-Level: X-Spam-Status: No, score=-4.988 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] 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 zaRaIBmo86T9 for ; Tue, 7 Aug 2012 22:45:32 -0700 (PDT) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3B11E809C for ; Tue, 7 Aug 2012 22:45:31 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUCH88fKSzPFeIUxCHG8GwNBtbelNtDm8@postini.com; Tue, 07 Aug 2012 22:45:31 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 8 Aug 2012 07:45:11 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.192]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Wed, 8 Aug 2012 07:45:16 +0200 From: Wuyts Carl To: Ted Lemon , "Brzozowski, John" Date: Wed, 8 Aug 2012 07:45:15 +0200 Thread-Topic: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) Thread-Index: AQHNdOXirwovxf8CZEyPfdn6AipKZpdPWhSAgAAOBZA= Message-ID: <867F4B6A1672E541A94676D556793ACD149FC9A822@MOPESMBX01.eu.thmulti.com> References: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> In-Reply-To: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_867F4B6A1672E541A94676D556793ACD149FC9A822MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Cc: dhc WG , dhc Chairs , Haberman Brian , Ralph Droms Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 08 Aug 2012 05:45:33 -0000 --_005_867F4B6A1672E541A94676D556793ACD149FC9A822MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD149FC9A822MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD149FC9A822MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In favor: +1 Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CD7539.BF7FECB0] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image002.gif@01CD7539.BF7FECB0] Help preserve the color of our world - Think before you print. From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: dinsdag 7 augustus 2012 23:55 To: Brzozowski, John Cc: dhc WG; dhc Chairs; Haberman Brian; Ralph Droms Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL= _MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) On Aug 7, 2012, at 5:44 PM, Brzozowski, John wrote: If there are any questions or concerns regarding adopting this draft as a w= ork item for the dhcwg please send mail no later than August 21, 2012 5PM E= DT. Er, also if you favor adopting the draft please send mail! I'm in favor of adopting. --_000_867F4B6A1672E541A94676D556793ACD149FC9A822MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In favor:= +1

 

=

Carl Wuyts=

GCD System Architect Network= ing

Connect Division

carl.wuyts@technicolor.com

tel.: +32 3 443 65 90

3D"Visit=

Prins Boudewijnlaan 47 &nbs= p;-  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV

= Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium

Company= registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen<= /o:p>

3DEco=

Help preserve the color of our world - Thin= k before you print.

 

 

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces= @ietf.org] On Behalf Of Ted Lemon
Sent: dinsdag 7 augustus= 2012 23:55
To: Brzozowski, John
Cc: dhc WG; dhc Chairs= ; Haberman Brian; Ralph Droms
Subject: Re: [dhcwg] ADOPTION REQUE= ST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-sol= maxrt-update-03)

 

On Aug 7, 2012, at 5:44 PM,= Brzozowski, John wrote:

If there are any questions or concerns regarding adopting this draft as a = work item for the dhcwg please send mail no later than August 21, 2012 5PM = EDT.

 

Er, also if you favo= r adopting the draft please send mail!

 

I'm in favor= of adopting.

 

= --_000_867F4B6A1672E541A94676D556793ACD149FC9A822MOPESMBX01eut_-- --_005_867F4B6A1672E541A94676D556793ACD149FC9A822MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1834; creation-date="Wed, 08 Aug 2012 05:45:15 GMT"; modification-date="Wed, 08 Aug 2012 05:45:15 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_005_867F4B6A1672E541A94676D556793ACD149FC9A822MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=493; creation-date="Wed, 08 Aug 2012 05:45:15 GMT"; modification-date="Wed, 08 Aug 2012 05:45:15 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_005_867F4B6A1672E541A94676D556793ACD149FC9A822MOPESMBX01eut_-- From tomasz.mrugalski@gmail.com Wed Aug 8 04:32:07 2012 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 5B30321F855A for ; Wed, 8 Aug 2012 04:32:07 -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=[BAYES_00=-2.599, 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 DZB9v9hTd13d for ; Wed, 8 Aug 2012 04:32:06 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADAA21F8554 for ; Wed, 8 Aug 2012 04:32:06 -0700 (PDT) Received: by eekb45 with SMTP id b45so194399eek.31 for ; Wed, 08 Aug 2012 04:32:05 -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:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=01qIGdRxOsR8oMtSAcPGSO+BGOgIMyIV5vyWupOY5Dw=; b=NtOMSAIsvexNyhwmSGw5N8M1viZPgC5M57w5xMWKmROVhCkBkPBFG7Jj1ncgCGKowE c597+fFCVWJsKF4vFKsJLXF8bNX5XqaQqNDFkw/SGiTd+c6n5BVdZoI4i8ftK/bRkQyK kRVYhPaaUjQwurb0dsnbkqMK8R9jPnYDuHT1Y54OtqbNdwmUTFzRGa9gJ50zBGOddKmh RGhIWuhLK1fud9OMZqQsbm99dQ2wjZL/qQErGTFqgRU8AZh+6bYqPNgb0wzjD/omuzix QJ17PVuL8hp88jPXOFF7Wj2HGSIs6biPd/yHzj9AVFGdC/ht1wGm/FxGGy/YELnOEMuY knfQ== Received: by 10.14.172.129 with SMTP id t1mr13877321eel.34.1344425525571; Wed, 08 Aug 2012 04:32:05 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:6d03:77cb:a9b5:70c1? ([2001:470:6061:1:6d03:77cb:a9b5:70c1]) by mx.google.com with ESMTPS id 45sm630140eeb.8.2012.08.08.04.32.04 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 04:32:04 -0700 (PDT) Message-ID: <50224E2B.3040203@gmail.com> Date: Wed, 08 Aug 2012 13:31:55 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> In-Reply-To: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> X-TagToolbar-Keys: D20120808133155413 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dhcwg] ADOPTION REQUEST for draft-droms-dhc-dhcpv6-solmaxrt-update-03 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, 08 Aug 2012 11:32:07 -0000 On 07.08.2012 23:54, Ted Lemon wrote: > On Aug 7, 2012, at 5:44 PM, Brzozowski, John wrote: >> If there are any questions or concerns regarding adopting this draft >> as a work item for the dhcwg please send mail no later than August 21, >> 2012 5PM EDT. > > Er, also if you favor adopting the draft please send mail! > > I'm in favor of adopting. I'm in favor as well. Tomek From ichiroumakino@gmail.com Wed Aug 8 04:38:29 2012 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 91F7E21F863B for ; Wed, 8 Aug 2012 04:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 YffZnJ6Ag8FF for ; Wed, 8 Aug 2012 04:38:28 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9278D21F85DA for ; Wed, 8 Aug 2012 04:38:28 -0700 (PDT) Received: by eaai11 with SMTP id i11so196448eaa.31 for ; Wed, 08 Aug 2012 04:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3jdM0gn84cUb2CsU7+5HsiWCjjFvgiTWl0nn28s8Vms=; b=rhRWwKlbZOmhOLXVKoGBxHt8j2S9+PDMnS6NEN/jz48VNcXywN1uu+E9wfJ7mOa3zG RYE1TJEYPBS8fqcVTNCNReB9Kxi/GIoNCH6NnteRMcmHg4oBavGC/gYNIJses17TSbWg R4liGR5IHZzIlZXKU3gVZKrPxvzQn0SA6dux7uDx8Q+4V6EHdNJj0wZ8lBFM+fBiyu5d kxRnmzP8MrYzBAasuOGGjkCMUh2ihLNW60S3g5OGNjoNI+Rxpx98lZSoqtkSDKd0g64f uHPdE7yYLJw54MdcosteMnlAb36HFzEMUgwz8/1UESrJM1n0Mqlpjod1ild/B9HWla/Z H49g== Received: by 10.14.211.3 with SMTP id v3mr10414155eeo.43.1344425896417; Wed, 08 Aug 2012 04:38:16 -0700 (PDT) Received: from dhcp-10-61-99-19.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id d48sm63932057eeo.10.2012.08.08.04.38.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Aug 2012 04:38:15 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 8 Aug 2012 13:38:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1278) Cc: dhc WG , dhc Chairs , Haberman Brian , Ralph Droms Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 08 Aug 2012 11:38:29 -0000 > The following draft was discussed during dhcwg meeting during IETF83. = The draft was recently updated after being expired for a short period. = Based on the identified need and interest in this topic I have conferred = with Ted and our ADs regarding next steps. As such I would like to = initiate a call to adopt this draft as a working group work item: >=20 > http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-solmaxrt-update-03 >=20 > If there are any questions or concerns regarding adopting this draft = as a work item for the dhcwg please send mail no later than August 21, = 2012 5PM EDT. I'm in favour of adoption. I would be even more in favour if it included = only the timer update and dropped the new option. cheers, Ole From twinters@iol.unh.edu Wed Aug 8 04:39:05 2012 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 A10CF21F8645 for ; Wed, 8 Aug 2012 04:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 J5MhES4Lj6sJ for ; Wed, 8 Aug 2012 04:39:05 -0700 (PDT) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with SMTP id B607321F8620 for ; Wed, 8 Aug 2012 04:39:04 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKUCJP2LWczKqPDcbKXeCil7SkVW/4YqNV@postini.com; Wed, 08 Aug 2012 04:39:04 PDT Received: from [10.0.1.8] (c-24-63-15-128.hsd1.nh.comcast.net [24.63.15.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id B0D478F0079 for ; Wed, 8 Aug 2012 07:39:03 -0400 (EDT) References: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> <50224E2B.3040203@gmail.com> From: Timothy Winters Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (9B206) In-Reply-To: <50224E2B.3040203@gmail.com> Message-Id: <8376CFDD-68F2-4ECE-A021-7A6A68FE7562@iol.unh.edu> Date: Wed, 8 Aug 2012 07:39:04 -0400 To: "dhcwg@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [dhcwg] ADOPTION REQUEST for draft-droms-dhc-dhcpv6-solmaxrt-update-03 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, 08 Aug 2012 11:39:05 -0000 I'm in favor of adopting this draft. Tim On Aug 8, 2012, at 7:31 AM, Tomek Mrugalski wro= te: > On 07.08.2012 23:54, Ted Lemon wrote: >> On Aug 7, 2012, at 5:44 PM, Brzozowski, John wrote: >>> If there are any questions or concerns regarding adopting this draft >>> as a work item for the dhcwg please send mail no later than August 21, >>> 2012 5PM EDT. >>=20 >> Er, also if you favor adopting the draft please send mail! >>=20 >> I'm in favor of adopting. > I'm in favor as well. >=20 > Tomek >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Wed Aug 8 05:30:15 2012 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 3D3E221F85F7 for ; Wed, 8 Aug 2012 05:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 f+qJxu8-wb-x for ; Wed, 8 Aug 2012 05:30: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 8475C21F860D for ; Wed, 8 Aug 2012 05:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=977; q=dns/txt; s=iport; t=1344429014; x=1345638614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TU9rsCLGLbbUM0/xx/2ghrmRPpR/pJnO1LOPbfg4oWI=; b=bRFPCrCESh6KrU1UG4SJ0APuneOOm+N1xoheF3Lw+qo+1eqI5srbHjEc G2VZEOEzTkZFAC5h391t7+GuBiy2amkmQOo+LXzwUrwDPfse9ERO/iiWa zZ1TQ77mpCEmLQVAMDnrb/+bNmBE35MHxcYWW3lLuw2SVbKbLmCstp3U3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUFAHZaIlCtJXG8/2dsb2JhbABFDoUstCGBB4IgAQEBAwEBAQEPASc0CwULAgEIDgoeECEGCyUCBA4FIodcAwYGC5pXlmkNiUoEii1lGoVmYAOTdoFTiwqDH4FmgiY5gV8 X-IronPort-AV: E=Sophos;i="4.77,733,1336348800"; d="scan'208";a="109545274" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 08 Aug 2012 12:30:14 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q78CUEqO017971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 12:30:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 07:30:13 -0500 From: "Bernie Volz (volz)" To: Timothy Winters Thread-Topic: [dhcwg] ADOPTION REQUEST for draft-droms-dhc-dhcpv6-solmaxrt-update-03 Thread-Index: AQHNdVlz+XR+0eVMzUCmkZrYBq1JDZdQHfEA//+6eYg= Date: Wed, 8 Aug 2012 12:30:12 +0000 Message-ID: <61B6CE5C-0EBB-49AE-830E-7E157024049B@cisco.com> References: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> <50224E2B.3040203@gmail.com>, <8376CFDD-68F2-4ECE-A021-7A6A68FE7562@iol.unh.edu> In-Reply-To: <8376CFDD-68F2-4ECE-A021-7A6A68FE7562@iol.unh.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.004 x-tm-as-result: No--37.940300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] ADOPTION REQUEST for draft-droms-dhc-dhcpv6-solmaxrt-update-03 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, 08 Aug 2012 12:30:15 -0000 +1 in favor. - Bernie On Aug 8, 2012, at 7:39 AM, "Timothy Winters" wrote: > I'm in favor of adopting this draft. >=20 > Tim >=20 > On Aug 8, 2012, at 7:31 AM, Tomek Mrugalski = wrote: >=20 >> On 07.08.2012 23:54, Ted Lemon wrote: >>> On Aug 7, 2012, at 5:44 PM, Brzozowski, John wrote: >>>> If there are any questions or concerns regarding adopting this draft >>>> as a work item for the dhcwg please send mail no later than August 21, >>>> 2012 5PM EDT. >>>=20 >>> Er, also if you favor adopting the draft please send mail! >>>=20 >>> I'm in favor of adopting. >> I'm in favor as well. >>=20 >> Tomek >>=20 >>=20 >> _______________________________________________ >> 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 From hansliu@gmail.com Wed Aug 8 06:20:46 2012 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 2BF4521F84A5 for ; Wed, 8 Aug 2012 06:20:46 -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=[BAYES_00=-2.599, 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 mpa5bYtX3lca for ; Wed, 8 Aug 2012 06:20:45 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D01921F848B for ; Wed, 8 Aug 2012 06:20:45 -0700 (PDT) Received: by weyu54 with SMTP id u54so536331wey.31 for ; Wed, 08 Aug 2012 06:20:44 -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:content-transfer-encoding; bh=IudF0vrcVDPzdgKZxUPbRZxk9t/uAriKGx1SewjDFLo=; b=06BQewxf3uGDbvaf7PbXU2zf5AfkkeGaAxJzuR9xXx+YQ+ESKu3C/iQvkKHUkhTDH1 wkblN1QUO7+Mmw64YU9BLzrNaU4Q2Zh4LCt+lQHVyG2rpqjZdR+sPe9bV8oSEACZcsQl O3/Mgmm09gSXhY5SKO/iSSObypzcu5dysl0hv0obRksQtk2MLa4zcKBd+7bTA0PGYoQz uuTHHQ6BylDj2lilyj+RUkcNHwZWG38E1jIwZ60MmQ8FPZ2K1+BYg+BHuBi1KNMa9UL9 LwVtXvHiR9BlyBysxmjtCb9NMtUAyefU1Btv0qgEfGve6bgmfsQTeM3lvbjnCpAC1kjz YrmA== MIME-Version: 1.0 Received: by 10.180.82.164 with SMTP id j4mr2672199wiy.18.1344432044371; Wed, 08 Aug 2012 06:20:44 -0700 (PDT) Received: by 10.223.194.68 with HTTP; Wed, 8 Aug 2012 06:20:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Aug 2012 21:20:44 +0800 Message-ID: From: Hans Liu To: "Brzozowski, John" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dhc WG , dhc Chairs , Haberman Brian , Ralph Droms Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 08 Aug 2012 13:20:46 -0000 I'm in favour of adoption. Actually I already implemented it. Oops .... Best regards, Hans On Wed, Aug 8, 2012 at 5:44 AM, Brzozowski, John wrote: > Folks, > > The following draft was discussed during dhcwg meeting during IETF83. Th= e draft was recently updated after being expired for a short period. Based= on the identified need and interest in this topic I have conferred with Te= d and our ADs regarding next steps. As such I would like to initiate a cal= l to adopt this draft as a working group work item: > > http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-solmaxrt-update-03 > > If there are any questions or concerns regarding adopting this draft as a= work item for the dhcwg please send mail no later than August 21, 2012 5PM= EDT. > > Thank you, > > John > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From suresh.krishnan@ericsson.com Wed Aug 8 11:12:51 2012 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 8675421F85ED for ; Wed, 8 Aug 2012 11:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 peDuQ0+m9lao for ; Wed, 8 Aug 2012 11:12:51 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id CB8A821F85B8 for ; Wed, 8 Aug 2012 11:12:50 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q78IBdET028658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 13:12:47 -0500 Received: from [142.133.112.80] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 8 Aug 2012 14:12:06 -0400 Message-ID: <5022ABF5.7070508@ericsson.com> Date: Wed, 8 Aug 2012 14:12:05 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Brzozowski, John" References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: dhc WG , dhc Chairs , Haberman Brian , Ralph Droms Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 08 Aug 2012 18:12:51 -0000 Hi Chairs, On 08/07/2012 05:44 PM, Brzozowski, John wrote: > Folks, > > The following draft was discussed during dhcwg meeting during IETF83. The draft was recently updated after being expired for a short period. Based on the identified need and interest in this topic I have conferred with Ted and our ADs regarding next steps. As such I would like to initiate a call to adopt this draft as a working group work item: > > http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-solmaxrt-update-03 > > If there are any questions or concerns regarding adopting this draft as a work item for the dhcwg please send mail no later than August 21, 2012 5PM EDT. I am in favor of adopting this draft as wg item. It is a welcome and needed update. Thanks Suresh From jason.weil@twcable.com Wed Aug 8 11:31:50 2012 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 5C20021F8550 for ; Wed, 8 Aug 2012 11:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 K1Dkf+7xcztc for ; Wed, 8 Aug 2012 11:31:49 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id B4F6021F850B for ; Wed, 8 Aug 2012 11:31:49 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,734,1336363200"; d="scan'208";a="403621666" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 08 Aug 2012 14:31:05 -0400 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.45]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 8 Aug 2012 14:31:48 -0400 From: "Weil, Jason" To: "Brzozowski, John" , dhc WG Date: Wed, 8 Aug 2012 14:32:15 -0400 Thread-Topic: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) Thread-Index: Ac11lBJfxo0v1+xoRcm0PgBjPPdPCw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc Chairs , Haberman Brian , Ralph Droms Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 08 Aug 2012 18:31:50 -0000 I am in favor of adopting. This draft addresses an immediate need in access provider networks who rely on DHC for customer provisioning. Thanks, Jason On 8/7/12 5:44 PM, "Brzozowski, John" wrote: >Folks, > >The following draft was discussed during dhcwg meeting during IETF83. >The draft was recently updated after being expired for a short period. >Based on the identified need and interest in this topic I have conferred >with Ted and our ADs regarding next steps. As such I would like to >initiate a call to adopt this draft as a working group work item: > >http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-solmaxrt-update-03 > >If there are any questions or concerns regarding adopting this draft as a >work item for the dhcwg please send mail no later than August 21, 2012 >5PM EDT. > >Thank you, > >John >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From victor.kuarsingh@gmail.com Wed Aug 8 12:03:56 2012 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 6735821F8653 for ; Wed, 8 Aug 2012 12:03:56 -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=[BAYES_00=-2.599, 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 B2D4owh+XovG for ; Wed, 8 Aug 2012 12:03:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA04A21F8643 for ; Wed, 8 Aug 2012 12:03:55 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1888752pbb.31 for ; Wed, 08 Aug 2012 12:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=UTsl4eMD62MRhBIyZOkkoTqPm+/KbXiq++iC3Wg0LGs=; b=ID0pLFByo+sxGvDSEuI0FvMKxPJFHkuuoEO0LQm3GTHViILEGVtixZOfHhRLc/PJfD NLcuW500rszrJvS1jB7JA3BFeAyyotfAR9uDtUqkk4gcfXYrbz9AGCcwlID6VBNTvHpl M9q4LP/ALSRoYu0naV3d3q5/ov21N6BsIcAzXWHXdKHgiSwqh8OK5vSWb0VnBf3qoWCS 10pAHFFrvewc9BXaEZFaJeIaNXF1FA2Pa1IpCzY67at1TmgBJIt2UP2w9l7c54d31f0/ 9K/9STlib5zzbDkyXRc37qDkyDx2DYbdCWVj1VrvJen/s60103emvMRQ8XvocrXGfzMz 2h2Q== Received: by 10.68.242.228 with SMTP id wt4mr38219087pbc.89.1344452635493; Wed, 08 Aug 2012 12:03:55 -0700 (PDT) Received: from [198.134.90.207] ([198.134.90.207]) by mx.google.com with ESMTPS id qr2sm13893226pbc.44.2012.08.08.12.03.51 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 12:03:54 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 08 Aug 2012 14:54:57 -0700 From: Victor Kuarsingh To: "Weil, Jason" , John Jason Brzozowski , dhc WG Message-ID: Thread-Topic: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: dhc Chairs , Haberman Brian , Ralph Droms Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 08 Aug 2012 19:03:56 -0000 In line with Jason's comments below, I too support this draft as an item. Regards, Victor K On 12-08-08 11:32 AM, "Weil, Jason" wrote: >I am in favor of adopting. This draft addresses an immediate need in >access provider networks who rely on DHC for customer provisioning. > >Thanks, > >Jason > >On 8/7/12 5:44 PM, "Brzozowski, John" >wrote: > >>Folks, >> >>The following draft was discussed during dhcwg meeting during IETF83. >>The draft was recently updated after being expired for a short period. >>Based on the identified need and interest in this topic I have conferred >>with Ted and our ADs regarding next steps. As such I would like to >>initiate a call to adopt this draft as a working group work item: >> >>http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-solmaxrt-update-03 >> >>If there are any questions or concerns regarding adopting this draft as a >>work item for the dhcwg please send mail no later than August 21, 2012 >>5PM EDT. >> >>Thank you, >> >>John >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www.ietf.org/mailman/listinfo/dhcwg > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Wed Aug 8 16:27:11 2012 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 9967C11E808D for ; Wed, 8 Aug 2012 16:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.377, 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 HyhI3Rd4iIQq for ; Wed, 8 Aug 2012 16:27:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F32C611E8087 for ; Wed, 8 Aug 2012 16:27:10 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJB11282; Wed, 08 Aug 2012 15:27:10 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 16:24:38 -0700 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 16:24:42 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 07:24:36 +0800 From: Sheng Jiang To: "Brzozowski, John" , dhc WG Thread-Topic: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) Thread-Index: AQHNdOXirwovxf8CZEyPfdn6AipKZpdQkBKg Date: Wed, 8 Aug 2012 23:24:35 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F03B61@szxeml545-mbx.china.huawei.com> References: 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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc Chairs , Haberman Brian , Ralph Droms Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 08 Aug 2012 23:27:11 -0000 U3VwcG9ydCB0aGUgYWRvcHRpb24uDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBCcnpvem93c2tpLCBKb2huDQo+U2VudDogV2VkbmVz ZGF5LCBBdWd1c3QgMDgsIDIwMTIgNTo0NSBBTQ0KPlRvOiBkaGMgV0cNCj5DYzogZGhjIENoYWly czsgSGFiZXJtYW4gQnJpYW47IFJhbHBoIERyb21zDQo+U3ViamVjdDogW2RoY3dnXSBBRE9QVElP TiBSRVFVRVNUOiBNb2RpZmljYXRpb24gdG8gRGVmYXVsdCBWYWx1ZSBvZg0KPlNPTF9NQVhfUlQg KGRyYWZ0LWRyb21zLWRoYy1kaGNwdjYtc29sbWF4cnQtdXBkYXRlLTAzKQ0KPg0KPkZvbGtzLA0K Pg0KPlRoZSBmb2xsb3dpbmcgZHJhZnQgd2FzIGRpc2N1c3NlZCBkdXJpbmcgZGhjd2cgbWVldGlu ZyBkdXJpbmcgSUVURjgzLiAgVGhlDQo+ZHJhZnQgd2FzIHJlY2VudGx5IHVwZGF0ZWQgYWZ0ZXIg YmVpbmcgZXhwaXJlZCBmb3IgYSBzaG9ydCBwZXJpb2QuICBCYXNlZCBvbg0KPnRoZSBpZGVudGlm aWVkIG5lZWQgYW5kIGludGVyZXN0IGluIHRoaXMgdG9waWMgSSBoYXZlIGNvbmZlcnJlZCB3aXRo IFRlZCBhbmQgb3VyDQo+QURzIHJlZ2FyZGluZyBuZXh0IHN0ZXBzLiAgQXMgc3VjaCBJIHdvdWxk IGxpa2UgdG8gaW5pdGlhdGUgYSBjYWxsIHRvIGFkb3B0IHRoaXMNCj5kcmFmdCBhcyBhIHdvcmtp bmcgZ3JvdXAgd29yayBpdGVtOg0KPg0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWRyb21zLWRoYy1kaGNwdjYtc29sbWF4cnQtdXBkYXRlLTAzDQo+DQo+SWYgdGhlcmUgYXJlIGFu eSBxdWVzdGlvbnMgb3IgY29uY2VybnMgcmVnYXJkaW5nIGFkb3B0aW5nIHRoaXMgZHJhZnQgYXMg YSB3b3JrDQo+aXRlbSBmb3IgdGhlIGRoY3dnIHBsZWFzZSBzZW5kIG1haWwgbm8gbGF0ZXIgdGhh biBBdWd1c3QgMjEsIDIwMTIgNVBNIEVEVC4NCj4NCj5UaGFuayB5b3UsDQo+DQo+Sm9obg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFp bGluZyBsaXN0DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RoY3dnDQo= From bs7652@att.com Thu Aug 9 06:24:05 2012 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 7C9FC21F86CF for ; Thu, 9 Aug 2012 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 4xT4Ej2QrgW0 for ; Thu, 9 Aug 2012 06:24:05 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id C7EBE21F86C9 for ; Thu, 9 Aug 2012 06:24:04 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo03.seg.att.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 4f9b3205.2aaad8e1a940.1146725.00-593.3168347.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 09 Aug 2012 13:24:04 +0000 (UTC) X-MXL-Hash: 5023b9f445f5f972-b86aa4a5d31640b7a17af01bbe2d42181497ae6d Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id be9b3205.0.1146679.00-467.3168199.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 09 Aug 2012 13:23:56 +0000 (UTC) X-MXL-Hash: 5023b9ec6b373138-c29ae7f87f7c8a354e2ed28899d09eb4d2d0a9b2 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q79DNs9s012968; Thu, 9 Aug 2012 09:23:55 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q79DMeU8011960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 09:23:48 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by sflint04.pst.cso.att.com (RSA Interceptor); Thu, 9 Aug 2012 09:22:17 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.02.0298.004; Thu, 9 Aug 2012 09:22:16 -0400 From: "STARK, BARBARA H" To: "Brzozowski, John" , dhc WG Thread-Topic: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) Thread-Index: AQHNdOXirwovxf8CZEyPfdn6AipKZpdQkBKggADpudA= Date: Thu, 9 Aug 2012 13:22:16 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61115CDEC@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <5D36713D8A4E7348A7E10DF7437A4B9239F03B61@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F03B61@szxeml545-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.82.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=Ql9-6Tpu5roA:10 a=3MkzUYqln20A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=48vgC7mUAAAA:8 a=Lu0bPQ9y_9pSgnDEwxgA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10] Cc: dhc Chairs , Haberman Brian , Ralph Droms Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 09 Aug 2012 13:24:05 -0000 +1 Barbara > Support the adoption. >=20 > >Subject: [dhcwg] ADOPTION REQUEST: Modification to Default Value of > >SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) > > > >Folks, > > > >The following draft was discussed during dhcwg meeting during IETF83. > >The draft was recently updated after being expired for a short period. > >Based on the identified need and interest in this topic I have > >conferred with Ted and our ADs regarding next steps. As such I would > >like to initiate a call to adopt this draft as a working group work item= : > > > >http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-solmaxrt-update-03 > > > >If there are any questions or concerns regarding adopting this draft as > >a work item for the dhcwg please send mail no later than August 21, 2012 > 5PM EDT. > > > >Thank you, > > > >John From Ted.Lemon@nominum.com Thu Aug 9 20:15:02 2012 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 B8E5D21F8446 for ; Thu, 9 Aug 2012 20:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 6edlSrft6nIF for ; Thu, 9 Aug 2012 20:15:01 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4741521F8443 for ; Thu, 9 Aug 2012 20:15: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 DSNKUCR8tCQqd/1GcbEpft1mL/EknPkG0HxL@postini.com; Thu, 09 Aug 2012 20:15: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 EBE611B8303 for ; Thu, 9 Aug 2012 20:14:59 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 E1CD2190052 for ; Thu, 9 Aug 2012 20:14:59 -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.02.0247.003; Thu, 9 Aug 2012 20:14:53 -0700 From: Ted Lemon To: dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhg== Date: Fri, 10 Aug 2012 03:14:53 +0000 Message-ID: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@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: <2D8CC1FD71F27443B7F0256756DE8AFF@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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: Fri, 10 Aug 2012 03:15:02 -0000 The authors have requested a working group last call. The document descri= bes some problems that exist in the way DHCP clients handle multiple statef= ul options, and proposes a solution that unifies the client state machine t= o accommodate these issues. This document could use additional review, so please take the time to read = it over and comment on it if you have any comments. If you are in favor o= f advancing the document, please say so. If you oppose advancing it, plea= se say so, and say why. We will evaluate the consensus based on these res= ponses on August 24. Thanks! From Ted.Lemon@nominum.com Fri Aug 10 05:43:03 2012 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 5225521F8507 for ; Fri, 10 Aug 2012 05:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 kfZ6FESkaDHS for ; Fri, 10 Aug 2012 05:43:02 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 92DF421F853A for ; Fri, 10 Aug 2012 05:43:02 -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 DSNKUCUB0AXGMLCY1xv5dPm/kroYFvJL2XIC@postini.com; Fri, 10 Aug 2012 05:43:02 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 883F11B80A9 for ; Fri, 10 Aug 2012 05:42:56 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 7E250190052 for ; Fri, 10 Aug 2012 05:42:56 -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.02.0247.003; Fri, 10 Aug 2012 05:42:56 -0700 From: Ted Lemon To: dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNdvWqSDMOAnuzpUmlatl1eCUEGA== Date: Fri, 10 Aug 2012 12:42:56 +0000 Message-ID: <4D779082-B182-4728-9534-39456573682E@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-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: Fri, 10 Aug 2012 12:43:03 -0000 The authors of this draft have requested a working group last call. The d= raft explains how DHCP clients operate in an environment where the interfac= e being configured doesn't support multicast (e.g., 6RD). If this is a ma= tter of interest to you, please review the draft and send comments to the l= ist. If you are in favor of advancing the draft, please say so on the list; if n= obody supports it, it won't advance. If you oppose advancing it, please a= lso say so. We will determine consensus on August 24. From Ted.Lemon@nominum.com Fri Aug 10 06:35:18 2012 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 06A8F21F85A3 for ; Fri, 10 Aug 2012 06:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 dviZDvWKi2Wi for ; Fri, 10 Aug 2012 06:35:17 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id AA64D21F8582 for ; Fri, 10 Aug 2012 06:35:16 -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 DSNKUCUOBHmYWtZySiA/rinSHqTjUpsosqJR@postini.com; Fri, 10 Aug 2012 06:35: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 42D7F1B802F for ; Fri, 10 Aug 2012 06:34:38 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 393DE190052 for ; Fri, 10 Aug 2012 06:34:38 -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.02.0247.003; Fri, 10 Aug 2012 06:34:38 -0700 From: Ted Lemon To: dhc WG Thread-Topic: WGLC: draft-ietf-dhc-client-id-02 Thread-Index: AQHNdvzipwaJ7NUE4EeU+hu4IXKgZQ== Date: Fri, 10 Aug 2012 13:34:37 +0000 Message-ID: <1939A7BF-5F90-4801-9956-A21161F1B024@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 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, 10 Aug 2012 13:35:18 -0000 The authors have requested a working group last call for this draft. This= is the document that clarifies the use of the DHCP client identifier by DH= CP servers, particularly in cases where chaddr is zero. Please review the= draft and indicate on the mailing list whether you support its advancement= or oppose its advancement. We will determine consensus on August 24. From Ted.Lemon@nominum.com Sun Aug 12 19:05:01 2012 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 6F0BE21F85D2 for ; Sun, 12 Aug 2012 19:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.817 X-Spam-Level: X-Spam-Status: No, score=-105.817 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_05=-1.11, 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 n9re79OyIz51 for ; Sun, 12 Aug 2012 19:05:00 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id D8E5E21F8565 for ; Sun, 12 Aug 2012 19:04:59 -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 DSNKUChgy0mRFh1JY64/c/0FQoMLT8pal6nK@postini.com; Sun, 12 Aug 2012 19:04:59 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 911AD1B82F9 for ; Sun, 12 Aug 2012 19:04:58 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 85E65190052 for ; Sun, 12 Aug 2012 19:04:58 -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.02.0247.003; Sun, 12 Aug 2012 19:04:58 -0700 From: Ted Lemon To: dhc WG Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGQ== Date: Mon, 13 Aug 2012 02:04:57 +0000 Message-ID: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@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: <1F236605FEEAEA4BB5B5241552D00F30@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 13 Aug 2012 02:05:01 -0000 The authors have requested a working group last call for this draft. The = draft provides a mechanism whereby the DHCP server can indicate to the DHCP= client which prefix it should use for autoconfiguration, for instance for = CGA address generation. This draft has been hanging around for a while, a= nd could definitely use more eyes on it. Please take the time to review i= t; if you think it's a good idea, please indicate your support for advancin= g the draft. If you think it's a bad idea, please indicate that you do no= t support advancing it. If you have comments, they would be very much app= reciated. We will determine consensus on August 27. From ghalwasi@cisco.com Sun Aug 12 19:57:47 2012 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 CA64421F86A8 for ; Sun, 12 Aug 2012 19:57: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 pLKdsRK9zLvF for ; Sun, 12 Aug 2012 19:57: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 1F3F421F86A4 for ; Sun, 12 Aug 2012 19:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1023; q=dns/txt; s=iport; t=1344826667; x=1346036267; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ORwFSUuYKJ3nlXKISgrOBWU+n9CYkc09Av293BoQ1gU=; b=gXLHoohSoXnh5xaSIFMwlt/YmA3z/7/BkDQ4Kb7sk0ta1o7V08x6YclI td25o5Iqmp2o+0iF94hADntEtgHO45si0lCnVFo6+fmbEl1yQJJ+G5/wo bpGt3hizwwr6WVm0puyWuw/pLbyOQts54Bd6z13okvYFGOkmof4hzdKU6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGFsKFCtJV2Z/2dsb2JhbABDuXiBB4IgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCBMHh2sLlwufKASLEoVRYAOjdYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,757,1336348800"; d="scan'208";a="107872061" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 13 Aug 2012 02:57:46 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7D2vkvU015946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 02:57:46 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Sun, 12 Aug 2012 21:57:46 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpdXEVvg Date: Mon, 13 Aug 2012 02:57:45 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0D01D3@xmb-aln-x06.cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> In-Reply-To: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.104.48] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19108.001 x-tm-as-result: No--31.445200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 13 Aug 2012 02:57:47 -0000 I support this document. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, August 10, 2012 8:45 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 The authors have requested a working group last call. The document descri= bes some problems that exist in the way DHCP clients handle multiple statef= ul options, and proposes a solution that unifies the client state machine t= o accommodate these issues. This document could use additional review, so please take the time to read = it over and comment on it if you have any comments. If you are in favor o= f advancing the document, please say so. If you oppose advancing it, plea= se say so, and say why. We will evaluate the consensus based on these res= ponses on August 24. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ghalwasi@cisco.com Sun Aug 12 21:20:48 2012 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 5AB7F21F84E4 for ; Sun, 12 Aug 2012 21:20:48 -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 wASfCTBgxDKF for ; Sun, 12 Aug 2012 21:20: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 18DAB21F84EF for ; Sun, 12 Aug 2012 21:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=2134; q=dns/txt; s=iport; t=1344831647; x=1346041247; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=zJQ0ZlE60GTu3H7mEN88e41SBfoa71aH2bpFQNyP30M=; b=PBCPUONFy9wEmG0n724Bk3UUZPVHq9VQBPFV0ePKxFlXeD9fh/mALyc4 l9jxIgWCYnP7Ut61auw131p/OQHSRN1AeJ0GzIkazAGwuhEVoM8GY/dK4 uA8E0kHZsNEOpsOg3aPNTfI5ikO2solttmZjimxQaeMdHeiEhstgLwxZ7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABuAKFCtJXG9/2dsb2JhbABEuXiBB4IgAQEBBAEBAQ8BCh00ARYEAgEIEQQBAQsUCQcnCxQJCAIEARIIGodrC5cOnywEixKFUWADo3WBZoJf X-IronPort-AV: E=Sophos;i="4.77,757,1336348800"; d="scan'208";a="110872369" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 13 Aug 2012 04:20:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7D4KkMB006191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 04:20:46 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Sun, 12 Aug 2012 23:20:46 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58g Date: Mon, 13 Aug 2012 04:20:45 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> In-Reply-To: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.104.48] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19108.001 x-tm-as-result: No--41.521900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 13 Aug 2012 04:20:48 -0000 I like the idea but I do have few comments:-. 1.) Abstract does not seems clear to me.=20 This document introduce a procedure for configuring hosts' IPv6 address which the prefix is assigned from a DHCPv6 server through DHCPv6 protocol while the interface identifiers are independently generated by the hosts. 2.) Section 1 . Introduction. Change "host-genarated" to "host-generated" 3.) Section 1 . Introduction. Change "separats" to "separates" 4.) Section 1 . Introduction. Change "ingerface identifiers" to "interface = identifiers" 5.) Section 4. This section talks about the new IA_PA option but does not = explicitly say that this option needs to be inserted in SOLICIT message. 6.) As this procedure is indeed "state less" from the DHCPv6 perspective, w= hy don't we want to use "Information-Request" message instead of SOLICIT fr= om the host.? 7.) What should the host do after timers expire.? And is the DHCPv6 RECONFI= GURE message supported for this option type. I think this should be clarifi= ed in the draft. =20 Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Monday, August 13, 2012 7:35 AM To: dhc WG Subject: [MARKETING] [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 The authors have requested a working group last call for this draft. The = draft provides a mechanism whereby the DHCP server can indicate to the DHCP= client which prefix it should use for autoconfiguration, for instance for = CGA address generation. This draft has been hanging around for a while, a= nd could definitely use more eyes on it. Please take the time to review i= t; if you think it's a good idea, please indicate your support for advancin= g the draft. If you think it's a bad idea, please indicate that you do no= t support advancing it. If you have comments, they would be very much app= reciated. We will determine consensus on August 27. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Mon Aug 13 00:38:40 2012 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 90B3C21F863F for ; Mon, 13 Aug 2012 00:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 G+KSDVqibPvJ for ; Mon, 13 Aug 2012 00:38:38 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4621D21F8687 for ; Mon, 13 Aug 2012 00:38:38 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIU28818; Sun, 12 Aug 2012 23:38:34 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 00:35:30 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 00:35:30 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Mon, 13 Aug 2012 15:35:26 +0800 From: Sheng Jiang To: "Gaurav Halwasia (ghalwasi)" , Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9A= Date: Mon, 13 Aug 2012 07:35:26 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 13 Aug 2012 07:38:40 -0000 SGksIEdhdXJhdiwNCg0KVGhhbmtzIGZvciB5b3VyIGNhcmVmdWxseSByZXZpZXcuIFJlcGx5IGlu IGxpbmVzLiBXaXRoIGFsbCB5b3VyIGNvbW1lbnRzIGFkZHJlc3NlZCwgd291bGQgeW91IHN1cHBv cnQgdGhpcyBkb2N1bWVudCBmb3J3YXJkPw0KDQo+SSBsaWtlIHRoZSBpZGVhIGJ1dCBJIGRvIGhh dmUgZmV3IGNvbW1lbnRzOi0uDQo+DQo+MS4pIEFic3RyYWN0IGRvZXMgbm90IHNlZW1zIGNsZWFy IHRvIG1lLg0KPlRoaXMgZG9jdW1lbnQgaW50cm9kdWNlIGEgcHJvY2VkdXJlIGZvciBjb25maWd1 cmluZyBob3N0cycgSVB2Ng0KPiAgIGFkZHJlc3Mgd2hpY2ggdGhlIHByZWZpeCBpcyBhc3NpZ25l ZCBmcm9tIGEgREhDUHY2IHNlcnZlciB0aHJvdWdoDQo+ICAgREhDUHY2IHByb3RvY29sIHdoaWxl IHRoZSBpbnRlcmZhY2UgaWRlbnRpZmllcnMgYXJlIGluZGVwZW5kZW50bHkNCj4gICBnZW5lcmF0 ZWQgYnkgdGhlIGhvc3RzLg0KDQpSZXdvcmRlZDogVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEg bmV3IERIQ1B2NiBwcm9jZWR1cmUgdG8gY29uZmlndXJlIGhvc3RzJyBJUHY2IGFkZHJlc3Nlcy4g SW4gdGhpcyBuZXcgcHJvY2VkdXJlLCB0aGUgcHJlZml4IGlzIGFkdmVydGlzZWQgZnJvbSBhIERI Q1B2NiBzZXJ2ZXIgdGhyb3VnaCBESENQdjYgcHJvdG9jb2wgd2hpbGUgdGhlIGludGVyZmFjZSBp ZGVudGlmaWVycyBhcmUgaW5kZXBlbmRlbnRseSBnZW5lcmF0ZWQgYnkgdGhlIGhvc3RzLg0KDQo+ Mi4pIFNlY3Rpb24gMSAuIEludHJvZHVjdGlvbi4gQ2hhbmdlICJob3N0LWdlbmFyYXRlZCIgdG8g Imhvc3QtZ2VuZXJhdGVkIg0KPjMuKSBTZWN0aW9uIDEgLiBJbnRyb2R1Y3Rpb24uIENoYW5nZSAi c2VwYXJhdHMiIHRvICJzZXBhcmF0ZXMiDQo+NC4pIFNlY3Rpb24gMSAuIEludHJvZHVjdGlvbi4g Q2hhbmdlICJpbmdlcmZhY2UgaWRlbnRpZmllcnMiIHRvICJpbnRlcmZhY2UNCj5pZGVudGlmaWVy cyINCg0KQWxsIGNoYW5nZWQuDQoNCj41LikgU2VjdGlvbiA0LiAgVGhpcyBzZWN0aW9uIHRhbGtz IGFib3V0IHRoZSBuZXcgSUFfUEEgb3B0aW9uIGJ1dCBkb2VzIG5vdA0KPmV4cGxpY2l0bHkgc2F5 IHRoYXQgdGhpcyBvcHRpb24gbmVlZHMgdG8gYmUgaW5zZXJ0ZWQgaW4gU09MSUNJVCBtZXNzYWdl Lg0KDQpIYXZlIGFkZGVkIGEgc2VudGVuY2UgZm9yIHRoaXMuIEhvd2V2ZXIsIHRoaXMgaXMgb25s eSBhIE1BWS4gIkEgaG9zdCBNQVkgaW5jbHVkZSBhIE9wdGlvbiBSZXF1ZXN0IE9wdGlvbiBpbiBh IFNvbGljaXQgb3IgUmVxdWVzdCBtZXNzYWdlIHRvIHJlcXVlc3QgYSBJQV9QQSBleHBsaWNpdGx5 LiIgVGhlIHByZWZpeCBhc3NpZ25tZW50IGNvdWxkIGJlIGluIGFkdmVydGlzZSBtb2RlbC4gSXQg aXMgbm90IG5lY2Vzc2FyeSB0aGF0IGEgaG9zdCByZXF1ZXN0IGEgSUFfUEEuDQoNCj42LikgQXMg dGhpcyBwcm9jZWR1cmUgaXMgaW5kZWVkICJzdGF0ZSBsZXNzIiBmcm9tIHRoZSBESENQdjYgcGVy c3BlY3RpdmUsIHdoeQ0KPmRvbid0IHdlIHdhbnQgdG8gdXNlICJJbmZvcm1hdGlvbi1SZXF1ZXN0 IiBtZXNzYWdlIGluc3RlYWQgb2YgU09MSUNJVA0KPmZyb20gdGhlIGhvc3QuPw0KDQpSZXF1ZXN0 IG1lc3NhZ2UgaXMgcG9zc2libGUsIHRvby4gU2VlIHRoZSBhYm92ZSBuZXcgc2VudGVuY2UuDQoN Cj43LikgV2hhdCBzaG91bGQgdGhlIGhvc3QgZG8gYWZ0ZXIgdGltZXJzIGV4cGlyZS4/IEFuZCBp cyB0aGUgREhDUHY2DQo+UkVDT05GSUdVUkUgbWVzc2FnZSBzdXBwb3J0ZWQgZm9yIHRoaXMgb3B0 aW9uIHR5cGUuIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUNCj5jbGFyaWZpZWQgaW4gdGhlIGRyYWZ0 Lg0KDQpIYXZlIGFkZGVkIHR3byBzZW50ZW5jZXMgaW4gU2VjdGlvbiA0IHRvIGRlc2NyaWJlIHRo ZSBwb3RlbnRpYWwgZm9sbG93IHVwIG9wZXJhdGlvbjogDQoNCldoZW4gdGhlIGhvc3QgcmVhY2hl cyBUMSBvciBUMiBkZWZpbmVkIGluIFNlY3Rpb24gNS4xLCBpdCBTSE9VTEQgdXNlIHRoZSBzYW1l IG1lc3NhZ2UgZXhjaGFuZ2VzLCBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAxOCwgIkRIQ1AgQ2xp ZW50LUluaXRpYXRlZCBDb25maWd1cmF0aW9uIEV4Y2hhbmdlIiBvZiBbUkZDMzMxNV0sIHRvIG9i dGFpbiBvciB1cGRhdGUgcHJlZml4KGVzKSBmcm9tIGEgREhDUHY2IHNlcnZlci4NCg0KQSBESENQ djYgc2VydmVyIE1BWSBpbml0aWF0aXZlbHkgc2VuZCBhIHJlY29uZmlndXJhdGlvbiBtZXNzYWdl IHRvIHRoZSBob3N0LCBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAxOSwgIkRIQ1AgU2VydmVyLSBJ bml0aWF0ZWQgQ29uZmlndXJhdGlvbiBFeGNoYW5nZSIgb2YgW1JGQzMzMTVdLCB0byBjYXVzZSBw cmVmaXgoZXMpIGluZm9ybWF0aW9uIHVwZGF0ZS4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0K DQo+VGhhbmtzLA0KPkdhdXJhdg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJv bTogZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPk9mIFRlZCBMZW1vbg0KPlNlbnQ6IE1vbmRheSwgQXVndXN0IDEzLCAyMDEy IDc6MzUgQU0NCj5UbzogZGhjIFdHDQo+U3ViamVjdDogW01BUktFVElOR10gW2RoY3dnXSBXR0xD OiBkcmFmdC1pZXRmLWRoYy1ob3N0LWdlbi1pZC0wMg0KPg0KPlRoZSBhdXRob3JzIGhhdmUgcmVx dWVzdGVkIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIHRoaXMgZHJhZnQuICAgVGhlDQo+ ZHJhZnQgcHJvdmlkZXMgYSBtZWNoYW5pc20gd2hlcmVieSB0aGUgREhDUCBzZXJ2ZXIgY2FuIGlu ZGljYXRlIHRvIHRoZQ0KPkRIQ1AgY2xpZW50IHdoaWNoIHByZWZpeCBpdCBzaG91bGQgdXNlIGZv ciBhdXRvY29uZmlndXJhdGlvbiwgZm9yIGluc3RhbmNlIGZvcg0KPkNHQSBhZGRyZXNzIGdlbmVy YXRpb24uICAgVGhpcyBkcmFmdCBoYXMgYmVlbiBoYW5naW5nIGFyb3VuZCBmb3IgYSB3aGlsZSwN Cj5hbmQgY291bGQgZGVmaW5pdGVseSB1c2UgbW9yZSBleWVzIG9uIGl0LiAgIFBsZWFzZSB0YWtl IHRoZSB0aW1lIHRvIHJldmlldyBpdDsNCj5pZiB5b3UgdGhpbmsgaXQncyBhIGdvb2QgaWRlYSwg cGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBmb3IgYWR2YW5jaW5nIHRoZQ0KPmRyYWZ0LiAg IElmIHlvdSB0aGluayBpdCdzIGEgYmFkIGlkZWEsIHBsZWFzZSBpbmRpY2F0ZSB0aGF0IHlvdSBk byBub3Qgc3VwcG9ydA0KPmFkdmFuY2luZyBpdC4gICBJZiB5b3UgaGF2ZSBjb21tZW50cywgdGhl eSB3b3VsZCBiZSB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQuDQo+DQo+V2Ugd2lsbCBkZXRlcm1pbmUg Y29uc2Vuc3VzIG9uIEF1Z3VzdCAyNy4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPmRoY3dnIG1haWxpbmcgbGlzdA0KPmRoY3dnQGlldGYub3Jn DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBs aXN0DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RoY3dnDQo= From ghalwasi@cisco.com Mon Aug 13 01:13:35 2012 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 D5F3821F86BB for ; Mon, 13 Aug 2012 01:13:34 -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, 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 pq1NzJkGjPYK for ; Mon, 13 Aug 2012 01:13:33 -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 1FD3721F86A8 for ; Mon, 13 Aug 2012 01:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5272; q=dns/txt; s=iport; t=1344845613; x=1346055213; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dTlJ/KS9JtGU5vUF0MQcMnNfs/C2R9ytB4G/A4nDUUM=; b=kTFmTVD+8mDcanUH0u9b1t2MXe1z/djeUuQbe/8ZZmuDIrM/oQy/RH2z siM4O9rF9ShDZjwpQvPwhhf1p+CY76Xk67m4zPLSY567eQZ8q21aEpXqZ UfKNPKlizQ1kX33N+7KdqfyqzJAzLMunnpEUiWCzLcooxGzwMGJA7Vuqd 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHa2KFCtJXG8/2dsb2JhbABEgkq3LoEHgiABAQEEEgEaTBACAQgRBAEBCxkEBzIUCQgCBA4FCBqHa5dCn1KLEhqFN2ADnneEfoFmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,758,1336348800"; d="scan'208,217";a="107928871" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 13 Aug 2012 08:13:32 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7D8DWIa026019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 08:13:32 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 03:13:31 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , "Brzozowski, John" Thread-Topic: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) Thread-Index: AQHNdOXirwovxf8CZEyPfdn6AipKZpdPWhSAgAgTFmA= Date: Mon, 13 Aug 2012 08:13:31 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0D05FA@xmb-aln-x06.cisco.com> References: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> In-Reply-To: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.104.48] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19108.004 x-tm-as-result: No--40.653600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB0D05FAxmbalnx06ciscocom_" MIME-Version: 1.0 Cc: dhc WG , dhc Chairs , Haberman Brian , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 13 Aug 2012 08:13:35 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB0D05FAxmbalnx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in favor of adopting this draft as wg item. Thanks, Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, August 08, 2012 3:25 AM To: Brzozowski, John Cc: dhc WG; dhc Chairs; Haberman Brian; Ralph Droms (rdroms) Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL= _MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) On Aug 7, 2012, at 5:44 PM, Brzozowski, John wrote: If there are any questions or concerns regarding adopting this draft as a w= ork item for the dhcwg please send mail no later than August 21, 2012 5PM E= DT. Er, also if you favor adopting the draft please send mail! I'm in favor of adopting. --_000_90903C21C73202418A48BFBE80AEE5EB0D05FAxmbalnx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in favor of adopting this draft as wg item.

 

Thanks,

Gaurav<= /p>

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Wednesday, August 08, 2012 3:25 AM
To: Brzozowski, John
Cc: dhc WG; dhc Chairs; Haberman Brian; Ralph Droms (rdroms)
Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value= of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03)

 

On Aug 7, 2012, at 5:44 PM, Brzozowski, John wrote:<= o:p>

If t= here are any questions or concerns regarding adopting this draft as a work = item for the dhcwg please send mail no later than August 21, 2012 5PM EDT.

 

Er, also if you favor adopting the draft please send= mail!

 

I'm in favor of adopting.

 

--_000_90903C21C73202418A48BFBE80AEE5EB0D05FAxmbalnx06ciscocom_-- From xuxiaohu@huawei.com Mon Aug 13 03:08:37 2012 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 7886321F872D for ; Mon, 13 Aug 2012 03:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 Yb76gT72g23h for ; Mon, 13 Aug 2012 03:08:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E573A21F85D2 for ; Mon, 13 Aug 2012 03:08:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIV07283; Mon, 13 Aug 2012 02:08:36 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 03:05:11 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 03:05:12 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.5]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Mon, 13 Aug 2012 18:04:51 +0800 From: Xuxiaohu To: Ted Lemon , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNdvWqSDMOAnuzpUmlatl1eCUEGJdXh7mw Date: Mon, 13 Aug 2012 10:04:50 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0753FF61@szxeml525-mbx.china.huawei.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> In-Reply-To: <4D779082-B182-4728-9534-39456573682E@nominum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.24] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-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: Mon, 13 Aug 2012 10:08:37 -0000 DQpJJ20gaW4gZmF2b3Igb2YgYWR2YW5jaW5nIHRoaXMgZHJhZnQuDQoNClhpYW9odQ0KDQo+IC0t LS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFRlZA0KPiBMZW1vbg0KPiC3osvNyrG85Dog MjAxMsTqONTCMTDI1SAyMDo0Mw0KPiDK1bz+yMs6IGRoYyBXRw0KPiDW98ziOiBbZGhjd2ddIFdH TEM6IGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni10dW5uZWwtMDEudHh0DQo+IA0KPiBUaGUgYXV0aG9y cyBvZiB0aGlzIGRyYWZ0IGhhdmUgcmVxdWVzdGVkIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwu ICAgVGhlIGRyYWZ0DQo+IGV4cGxhaW5zIGhvdyBESENQIGNsaWVudHMgb3BlcmF0ZSBpbiBhbiBl bnZpcm9ubWVudCB3aGVyZSB0aGUgaW50ZXJmYWNlDQo+IGJlaW5nIGNvbmZpZ3VyZWQgZG9lc24n dCBzdXBwb3J0IG11bHRpY2FzdCAoZS5nLiwgNlJEKS4gICBJZiB0aGlzIGlzIGEgbWF0dGVyIG9m DQo+IGludGVyZXN0IHRvIHlvdSwgcGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHNlbmQgY29t bWVudHMgdG8gdGhlIGxpc3QuDQo+IA0KPiBJZiB5b3UgYXJlIGluIGZhdm9yIG9mIGFkdmFuY2lu ZyB0aGUgZHJhZnQsIHBsZWFzZSBzYXkgc28gb24gdGhlIGxpc3Q7IGlmIG5vYm9keQ0KPiBzdXBw b3J0cyBpdCwgaXQgd29uJ3QgYWR2YW5jZS4gICBJZiB5b3Ugb3Bwb3NlIGFkdmFuY2luZyBpdCwg cGxlYXNlIGFsc28gc2F5IHNvLg0KPiBXZSB3aWxsIGRldGVybWluZSBjb25zZW5zdXMgb24gQXVn dXN0IDI0Lg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+IGRoY3dnQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg== From magoyal@cisco.com Sun Aug 12 23:39:01 2012 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 0FD2221F84F5 for ; Sun, 12 Aug 2012 23:39:01 -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 zczGPp5Ny4cY for ; Sun, 12 Aug 2012 23:39:00 -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 5A0BB21F8589 for ; Sun, 12 Aug 2012 23:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=magoyal@cisco.com; l=781; q=dns/txt; s=iport; t=1344839940; x=1346049540; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=MMHj7ekwRy4L90L5tvxtmvNi0Ua4K1wbojRR+R/l6HM=; b=bqBfXm5OfCvjdhfvUnndB/AyMrfA6wVMfEaCH7t1BQMzonV5MzooXPaZ g+5AYNvuGIg/1HJzAbjbAaGv5mhC0KQScGeRqKn1hPhVDe7sjWlMfujNh oYuA623AzWLpCF5bD8D8Rx2MYo/fPwokJ4sDjEs2IbfXuWuX/MuE8ZxFO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAIqgKFCtJXG//2dsb2JhbABDhTq0PoEHgiABAQEEAQEBDwEKHTQXBAIBCBEEAQELFAkHJwsUCQgCBBMIGodrC5cin0IEixKFUWADo3WBZoJf X-IronPort-AV: E=Sophos;i="4.77,758,1336348800"; d="scan'208";a="110923471" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 13 Aug 2012 06:39:00 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7D6cxbq030973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 Aug 2012 06:38:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 01:38:59 -0500 From: "Manoj Kumar (magoyal)" To: "dhcwg@ietf.org" Thread-Topic: WGLC: draft-ietf-dhc-client-id-02 Thread-Index: AQHNdvzipwaJ7NUE4EeU+hu4IXKgZZdXTdqAgAAAo5A= Date: Mon, 13 Aug 2012 06:38:58 +0000 Message-ID: References: <1939A7BF-5F90-4801-9956-A21161F1B024@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D048F@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB0D048F@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.104.83] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19108.004 x-tm-as-result: No--32.877400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 13 Aug 2012 06:25:56 -0700 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 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, 13 Aug 2012 07:07:14 -0000 I support this work. Thanks, Manoj -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, August 10, 2012 7:05 PM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 The authors have requested a working group last call for this draft. This= is the document that clarifies the use of the DHCP client identifier by DH= CP servers, particularly in cases where chaddr is zero. Please review the= draft and indicate on the mailing list whether you support its advancement= or oppose its advancement. We will determine consensus on August 24. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From akostur@incognito.com Mon Aug 13 06:35:04 2012 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 7577521F8769 for ; Mon, 13 Aug 2012 06:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 LSBl0vNtjBUy for ; Mon, 13 Aug 2012 06:35:04 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with SMTP id B8A5E21F8767 for ; Mon, 13 Aug 2012 06:35:03 -0700 (PDT) Received: from mail-gg0-f174.google.com ([209.85.161.174]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKUCkChzq9NKJ9nXLorhpyVFbBXo7wWMMg@postini.com; Mon, 13 Aug 2012 06:35:03 PDT Received: by ggdk6 with SMTP id k6so3449695ggd.5 for ; Mon, 13 Aug 2012 06:35:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=EqC7oTgYufsdEOFhwu3jZcmVuwvBw4irckWSXiI8+w4=; b=PkjhdVk27CQCEH/twKolp7oT4Lgy7Wx9CqOutNdTOmVkj7KOmJrHT5ORL8DYpyXz6/ H9JmS+NXZx5Eoa5p2iWsFqfC61Otx2HA6WLg+k+Emw/z8GKZws6bJqJHArx4Qe1ZehzS LM1TWVYSCNuSuWI76fE/AvCi6lP8fmCWirdPBkX69rZxG0Xt6UikimwoUxHa0R3a1VHR ZLL84ontnTzryG2/TD+DAhGlwBY2EUjNf/DkZURWb5GzuMJCg7GLzHqavceO3vSt5Eps 604lP7TiBo/yScsJKWQVmV+yMWKCzVv8NkD19sXL3zD8fbcocYmBiUX4LzpKSHD+ujCp xRPA== MIME-Version: 1.0 Received: by 10.50.196.197 with SMTP id io5mr5421503igc.20.1344864902371; Mon, 13 Aug 2012 06:35:02 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Mon, 13 Aug 2012 06:35:02 -0700 (PDT) In-Reply-To: <1939A7BF-5F90-4801-9956-A21161F1B024@nominum.com> References: <1939A7BF-5F90-4801-9956-A21161F1B024@nominum.com> Date: Mon, 13 Aug 2012 06:35:02 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlk47DHTP7iR5lcfdY90F0sk1N/3oHvgAWwpKYEv85q75ha9Qee0JwaoP2PPBCdMcG45aRj Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 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, 13 Aug 2012 13:35:04 -0000 I support this draft. On Fri, Aug 10, 2012 at 6:34 AM, Ted Lemon wrote: > The authors have requested a working group last call for this draft. Th= is is the document that clarifies the use of the DHCP client identifier by = DHCP servers, particularly in cases where chaddr is zero. Please review t= he draft and indicate on the mailing list whether you support its advanceme= nt or oppose its advancement. > > We will determine consensus on August 24. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=20 Andre Kostur From volz@cisco.com Mon Aug 13 07:35:55 2012 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 0228721F8683 for ; Mon, 13 Aug 2012 07:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 nDSLLEW505vk for ; Mon, 13 Aug 2012 07:35:54 -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 482F621F8611 for ; Mon, 13 Aug 2012 07:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1471; q=dns/txt; s=iport; t=1344868554; x=1346078154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8Mp1AVw/S57UKXzyfg7RTW5r8bAbDS3IJFmUiB1v0A0=; b=MWpANXaB5WEOyFcAsjIkmPs/hMhLBZk+upqf25sGwuPf1XOfZLWHwZxu J/HDLdBJGvIldkOASTPi0UG84ED1n+Kr5Yyf212hqpl70VWi4wTqWVUeK h+ISz4pieUkZFWuL4HPBQ+rGgJepr1v06BiGbiRIf9+vJG7oVfSZU86/z 8=; X-IronPort-AV: E=Sophos;i="4.77,759,1336348800"; d="scan'208";a="111023630" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 13 Aug 2012 14:35:52 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7DEZqCo018867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 14:35:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 09:35:52 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNdvWqSDMOAnuzpUmlatl1eCUEGJdX0gXA Date: Mon, 13 Aug 2012 14:35:51 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> In-Reply-To: <4D779082-B182-4728-9534-39456573682E@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.186] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19108.006 x-tm-as-result: No--33.190700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ot@cisco.com" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-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: Mon, 13 Aug 2012 14:35:55 -0000 I am OK with advancing this. A few nits: - In section 1: The source tunnel end-point often need more configuration data for I think need should be needs here. - In section 3, "CE" and "BR" are not defined and should be the first time = used (or perhaps a terminology section is appropriate). Also, while relaying the packet seems like a fine idea, it might be useful = to indicate what the relay should use for a peer-address in the Relay-Forw = message. It is all 0's? (Normally the client's link local address would be = stored there.) - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, August 10, 2012 8:43 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt The authors of this draft have requested a working group last call. The d= raft explains how DHCP clients operate in an environment where the interfac= e being configured doesn't support multicast (e.g., 6RD). If this is a ma= tter of interest to you, please review the draft and send comments to the l= ist. If you are in favor of advancing the draft, please say so on the list; if n= obody supports it, it won't advance. If you oppose advancing it, please a= lso say so. We will determine consensus on August 24. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Aug 13 07:45:44 2012 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 BD29721F8513 for ; Mon, 13 Aug 2012 07:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 ngEeQYi9VGx2 for ; Mon, 13 Aug 2012 07:45: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 419FD21F84EB for ; Mon, 13 Aug 2012 07:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1241; q=dns/txt; s=iport; t=1344869144; x=1346078744; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=62Mx9gIqzYitAkRopYawCeTdnILr0WRHoAryoNJbPCM=; b=dKP+7uFwuBQ8XVawHVCcMzdbox6qO+vqgV6YwluyRj2UU997r3IgsYXn e3iDD0OdFku7LrIyZvQenYN/WwNQXUF9eXf7lfqs02udCrOUodEwE6sCO s8UUNmuvsxluHAay4SXcKfeHpNfdKQA9YYRR5vZZGB0cydmYME9oysMT3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFYSKVCtJXG//2dsb2JhbABFugWBB4IgAQEBBAEBAQ8BCh00CwwGAQgRBAEBCxQJLgsUCQkBBAENBQgah2sLl2+gDwSLEoVRYAOjdYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,761,1336348800"; d="scan'208";a="108040790" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 13 Aug 2012 14:45:43 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7DEjhEP015829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 14:45:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 09:45:43 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-client-id-02 [really -04] Thread-Index: Ac15YUfwlGgq0q+jR2GO+r7urotZWw== Date: Mon, 13 Aug 2012 14:45:43 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4EA3E4@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.248.186] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19108.006 x-tm-as-result: No--30.375200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "narasimha.nelakuditi@nokia.com" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 [really -04] 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, 13 Aug 2012 14:45:44 -0000 The current draft is 04, not 02. I am OK with advancing this draft. However, might be nice to also include DHCPINFORM in this document? The DHC= PACK sent in response should also include the Client Identifier option if s= ent in by the client (while this is generally not broadcast and may not suf= fer the same issues as the other messages, just be clean to allow the serve= r to have consistent processing to include the Client Identifier in all res= ponses to the client). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, August 10, 2012 9:35 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 The authors have requested a working group last call for this draft. This= is the document that clarifies the use of the DHCP client identifier by DH= CP servers, particularly in cases where chaddr is zero. Please review the= draft and indicate on the mailing list whether you support its advancement= or oppose its advancement. We will determine consensus on August 24. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ghalwasi@cisco.com Mon Aug 13 08:00:12 2012 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 99A5D21F877F for ; Mon, 13 Aug 2012 08:00:12 -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 miLBTYfJ1m+Y for ; Mon, 13 Aug 2012 08:00:10 -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 936FB21F877C for ; Mon, 13 Aug 2012 08:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=1950; q=dns/txt; s=iport; t=1344870010; x=1346079610; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=nje80hax1dh3rttuhrMUPMRQEu1xcOtRwTFko3Mgyio=; b=cWznJgveLaSEJC8DkAMxrkJYDlNyupBzuCiNGsgLg8egAoUkQIg7gPwZ pLrzy0d3GYKg0Ns6PSxQIP2kSYyFU9NqVb4GL1KhZ8Np/oEBnkIsPl2rg pwnCfcpuYIQdYUsTrfPk5mkhvLRlz8aoqEWrLqQ46sYIaQrLl+yzEc6BR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFMWKVCtJXG+/2dsb2JhbABFugWBB4IgAQEBBAEBAQ8BCh00CwwGAQgRBAEBCxQJLgsUCQkBBAENBQgah2sLl3igFQSLEoVRYAOjdYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,761,1336348800"; d="scan'208";a="110823342" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 13 Aug 2012 15:00:09 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7DF09nn006672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 15:00:09 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 10:00:08 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "Bernie Volz (volz)" , Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-client-id-04 Thread-Index: Ac15ZFIRL299vwF4RFu+DG7rWScoPw== Date: Mon, 13 Aug 2012 15:00:07 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0D0CF0@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.175] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19108.006 x-tm-as-result: No--38.365100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "narasimha.nelakuditi@nokia.com" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-04 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, 13 Aug 2012 15:00:12 -0000 Hi Bernie, Thanks for supporting. Yes, you are right. Version is 04. Regarding including reference to DHCPINFORM, I guess the document talks abo= ut server including 'Client Identifier' in OFFER/ACK/NAK irrespective of th= e message type from the client. Having said that, I think document in it's = current state actually covers this scenario as well. Please let me know if = you think otherwise. Thanks, Gaurav -----Original Message----- From: Bernie Volz (volz)=20 Sent: Monday, August 13, 2012 8:16 PM To: Ted Lemon; dhc WG Cc: narasimha.nelakuditi@nokia.com; Gaurav Halwasia (ghalwasi); Prashant Jh= ingran (pjhingra) Subject: RE: WGLC: draft-ietf-dhc-client-id-02 [really -04] The current draft is 04, not 02. I am OK with advancing this draft. However, might be nice to also include DHCPINFORM in this document? The DHC= PACK sent in response should also include the Client Identifier option if s= ent in by the client (while this is generally not broadcast and may not suf= fer the same issues as the other messages, just be clean to allow the serve= r to have consistent processing to include the Client Identifier in all res= ponses to the client). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, August 10, 2012 9:35 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 The authors have requested a working group last call for this draft. This= is the document that clarifies the use of the DHCP client identifier by DH= CP servers, particularly in cases where chaddr is zero. Please review the= draft and indicate on the mailing list whether you support its advancement= or oppose its advancement. We will determine consensus on August 24. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Aug 13 08:09:21 2012 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 629D821F8777 for ; Mon, 13 Aug 2012 08:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 MR+-U-ycKn7Z for ; Mon, 13 Aug 2012 08:09:20 -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 A1A4121F8751 for ; Mon, 13 Aug 2012 08:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=2326; q=dns/txt; s=iport; t=1344870560; x=1346080160; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=onhF+4bbL5YFCphJ6FvhKAshU+tA8rCKnh2hbK8LZkA=; b=IKCMaL1Mi6BPVtrCVSzOaSJ8SthH5GWRhavhlH/rrtr5tIkabtY/rO+H RFVJ4AweY8c1IEE+DuOS4Svbtj/ZfqS1WApmYssvxEPKFsK7gbNCCMoSl KUo4C9CZuk2NXqtZ8WU6Isu6FZhLU/cGfD/jHjnbaNSUbrADDJNf0R0md 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACYYKVCtJXG//2dsb2JhbABFugWBB4IgAQEBBAEBAQ8BCh00CwwEAgEIEQQBAQsUCQcnCxQJCAEBBAENBQgah2sLl3ygFwSLEoVRYAOjdYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,761,1336348800"; d="scan'208";a="111039194" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 13 Aug 2012 15:09:20 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7DF9J5f011091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Aug 2012 15:09:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 10:09:19 -0500 From: "Bernie Volz (volz)" To: "Gaurav Halwasia (ghalwasi)" , Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-client-id-04 Thread-Index: Ac15ZFIRL299vwF4RFu+DG7rWScoPwAASMRQ Date: Mon, 13 Aug 2012 15:09:18 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4EA450@xmb-rcd-x04.cisco.com> References: <90903C21C73202418A48BFBE80AEE5EB0D0CF0@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB0D0CF0@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.186] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19108.006 x-tm-as-result: No--39.734000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "narasimha.nelakuditi@nokia.com" Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-04 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, 13 Aug 2012 15:09:21 -0000 Yes, you are correct. The document is indeed just refers to the responses -= not the requests. - Bernie -----Original Message----- From: Gaurav Halwasia (ghalwasi)=20 Sent: Monday, August 13, 2012 11:00 AM To: Bernie Volz (volz); Ted Lemon; dhc WG Cc: narasimha.nelakuditi@nokia.com; Prashant Jhingran (pjhingra) Subject: RE: WGLC: draft-ietf-dhc-client-id-04 Hi Bernie, Thanks for supporting. Yes, you are right. Version is 04. Regarding including reference to DHCPINFORM, I guess the document talks abo= ut server including 'Client Identifier' in OFFER/ACK/NAK irrespective of th= e message type from the client. Having said that, I think document in it's = current state actually covers this scenario as well. Please let me know if = you think otherwise. Thanks, Gaurav -----Original Message----- From: Bernie Volz (volz)=20 Sent: Monday, August 13, 2012 8:16 PM To: Ted Lemon; dhc WG Cc: narasimha.nelakuditi@nokia.com; Gaurav Halwasia (ghalwasi); Prashant Jh= ingran (pjhingra) Subject: RE: WGLC: draft-ietf-dhc-client-id-02 [really -04] The current draft is 04, not 02. I am OK with advancing this draft. However, might be nice to also include DHCPINFORM in this document? The DHC= PACK sent in response should also include the Client Identifier option if s= ent in by the client (while this is generally not broadcast and may not suf= fer the same issues as the other messages, just be clean to allow the serve= r to have consistent processing to include the Client Identifier in all res= ponses to the client). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, August 10, 2012 9:35 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 The authors have requested a working group last call for this draft. This= is the document that clarifies the use of the DHCP client identifier by DH= CP servers, particularly in cases where chaddr is zero. Please review the= draft and indicate on the mailing list whether you support its advancement= or oppose its advancement. We will determine consensus on August 24. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Mon Aug 13 17:48:01 2012 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 7727A21F871D for ; Mon, 13 Aug 2012 17:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 PHWfJ2mYowHU for ; Mon, 13 Aug 2012 17:48:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BD4EE21F8705 for ; Mon, 13 Aug 2012 17:48:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJG50138; Mon, 13 Aug 2012 16:48:00 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 17:43:24 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Aug 2012 17:43:26 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Tue, 14 Aug 2012 08:43:20 +0800 From: Sheng Jiang To: Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-client-id-04 Thread-Index: Ac15ZFIRL299vwF4RFu+DG7rWScoPwAUWVSQ Date: Tue, 14 Aug 2012 00:43:18 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F05681@szxeml545-mbx.china.huawei.com> References: <90903C21C73202418A48BFBE80AEE5EB0D0CF0@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB0D0CF0@xmb-aln-x06.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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-04 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, 14 Aug 2012 00:48:01 -0000 U3VwcG9ydCB0byBhZHZhbmNlIHRoaXMgd29yay4NCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+RnJvbTogZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRoY3dn LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPk9mIEdhdXJhdiBIYWx3YXNpYSAoZ2hhbHdh c2kpDQo+U2VudDogTW9uZGF5LCBBdWd1c3QgMTMsIDIwMTIgMTE6MDAgUE0NCj5UbzogQmVybmll IFZvbHogKHZvbHopOyBUZWQgTGVtb247IGRoYyBXRw0KPkNjOiBuYXJhc2ltaGEubmVsYWt1ZGl0 aUBub2tpYS5jb20NCj5TdWJqZWN0OiBSZTogW2RoY3dnXSBXR0xDOiBkcmFmdC1pZXRmLWRoYy1j bGllbnQtaWQtMDQNCj4NCj5IaSBCZXJuaWUsDQo+DQo+VGhhbmtzIGZvciBzdXBwb3J0aW5nLiBZ ZXMsIHlvdSBhcmUgcmlnaHQuIFZlcnNpb24gaXMgMDQuDQo+DQo+UmVnYXJkaW5nIGluY2x1ZGlu ZyByZWZlcmVuY2UgdG8gREhDUElORk9STSwgSSBndWVzcyB0aGUgZG9jdW1lbnQgdGFsa3MNCj5h Ym91dCBzZXJ2ZXIgaW5jbHVkaW5nICdDbGllbnQgSWRlbnRpZmllcicgaW4gT0ZGRVIvQUNLL05B SyBpcnJlc3BlY3RpdmUgb2YgdGhlDQo+bWVzc2FnZSB0eXBlIGZyb20gdGhlIGNsaWVudC4gSGF2 aW5nIHNhaWQgdGhhdCwgSSB0aGluayBkb2N1bWVudCBpbiBpdCdzIGN1cnJlbnQNCj5zdGF0ZSBh Y3R1YWxseSBjb3ZlcnMgdGhpcyBzY2VuYXJpbyBhcyB3ZWxsLiBQbGVhc2UgbGV0IG1lIGtub3cg aWYgeW91IHRoaW5rDQo+b3RoZXJ3aXNlLg0KPg0KPlRoYW5rcywNCj5HYXVyYXYNCj4NCj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEJlcm5pZSBWb2x6ICh2b2x6KQ0KPlNlbnQ6 IE1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDg6MTYgUE0NCj5UbzogVGVkIExlbW9uOyBkaGMgV0cN Cj5DYzogbmFyYXNpbWhhLm5lbGFrdWRpdGlAbm9raWEuY29tOyBHYXVyYXYgSGFsd2FzaWEgKGdo YWx3YXNpKTsgUHJhc2hhbnQNCj5KaGluZ3JhbiAocGpoaW5ncmEpDQo+U3ViamVjdDogUkU6IFdH TEM6IGRyYWZ0LWlldGYtZGhjLWNsaWVudC1pZC0wMiBbcmVhbGx5IC0wNF0NCj4NCj5UaGUgY3Vy cmVudCBkcmFmdCBpcyAwNCwgbm90IDAyLg0KPg0KPkkgYW0gT0sgd2l0aCBhZHZhbmNpbmcgdGhp cyBkcmFmdC4NCj4NCj5Ib3dldmVyLCBtaWdodCBiZSBuaWNlIHRvIGFsc28gaW5jbHVkZSBESENQ SU5GT1JNIGluIHRoaXMgZG9jdW1lbnQ/IFRoZQ0KPkRIQ1BBQ0sgc2VudCBpbiByZXNwb25zZSBz aG91bGQgYWxzbyBpbmNsdWRlIHRoZSBDbGllbnQgSWRlbnRpZmllciBvcHRpb24gaWYNCj5zZW50 IGluIGJ5IHRoZSBjbGllbnQgKHdoaWxlIHRoaXMgaXMgZ2VuZXJhbGx5IG5vdCBicm9hZGNhc3Qg YW5kIG1heSBub3Qgc3VmZmVyDQo+dGhlIHNhbWUgaXNzdWVzIGFzIHRoZSBvdGhlciBtZXNzYWdl cywganVzdCBiZSBjbGVhbiB0byBhbGxvdyB0aGUgc2VydmVyIHRvDQo+aGF2ZSBjb25zaXN0ZW50 IHByb2Nlc3NpbmcgdG8gaW5jbHVkZSB0aGUgQ2xpZW50IElkZW50aWZpZXIgaW4gYWxsIHJlc3Bv bnNlcyB0bw0KPnRoZSBjbGllbnQpLg0KPg0KPi0gQmVybmllDQo+DQo+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj5Gcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ct Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+T2YgVGVkIExlbW9uDQo+U2VudDogRnJpZGF5 LCBBdWd1c3QgMTAsIDIwMTIgOTozNSBBTQ0KPlRvOiBkaGMgV0cNCj5TdWJqZWN0OiBbZGhjd2dd IFdHTEM6IGRyYWZ0LWlldGYtZGhjLWNsaWVudC1pZC0wMg0KPg0KPlRoZSBhdXRob3JzIGhhdmUg cmVxdWVzdGVkIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIHRoaXMgZHJhZnQuICAgVGhp cyBpcw0KPnRoZSBkb2N1bWVudCB0aGF0IGNsYXJpZmllcyB0aGUgdXNlIG9mIHRoZSBESENQIGNs aWVudCBpZGVudGlmaWVyIGJ5IERIQ1ANCj5zZXJ2ZXJzLCBwYXJ0aWN1bGFybHkgaW4gY2FzZXMg d2hlcmUgY2hhZGRyIGlzIHplcm8uICAgUGxlYXNlIHJldmlldyB0aGUgZHJhZnQNCj5hbmQgaW5k aWNhdGUgb24gdGhlIG1haWxpbmcgbGlzdCB3aGV0aGVyIHlvdSBzdXBwb3J0IGl0cyBhZHZhbmNl bWVudCBvcg0KPm9wcG9zZSBpdHMgYWR2YW5jZW1lbnQuDQo+DQo+V2Ugd2lsbCBkZXRlcm1pbmUg Y29uc2Vuc3VzIG9uIEF1Z3VzdCAyNC4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPmRoY3dnIG1haWxpbmcgbGlzdA0KPmRoY3dnQGlldGYub3Jn DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBs aXN0DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RoY3dnDQo= From internet-drafts@ietf.org Mon Aug 13 19:33:01 2012 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 C8D5421F871D; Mon, 13 Aug 2012 19:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 7xeH881dkVtE; Mon, 13 Aug 2012 19:33:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315DC21F876F; Mon, 13 Aug 2012 19:33:01 -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.33 Message-ID: <20120814023301.12939.59518.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2012 19:33:01 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-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: Tue, 14 Aug 2012 02:33:02 -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 : Client Link-layer Address Option in DHCPv6 Author(s) : Gaurav Halwasia Shwetha Bhandari Wojciech Dec Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt Pages : 6 Date : 2012-08-13 Abstract: This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 relay forward messages by defining a new DHCPv6 Client Link-layer Address option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-ad= dr-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt= -01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-client-link-layer-= addr-opt-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shwethab@cisco.com Mon Aug 13 23:12:49 2012 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 95FAD11E80A4 for ; Mon, 13 Aug 2012 23:12:49 -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 yd+9zVkLKDjt for ; Mon, 13 Aug 2012 23:12:49 -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 DD0A611E809C for ; Mon, 13 Aug 2012 23:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shwethab@cisco.com; l=2786; q=dns/txt; s=iport; t=1344924769; x=1346134369; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=z2veS/WzLD6LuZRN2ATxIQJQcvBoQrkyGDvzZzYOGdA=; b=Le+NmpT7Q0i44RCtv3DMd3Nff05GxdC83TIGljIXBw/jQ4Q5mdc4PsIc 78dYg7fK6WdG/l6/gJEW/tqAFwSauW57uV1VVUlafeYW4cWbrbFVbJ/v7 h4kBvrjAfhMW2zA/KqRpqyR4+viN8KMvI/zEGIOzZMco2cRNCy44okICe o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADLrKVCtJXG+/2dsb2JhbABFug2BB4IgAQEBBAEBAQ8BCh00FwYBCBEEAQEfCS4LFAkIAQEEARIih2sLmBagfASLEoYxA5VLjiqBZoJf X-IronPort-AV: E=Sophos;i="4.77,764,1336348800"; d="scan'208";a="111298691" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 14 Aug 2012 06:12:48 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7E6Cm9k023980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Aug 2012 06:12:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 01:12:47 -0500 From: "Shwetha Bhandari (shwethab)" To: Ted Lemon , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-client-id-04 Thread-Index: Ac15ZFIRL299vwF4RFu+DG7rWScoPwAUWVSQACGG+YA= Date: Tue, 14 Aug 2012 06:12:47 +0000 Message-ID: In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F05681@szxeml545-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.0.0.100825 x-originating-ip: [10.142.104.149] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19112.003 x-tm-as-result: No--44.512700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-04 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, 14 Aug 2012 06:12:49 -0000 I support this work too. On 8/14/12 6:13 AM, "Sheng Jiang" wrote: >Support to advance this work. > >Sheng > >>-----Original Message----- >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>Of Gaurav Halwasia (ghalwasi) >>Sent: Monday, August 13, 2012 11:00 PM >>To: Bernie Volz (volz); Ted Lemon; dhc WG >>Cc: narasimha.nelakuditi@nokia.com >>Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-client-id-04 >> >>Hi Bernie, >> >>Thanks for supporting. Yes, you are right. Version is 04. >> >>Regarding including reference to DHCPINFORM, I guess the document talks >>about server including 'Client Identifier' in OFFER/ACK/NAK irrespective >>of the >>message type from the client. Having said that, I think document in it's >>current >>state actually covers this scenario as well. Please let me know if you >>think >>otherwise. >> >>Thanks, >>Gaurav >> >>-----Original Message----- >>From: Bernie Volz (volz) >>Sent: Monday, August 13, 2012 8:16 PM >>To: Ted Lemon; dhc WG >>Cc: narasimha.nelakuditi@nokia.com; Gaurav Halwasia (ghalwasi); Prashant >>Jhingran (pjhingra) >>Subject: RE: WGLC: draft-ietf-dhc-client-id-02 [really -04] >> >>The current draft is 04, not 02. >> >>I am OK with advancing this draft. >> >>However, might be nice to also include DHCPINFORM in this document? The >>DHCPACK sent in response should also include the Client Identifier >>option if >>sent in by the client (while this is generally not broadcast and may not >>suffer >>the same issues as the other messages, just be clean to allow the server >>to >>have consistent processing to include the Client Identifier in all >>responses to >>the client). >> >>- Bernie >> >>-----Original Message----- >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >>Of Ted Lemon >>Sent: Friday, August 10, 2012 9:35 AM >>To: dhc WG >>Subject: [dhcwg] WGLC: draft-ietf-dhc-client-id-02 >> >>The authors have requested a working group last call for this draft. >>This is >>the document that clarifies the use of the DHCP client identifier by DHCP >>servers, particularly in cases where chaddr is zero. Please review the >>draft >>and indicate on the mailing list whether you support its advancement or >>oppose its advancement. >> >>We will determine consensus on August 24. >> >>_______________________________________________ >>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 >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From shwethab@cisco.com Mon Aug 13 23:13:34 2012 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 27AAD11E80BF for ; Mon, 13 Aug 2012 23:13:34 -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 n6BqaCBkDDSp for ; Mon, 13 Aug 2012 23:13:33 -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 530A811E809C for ; Mon, 13 Aug 2012 23:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1017; q=dns/txt; s=iport; t=1344924813; x=1346134413; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1T788m/IZKr7/4v4asLBdby0NqZsO6pYJCmr5h+4+qo=; b=Khp+9gBIWMLTbnnbeZb3xmRCRADNNmUh1qIvr0jbxrC7uf254MEH+W6M Vl1KVAi2/l0ZUFCUBIj6ngffQQ6aTdyOfM9G7thPYDR4r3AhJXCgsOyW1 VT3pb+PTkkyfBi9DB81lBn69+g0AUkqtBYhZKtuhrG9WfQUV1G0UdGlBR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOPrKVCtJXG+/2dsb2JhbABFug2BB4IgAQEBAwEBAQEPASc0CxIBCBcfBTILHQgCBAENBSKHZQYLmBehAIsSGoYXA5VLgRSIGIR+gWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,764,1336348800"; d="scan'208";a="108300726" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 14 Aug 2012 06:13:32 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7E6DWvJ024575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Aug 2012 06:13:32 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 01:13:32 -0500 From: "Shwetha Bhandari (shwethab)" To: "Brzozowski, John" , dhc WG Thread-Topic: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) Thread-Index: AQHNdOXirwovxf8CZEyPfdn6AipKZpdQkBKggADpudCACBRHAA== Date: Tue, 14 Aug 2012 06:13:32 +0000 Message-ID: In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61115CDEC@GAALPA1MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.142.104.149] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19112.003 x-tm-as-result: No--36.064700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <0F012A0E22146043B44FA092D1C03AB9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc Chairs , "Ralph Droms \(rdroms\)" Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 14 Aug 2012 06:13:34 -0000 +1 Shwetha > >> Support the adoption. >>=20 >> >Subject: [dhcwg] ADOPTION REQUEST: Modification to Default Value of >> >SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) >> > >> >Folks, >> > >> >The following draft was discussed during dhcwg meeting during IETF83. >> >The draft was recently updated after being expired for a short period. >> >Based on the identified need and interest in this topic I have >> >conferred with Ted and our ADs regarding next steps. As such I would >> >like to initiate a call to adopt this draft as a working group work >>item: >> > >> >http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-solmaxrt-update-03 >> > >> >If there are any questions or concerns regarding adopting this draft as >> >a work item for the dhcwg please send mail no later than August 21, >>2012 >> 5PM EDT. >> > >> >Thank you, >> > >> >John >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From leo.liubing@huawei.com Tue Aug 14 01:02:46 2012 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 E3E2E21F85AC for ; Tue, 14 Aug 2012 01:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.306 X-Spam-Level: X-Spam-Status: No, score=-6.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 MidkpesFtfhK for ; Tue, 14 Aug 2012 01:02:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB6421F86D1 for ; Tue, 14 Aug 2012 01:02:46 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIV89117; Tue, 14 Aug 2012 00:02:45 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 00:58:41 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 00:58:44 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Tue, 14 Aug 2012 15:58:37 +0800 From: "Liubing (Leo)" To: Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdY5bRA Date: Tue, 14 Aug 2012 07:58:36 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F452932EAEC@szxeml509-mbs> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> In-Reply-To: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 14 Aug 2012 08:02:47 -0000 Support advancing it. Few minor comments: Section 3, first paragraph. It is not proper to say routers can "specify" t= he hosts should use DHCPv6 and/or stateless address configuration. In fact = the RFC4862 doesn't clearly defined the hosts should interpret the M/O flag= s as prescriptive, but just advisory. In other word, it is not determined b= y the routers, but the hosts themselves.=20 In last paragraph of section 4, what is the "address registration procedure= "? Do you mean the procedure defined in draft-ietf-dhc-addr-registration ? = If it is, it's better to add a reference. -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Monday, August 13, 2012 10:05 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 The authors have requested a working group last call for this draft. The = draft provides a mechanism whereby the DHCP server can indicate to the DHCP= client which prefix it should use for autoconfiguration, for instance for = CGA address generation. This draft has been hanging around for a while, a= nd could definitely use more eyes on it. Please take the time to review i= t; if you think it's a good idea, please indicate your support for advancin= g the draft. If you think it's a bad idea, please indicate that you do no= t support advancing it. If you have comments, they would be very much app= reciated. We will determine consensus on August 27. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Tue Aug 14 02:31:08 2012 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 B423A21F85DA for ; Tue, 14 Aug 2012 02:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.306 X-Spam-Level: X-Spam-Status: No, score=-6.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 R6QABzBbXCdo for ; Tue, 14 Aug 2012 02:31:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D2D6821F8548 for ; Tue, 14 Aug 2012 02:31:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIV94688; Tue, 14 Aug 2012 01:31:02 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 02:26:38 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 02:26:37 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Tue, 14 Aug 2012 17:26:25 +0800 From: Sheng Jiang To: "Liubing (Leo)" , Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdY5bRAgAAkl+A= Date: Tue, 14 Aug 2012 09:26:24 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F059F5@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F452932EAEC@szxeml509-mbs> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F452932EAEC@szxeml509-mbs> 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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 14 Aug 2012 09:31:08 -0000 SGksIEJpbmcsDQoNClRoYW5rcyBmb3IgeW91ciBzdXBwb3J0IGFuZCBjb21tZW50cy4gU2VlIG15 IHJlcGxpZXMgaW4gbGluZXMuDQoNClJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3 Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBMaXViaW5nIChMZW8pDQo+U2VudDog VHVlc2RheSwgQXVndXN0IDE0LCAyMDEyIDM6NTkgUE0NCj5UbzogVGVkIExlbW9uOyBkaGMgV0cN Cj5TdWJqZWN0OiBSZTogW2RoY3dnXSBXR0xDOiBkcmFmdC1pZXRmLWRoYy1ob3N0LWdlbi1pZC0w Mg0KPg0KPlN1cHBvcnQgYWR2YW5jaW5nIGl0LiBGZXcgbWlub3IgY29tbWVudHM6DQo+DQo+U2Vj dGlvbiAzLCBmaXJzdCBwYXJhZ3JhcGguIEl0IGlzIG5vdCBwcm9wZXIgdG8gc2F5IHJvdXRlcnMg Y2FuICJzcGVjaWZ5IiB0aGUNCj5ob3N0cyBzaG91bGQgdXNlIERIQ1B2NiBhbmQvb3Igc3RhdGVs ZXNzIGFkZHJlc3MgY29uZmlndXJhdGlvbi4gSW4gZmFjdCB0aGUNCj5SRkM0ODYyIGRvZXNuJ3Qg Y2xlYXJseSBkZWZpbmVkIHRoZSBob3N0cyBzaG91bGQgaW50ZXJwcmV0IHRoZSBNL08gZmxhZ3Mg YXMNCj5wcmVzY3JpcHRpdmUsIGJ1dCBqdXN0IGFkdmlzb3J5LiBJbiBvdGhlciB3b3JkLCBpdCBp cyBub3QgZGV0ZXJtaW5lZCBieSB0aGUNCj5yb3V0ZXJzLCBidXQgdGhlIGhvc3RzIHRoZW1zZWx2 ZXMuDQoNClRoaXMgc2VudGVuY2UgaXMgYWxtb3N0IHRoZSBzYW1lIHdpdGggb3JpZ2luYWwgc2Vu dGVuY2UgaW4gUkZDNDg2MiwgaW5jbHVkaW5nIHRoZSB3b3JkICJzcGVjaWZ5Ii4gVGhlIG9iamVj dCBvZiAic3BlY2lmeSIgaXMgYSAic2hvdWxkIiwgcmF0aGVyIHRoYW4gIk1VU1QiLiBTbywgcm91 dGVyIGlzIG5vdCBkZXRlcm1pbmVkIHRoZSBhZGRyZXNzIGNvbmZpZ3VyYXRpb24gbW9kZWwuIFJv dXRlciBnaXZlcyBhZHZpY2VzLiBUaGlzIGRlc2NyaXB0aW9uIGlzIGNvbXBhdGlibGUgd2l0aCB5 b3VyIHVuZGVyc3RhbmRpbmcsIEkgYmVsaWV2ZS4gDQoNCj5JbiBsYXN0IHBhcmFncmFwaCBvZiBz ZWN0aW9uIDQsIHdoYXQgaXMgdGhlICJhZGRyZXNzIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmUiPw0K PkRvIHlvdSBtZWFuIHRoZSBwcm9jZWR1cmUgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLWRoYy1hZGRy LXJlZ2lzdHJhdGlvbiA/IElmIGl0IGlzLA0KPml0J3MgYmV0dGVyIHRvIGFkZCBhIHJlZmVyZW5j ZS4NCg0KRWNoby4gVGhhbmtzLg0KDQpTaGVuZw0KDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj5Gcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+T2YgVGVkIExlbW9uDQo+U2VudDogTW9uZGF5LCBBdWd1 c3QgMTMsIDIwMTIgMTA6MDUgQU0NCj5UbzogZGhjIFdHDQo+U3ViamVjdDogW2RoY3dnXSBXR0xD OiBkcmFmdC1pZXRmLWRoYy1ob3N0LWdlbi1pZC0wMg0KPg0KPlRoZSBhdXRob3JzIGhhdmUgcmVx dWVzdGVkIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIHRoaXMgZHJhZnQuICAgVGhlDQo+ ZHJhZnQgcHJvdmlkZXMgYSBtZWNoYW5pc20gd2hlcmVieSB0aGUgREhDUCBzZXJ2ZXIgY2FuIGlu ZGljYXRlIHRvIHRoZQ0KPkRIQ1AgY2xpZW50IHdoaWNoIHByZWZpeCBpdCBzaG91bGQgdXNlIGZv ciBhdXRvY29uZmlndXJhdGlvbiwgZm9yIGluc3RhbmNlIGZvcg0KPkNHQSBhZGRyZXNzIGdlbmVy YXRpb24uICAgVGhpcyBkcmFmdCBoYXMgYmVlbiBoYW5naW5nIGFyb3VuZCBmb3IgYSB3aGlsZSwN Cj5hbmQgY291bGQgZGVmaW5pdGVseSB1c2UgbW9yZSBleWVzIG9uIGl0LiAgIFBsZWFzZSB0YWtl IHRoZSB0aW1lIHRvIHJldmlldyBpdDsNCj5pZiB5b3UgdGhpbmsgaXQncyBhIGdvb2QgaWRlYSwg cGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBmb3IgYWR2YW5jaW5nIHRoZQ0KPmRyYWZ0LiAg IElmIHlvdSB0aGluayBpdCdzIGEgYmFkIGlkZWEsIHBsZWFzZSBpbmRpY2F0ZSB0aGF0IHlvdSBk byBub3Qgc3VwcG9ydA0KPmFkdmFuY2luZyBpdC4gICBJZiB5b3UgaGF2ZSBjb21tZW50cywgdGhl eSB3b3VsZCBiZSB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQuDQo+DQo+V2Ugd2lsbCBkZXRlcm1pbmUg Y29uc2Vuc3VzIG9uIEF1Z3VzdCAyNy4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPmRoY3dnIG1haWxpbmcgbGlzdA0KPmRoY3dnQGlldGYub3Jn DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBs aXN0DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RoY3dnDQo= From ghalwasi@cisco.com Tue Aug 14 03:26:51 2012 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 74A6621F859B for ; Tue, 14 Aug 2012 03:26: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=[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 y-SAKKCxiz+F for ; Tue, 14 Aug 2012 03:26:50 -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 739A521F85D8 for ; Tue, 14 Aug 2012 03:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=5752; q=dns/txt; s=iport; t=1344940010; x=1346149610; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UIaJ1GXkftjTtwBK0lR2E+qaBntvO0scTCkyLl6IJWI=; b=ZOPmlxAEAeyHt6f3msrs25vHovzyxkPlqd/kiIeRNtxrdpvj3ize6KbZ 1Iecl8N1dtl3qsCJWI5vHEqfHxXJ+RJfI19fbIC3g4vezP1SCi+INsfmj 6QRxmfBvUkHly31x8gzaEzyUlfPLTiHK9ax9poVg/9UM1xyOahb39mp+Z M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAF8nKlCtJXHA/2dsb2JhbABEhgGzKWWBB4IgAQEBBAEBAQ8BCgYROgEWBAIBCBEEAQEDAgYdAwICAiULFAEICAIEARIIGodrC5gXjRmTdASBIYlkhR8yYAOjdYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,765,1336348800"; d="scan'208";a="111356826" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 14 Aug 2012 10:26:50 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7EAQngh012616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Aug 2012 10:26:49 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 05:26:49 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Sheng Jiang , Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoA== Date: Tue, 14 Aug 2012 10:26:49 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.143] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19112.005 x-tm-as-result: No--47.306100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 14 Aug 2012 10:26:51 -0000 SGkgU2hlbmcsDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpUaGFua3MsDQpHYXVyYXYNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNoZW5nIEppYW5nIFttYWlsdG86amlhbmdz aGVuZ0BodWF3ZWkuY29tXSANClNlbnQ6IE1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDE6MDUgUE0N ClRvOiBHYXVyYXYgSGFsd2FzaWEgKGdoYWx3YXNpKTsgVGVkIExlbW9uOyBkaGMgV0cNClN1Ympl Y3Q6IFJFOiBXR0xDOiBkcmFmdC1pZXRmLWRoYy1ob3N0LWdlbi1pZC0wMg0KDQpIaSwgR2F1cmF2 LA0KDQpUaGFua3MgZm9yIHlvdXIgY2FyZWZ1bGx5IHJldmlldy4gUmVwbHkgaW4gbGluZXMuIFdp dGggYWxsIHlvdXIgY29tbWVudHMgYWRkcmVzc2VkLCB3b3VsZCB5b3Ugc3VwcG9ydCB0aGlzIGRv Y3VtZW50IGZvcndhcmQ/DQpbR2F1cmF2XSBDZXJ0YWlubHkuIEkgc3VwcG9ydCB0aGUgZG9jdW1l bnQgZm9yd2FyZC4NCg0KPkkgbGlrZSB0aGUgaWRlYSBidXQgSSBkbyBoYXZlIGZldyBjb21tZW50 czotLg0KPg0KPjEuKSBBYnN0cmFjdCBkb2VzIG5vdCBzZWVtcyBjbGVhciB0byBtZS4NCj5UaGlz IGRvY3VtZW50IGludHJvZHVjZSBhIHByb2NlZHVyZSBmb3IgY29uZmlndXJpbmcgaG9zdHMnIElQ djYNCj4gICBhZGRyZXNzIHdoaWNoIHRoZSBwcmVmaXggaXMgYXNzaWduZWQgZnJvbSBhIERIQ1B2 NiBzZXJ2ZXIgdGhyb3VnaA0KPiAgIERIQ1B2NiBwcm90b2NvbCB3aGlsZSB0aGUgaW50ZXJmYWNl IGlkZW50aWZpZXJzIGFyZSBpbmRlcGVuZGVudGx5DQo+ICAgZ2VuZXJhdGVkIGJ5IHRoZSBob3N0 cy4NCg0KUmV3b3JkZWQ6IFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBhIG5ldyBESENQdjYgcHJv Y2VkdXJlIHRvIGNvbmZpZ3VyZSBob3N0cycgSVB2NiBhZGRyZXNzZXMuIEluIHRoaXMgbmV3IHBy b2NlZHVyZSwgdGhlIHByZWZpeCBpcyBhZHZlcnRpc2VkIGZyb20gYSBESENQdjYgc2VydmVyIHRo cm91Z2ggREhDUHY2IHByb3RvY29sIHdoaWxlIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmllcnMgYXJl IGluZGVwZW5kZW50bHkgZ2VuZXJhdGVkIGJ5IHRoZSBob3N0cy4NCg0KPjIuKSBTZWN0aW9uIDEg LiBJbnRyb2R1Y3Rpb24uIENoYW5nZSAiaG9zdC1nZW5hcmF0ZWQiIHRvICJob3N0LWdlbmVyYXRl ZCINCj4zLikgU2VjdGlvbiAxIC4gSW50cm9kdWN0aW9uLiBDaGFuZ2UgInNlcGFyYXRzIiB0byAi c2VwYXJhdGVzIg0KPjQuKSBTZWN0aW9uIDEgLiBJbnRyb2R1Y3Rpb24uIENoYW5nZSAiaW5nZXJm YWNlIGlkZW50aWZpZXJzIiB0byANCj4iaW50ZXJmYWNlIGlkZW50aWZpZXJzIg0KDQpBbGwgY2hh bmdlZC4NCg0KPjUuKSBTZWN0aW9uIDQuICBUaGlzIHNlY3Rpb24gdGFsa3MgYWJvdXQgdGhlIG5l dyBJQV9QQSBvcHRpb24gYnV0IGRvZXMgDQo+bm90IGV4cGxpY2l0bHkgc2F5IHRoYXQgdGhpcyBv cHRpb24gbmVlZHMgdG8gYmUgaW5zZXJ0ZWQgaW4gU09MSUNJVCBtZXNzYWdlLg0KDQpIYXZlIGFk ZGVkIGEgc2VudGVuY2UgZm9yIHRoaXMuIEhvd2V2ZXIsIHRoaXMgaXMgb25seSBhIE1BWS4gIkEg aG9zdCBNQVkgaW5jbHVkZSBhIE9wdGlvbiBSZXF1ZXN0IE9wdGlvbiBpbiBhIFNvbGljaXQgb3Ig UmVxdWVzdCBtZXNzYWdlIHRvIHJlcXVlc3QgYSBJQV9QQSBleHBsaWNpdGx5LiIgVGhlIHByZWZp eCBhc3NpZ25tZW50IGNvdWxkIGJlIGluIGFkdmVydGlzZSBtb2RlbC4gSXQgaXMgbm90IG5lY2Vz c2FyeSB0aGF0IGEgaG9zdCByZXF1ZXN0IGEgSUFfUEEuDQpbR2F1cmF2XSBJIGRvbid0IHVuZGVy c3RhbmQgdGhpcyBwYXJ0IGNvbXBsZXRlbHkuIFNvIHlvdSBhcmUgc2F5aW5nIHRoYXQgaG9zdCBj YW4gc2VuZCAiREhDUCBSRVFVRVNUIiBtZXNzYWdlIGFzIHdlbGwgaW5zdGVhZCBvZiBTT0xJQ0lU Lj8gQ2FuIHlvdSBwbGVhc2UgZWxhYm9yYXRlIGl0IGluIGRldGFpbC4gDQoNCj42LikgQXMgdGhp cyBwcm9jZWR1cmUgaXMgaW5kZWVkICJzdGF0ZSBsZXNzIiBmcm9tIHRoZSBESENQdjYgDQo+cGVy c3BlY3RpdmUsIHdoeSBkb24ndCB3ZSB3YW50IHRvIHVzZSAiSW5mb3JtYXRpb24tUmVxdWVzdCIg bWVzc2FnZSANCj5pbnN0ZWFkIG9mIFNPTElDSVQgZnJvbSB0aGUgaG9zdC4/DQoNClJlcXVlc3Qg bWVzc2FnZSBpcyBwb3NzaWJsZSwgdG9vLiBTZWUgdGhlIGFib3ZlIG5ldyBzZW50ZW5jZS4NCg0K W0dhdXJhdl0gSSB3YXMgcmVmZXJyaW5nIHRvICJJbmZvcm1hdGlvbi1SZXF1ZXN0KDExKSIgbWVz c2FnZSBub3QgICJSZXF1ZXN0KDMpIg0KDQoNCj43LikgV2hhdCBzaG91bGQgdGhlIGhvc3QgZG8g YWZ0ZXIgdGltZXJzIGV4cGlyZS4/IEFuZCBpcyB0aGUgREhDUHY2IA0KPlJFQ09ORklHVVJFIG1l c3NhZ2Ugc3VwcG9ydGVkIGZvciB0aGlzIG9wdGlvbiB0eXBlLiBJIHRoaW5rIHRoaXMgc2hvdWxk IA0KPmJlIGNsYXJpZmllZCBpbiB0aGUgZHJhZnQuDQoNCkhhdmUgYWRkZWQgdHdvIHNlbnRlbmNl cyBpbiBTZWN0aW9uIDQgdG8gZGVzY3JpYmUgdGhlIHBvdGVudGlhbCBmb2xsb3cgdXAgb3BlcmF0 aW9uOiANCg0KV2hlbiB0aGUgaG9zdCByZWFjaGVzIFQxIG9yIFQyIGRlZmluZWQgaW4gU2VjdGlv biA1LjEsIGl0IFNIT1VMRCB1c2UgdGhlIHNhbWUgbWVzc2FnZSBleGNoYW5nZXMsIGFzIGRlc2Ny aWJlZCBpbiBzZWN0aW9uIDE4LCAiREhDUCBDbGllbnQtSW5pdGlhdGVkIENvbmZpZ3VyYXRpb24g RXhjaGFuZ2UiIG9mIFtSRkMzMzE1XSwgdG8gb2J0YWluIG9yIHVwZGF0ZSBwcmVmaXgoZXMpIGZy b20gYSBESENQdjYgc2VydmVyLg0KDQpBIERIQ1B2NiBzZXJ2ZXIgTUFZIGluaXRpYXRpdmVseSBz ZW5kIGEgcmVjb25maWd1cmF0aW9uIG1lc3NhZ2UgdG8gdGhlIGhvc3QsIGFzIGRlc2NyaWJlZCBp biBzZWN0aW9uIDE5LCAiREhDUCBTZXJ2ZXItIEluaXRpYXRlZCBDb25maWd1cmF0aW9uIEV4Y2hh bmdlIiBvZiBbUkZDMzMxNV0sIHRvIGNhdXNlIHByZWZpeChlcykgaW5mb3JtYXRpb24gdXBkYXRl Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj5UaGFua3MsDQo+R2F1cmF2DQo+DQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIA0KPk9mIFRlZCBMZW1vbg0K PlNlbnQ6IE1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDc6MzUgQU0NCj5UbzogZGhjIFdHDQo+U3Vi amVjdDogW01BUktFVElOR10gW2RoY3dnXSBXR0xDOiBkcmFmdC1pZXRmLWRoYy1ob3N0LWdlbi1p ZC0wMg0KPg0KPlRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVkIGEgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgZm9yIHRoaXMgZHJhZnQuICAgVGhlDQo+ZHJhZnQgcHJvdmlkZXMgYSBtZWNoYW5pc20g d2hlcmVieSB0aGUgREhDUCBzZXJ2ZXIgY2FuIGluZGljYXRlIHRvIHRoZSANCj5ESENQIGNsaWVu dCB3aGljaCBwcmVmaXggaXQgc2hvdWxkIHVzZSBmb3IgYXV0b2NvbmZpZ3VyYXRpb24sIGZvciBp bnN0YW5jZSBmb3INCj5DR0EgYWRkcmVzcyBnZW5lcmF0aW9uLiAgIFRoaXMgZHJhZnQgaGFzIGJl ZW4gaGFuZ2luZyBhcm91bmQgZm9yIGEgd2hpbGUsDQo+YW5kIGNvdWxkIGRlZmluaXRlbHkgdXNl IG1vcmUgZXllcyBvbiBpdC4gICBQbGVhc2UgdGFrZSB0aGUgdGltZSB0byByZXZpZXcgaXQ7DQo+ aWYgeW91IHRoaW5rIGl0J3MgYSBnb29kIGlkZWEsIHBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBv cnQgZm9yIGFkdmFuY2luZyB0aGUNCj5kcmFmdC4gICBJZiB5b3UgdGhpbmsgaXQncyBhIGJhZCBp ZGVhLCBwbGVhc2UgaW5kaWNhdGUgdGhhdCB5b3UgZG8gbm90IHN1cHBvcnQNCj5hZHZhbmNpbmcg aXQuICAgSWYgeW91IGhhdmUgY29tbWVudHMsIHRoZXkgd291bGQgYmUgdmVyeSBtdWNoIGFwcHJl Y2lhdGVkLg0KPg0KPldlIHdpbGwgZGV0ZXJtaW5lIGNvbnNlbnN1cyBvbiBBdWd1c3QgMjcuDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5kaGN3 ZyBtYWlsaW5nIGxpc3QNCj5kaGN3Z0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGhjd2cNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPmRoY3dnIG1haWxpbmcgbGlzdA0KPmRoY3dnQGlldGYub3JnDQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0K From dankney@network1.net Tue Aug 14 06:28:26 2012 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 BEADE21F85D0; Tue, 14 Aug 2012 06:28:26 -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 Ac6uc77lPFnR; Tue, 14 Aug 2012 06:28:26 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 250CC21F85AD; Tue, 14 Aug 2012 06:28:09 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 78CAE541104; Tue, 14 Aug 2012 09:28:08 -0400 (EDT) Date: Tue, 14 Aug 2012 09:28:08 -0400 (EDT) From: perl-list To: internet-drafts@ietf.org Message-ID: <1978941860.119401.1344950888386.JavaMail.root@network1.net> In-Reply-To: <20120814023301.12939.59518.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_119400_641411279.1344950888385" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Cc: dhcwg@ietf.org, i-d-announce@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-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: Tue, 14 Aug 2012 13:28:26 -0000 ------=_Part_119400_641411279.1344950888385 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I for one would like to thank Cisco for their work on this. My company is quite interested in this option. Does anyone know where we are in the timeline? Specifically, any estimates as to when we might see support for this in production software (I know it isn't all the way through the IETF process yet)? ----- Original Message ----- > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Sent: Monday, August 13, 2012 10:33:01 PM > Subject: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.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 : Client Link-layer Address Option in DHCPv6 > Author(s) : Gaurav Halwasia > Shwetha Bhandari > Wojciech Dec > Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt > Pages : 6 > Date : 2012-08-13 > Abstract: > This document specifies the format and mechanism that is to be used > for encoding client link-layer address in DHCPv6 relay forward > messages by defining a new DHCPv6 Client Link-layer Address option. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > 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 ------=_Part_119400_641411279.1344950888385 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>I for one would like to thank Cisco for their work on this. &nb= sp;My company is quite interested in this option.  Does anyone know wh= ere we are in the timeline?  Specifically, any estimates as to when we= might see support for this in production software (I know it isn't all the= way through the IETF process yet)?


Fro= m: internet-drafts@ietf.org
To: i-d-announce@ietf.org
C= c: dhcwg@ietf.org
Sent: Monday, August 13, 2012 10:33:01 PMSubject: [dhcwg] I-D Action:      &n= bsp; draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt

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

      &nbs= p; Title           : Client Link-layer Addres= s Option in DHCPv6
        Autho= r(s)       : Gaurav Halwasia
       &= nbsp;                  Shwetha= Bhandari
                 =          Wojciech Dec
    &= nbsp;   Filename        : draft-ietf-dhc= -dhcpv6-client-link-layer-addr-opt-01.txt
     =    Pages           : 6
 &nb= sp;      Date         &nb= sp;  : 2012-08-13

Abstract:
   This document speci= fies the format and mechanism that is to be used
   for encodi= ng client link-layer address in DHCPv6 relay forward
   messag= es by defining a new DHCPv6 Client Link-layer Address option.


The IETF datatracker status page for this draft is:
https://datatracke= r.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt

Ther= e's also a htmlized version available at:
http://tools.ietf.org/html/dra= ft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

A diff from the pre= vious version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-= ietf-dhc-dhcpv6-client-link-layer-addr-opt-01


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

_______________________________________________
dhcwg mailing l= ist
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

------=_Part_119400_641411279.1344950888385-- From Ted.Lemon@nominum.com Tue Aug 14 07:30:53 2012 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 183CF21F85A8; Tue, 14 Aug 2012 07:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XFoAECIbCpRf; Tue, 14 Aug 2012 07:30:52 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFF421F8587; Tue, 14 Aug 2012 07:30:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUCphGrsFiXdq+MCPcr6pDSz1v62dhEdl@postini.com; Tue, 14 Aug 2012 07:30:51 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 097A11B8307; Tue, 14 Aug 2012 07:30:50 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 F3F48190052; Tue, 14 Aug 2012 07:30:49 -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.02.0247.003; Tue, 14 Aug 2012 07:30:50 -0700 From: Ted Lemon To: perl-list Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt Thread-Index: AQHNeiCyoe6pUrxqkEmuwyWyAZQLd5dZ0+OA Date: Tue, 14 Aug 2012 14:30:49 +0000 Message-ID: References: <1978941860.119401.1344950888386.JavaMail.root@network1.net> In-Reply-To: <1978941860.119401.1344950888386.JavaMail.root@network1.net> 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: multipart/alternative; boundary="_000_E651F4F719DC415C99ECA95CA42A2F37nominumcom_" MIME-Version: 1.0 Cc: "" , "" , "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-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: Tue, 14 Aug 2012 14:30:53 -0000 --_000_E651F4F719DC415C99ECA95CA42A2F37nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 14, 2012, at 9:28 AM, perl-list wrote: I for one would like to thank Cisco for their work on this. My company is = quite interested in this option. Does anyone know where we are in the time= line? Specifically, any estimates as to when we might see support for this= in production software (I know it isn't all the way through the IETF proce= ss yet)? I'd like to see the authors bring this to WGLC quickly (like, this month). = However, that is up to them. And of course, the working group will need= to give substantive (and hopefully in-scope) review to maximize document q= uality. (Yes, that is a hint! :) --_000_E651F4F719DC415C99ECA95CA42A2F37nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0E6674B48281FC429B47B3D0739BFF21@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 14, 2012, at 9:28 AM, perl-list wrote:
I for one would like to thank Cisco for their work on this.  My company= is quite interested in this option.  Does anyone know where we are in= the timeline?  Specifically, any estimates as to when we might see su= pport for this in production software (I know it isn't all the way through the IETF process yet)?

I'd like to see the authors bring this to WGLC quickly (like, this mon= th).   However, that is up to them.   And of course, the working = group will need to give substantive (and hopefully in-scope) review to maxi= mize document quality.   (Yes, that is a hint! :)

--_000_E651F4F719DC415C99ECA95CA42A2F37nominumcom_-- From cra@WPI.EDU Tue Aug 14 07:45:39 2012 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 8BE4421F846F for ; Tue, 14 Aug 2012 07:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Ie2yafCXyZEA for ; Tue, 14 Aug 2012 07:45:38 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id BF22C21F84FB for ; Tue, 14 Aug 2012 07:45:38 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7EEjbYr028557 for ; Tue, 14 Aug 2012 10:45:37 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q7EEjbYr028557 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1344955537; bh=h9p4L+RkIoyLgerdofPSTJ3dZvOdxxG5Esfvn6JSzVc=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=GiS+ZkGgNPPfDnlBDmPxb7HlQb/QeRPrgdF2qlS+Q1Yl7wldJrbYteM0baF9G3XLW vAnic/7uqTThc284iwaRc2DHYPmdffJa2HGXdDiThNpZOqJXKM5wjsnbgu4JMLIACc bbbkoH6eEHtqjhdf+LONNWfK+a3H2fVfaJ7bO4xg= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7EEjaAJ028408 for ; Tue, 14 Aug 2012 10:45:37 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7EE7qN5023029 for ; Tue, 14 Aug 2012 10:07:53 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7EE7q0O005986 for ; Tue, 14 Aug 2012 10:07:52 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id q7EE7p78005985 for dhcwg@ietf.org; Tue, 14 Aug 2012 10:07:51 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Tue, 14 Aug 2012 10:07:51 -0400 From: Chuck Anderson To: dhcwg@ietf.org Message-ID: <20120814140751.GC21390@angus.ind.WPI.EDU> Mail-Followup-To: dhcwg@ietf.org References: <20120814023301.12939.59518.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120814023301.12939.59518.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.20 (2009-12-10) Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-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: Tue, 14 Aug 2012 14:45:39 -0000 I support this draft. I wouldn't mind standardizing a way for a client to add LL address to DHCPv6, but agree that it is probably best to leave that for future standards action and move forward with this draft which standardizes only having the relay agent add the LL address. Thanks. On Mon, Aug 13, 2012 at 07:33:01PM -0700, 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 : Client Link-layer Address Option in DHCPv6 > Author(s) : Gaurav Halwasia > Shwetha Bhandari > Wojciech Dec > Filename : draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt > Pages : 6 > Date : 2012-08-13 > > Abstract: > This document specifies the format and mechanism that is to be used > for encoding client link-layer address in DHCPv6 relay forward > messages by defining a new DHCPv6 Client Link-layer Address option. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From akostur@incognito.com Tue Aug 14 08:10:38 2012 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 A06CA21F84EA for ; Tue, 14 Aug 2012 08:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jvuyV5PXlK+2 for ; Tue, 14 Aug 2012 08:10:38 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id BD5B921F8647 for ; Tue, 14 Aug 2012 08:10:37 -0700 (PDT) Received: from mail-gh0-f176.google.com ([209.85.160.176]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKUCpqbPUpxjR90kqYvfOaq89uHFyXGXPF@postini.com; Tue, 14 Aug 2012 08:10:37 PDT Received: by ghbz10 with SMTP id z10so674772ghb.35 for ; Tue, 14 Aug 2012 08:10:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=uM9n4CBfz0YRv13+NebMWhAlD3weL49aCvy3QXJLBIQ=; b=HmMb7cj5wjPyls5nlv+8Fb696T3NdjghOKitGHWtp89a3g0Xi/UXKygsTIMP08OOha jH8HWbDaqRsBrwupdrEAYpGfxUi4qv4bqJVddN/PXjUoAx8g7shctIOhsU0r6GjLGbYH k/iUzsO4R+IK91mYcFx1glAx2hlAnzUySSYykWFY6L+ef00WoqAfrt8/re7MstXnjfTV hMVMyCZgHYKI9SbZzwkIWMab2hm826FIp/CUBJtChvKsIyafEcvGFoHvzMdU99uk5WLL Fl6ZYuK8pXVBqbIo+mTRkg/UkPDZXyGfj7Rn6g0aJYmOvd+ZNgXLreQfllcGx0jOgebY 3jPg== MIME-Version: 1.0 Received: by 10.42.114.16 with SMTP id e16mr12980374icq.57.1344957036241; Tue, 14 Aug 2012 08:10:36 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Tue, 14 Aug 2012 08:10:36 -0700 (PDT) In-Reply-To: <20120814023301.12939.59518.idtracker@ietfa.amsl.com> References: <20120814023301.12939.59518.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2012 08:10:36 -0700 Message-ID: From: Andre Kostur To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnFifQruVHtfsdHSU2WZHczdXZdu5gHINQeqNWdJOMhiq1Sm7Z0DQ56WBqQA4HEjEmgb8Zx Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-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: Tue, 14 Aug 2012 15:10:38 -0000 On Mon, Aug 13, 2012 at 7:33 PM, 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 : Client Link-layer Address Option in DHCPv6 > Author(s) : Gaurav Halwasia > Shwetha Bhandari > Wojciech Dec > Filename : > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt > Pages : 6 > Date : 2012-08-13 I think section 2, paragraph 1 is somewhat superfluous (does it really matter how DHCPv4 carries the link-layer address, or merely that it does carry it in every packet?). I think that it would be clearer to start with paragraph 2, talking about how we wish to associate a DHCPv6 lease with a DHCPv4 lease instead of focusing on the link-layer address first, then talking about why it's a problem. -- Andre Kostur From dankney@network1.net Tue Aug 14 09:54:47 2012 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 C8BF321F87A0 for ; Tue, 14 Aug 2012 09:54:47 -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 UdKtPtMmWho2 for ; Tue, 14 Aug 2012 09:54:47 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 08BB221F879F for ; Tue, 14 Aug 2012 09:54:46 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 27E3E541107 for ; Tue, 14 Aug 2012 12:54:46 -0400 (EDT) Date: Tue, 14 Aug 2012 12:54:46 -0400 (EDT) From: perl-list To: dhcwg@ietf.org Message-ID: <1042177688.120003.1344963286073.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_120002_1250578011.1344963286072" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-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: Tue, 14 Aug 2012 16:54:47 -0000 ------=_Part_120002_1250578011.1344963286072 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit paragraph 1 is fine in my opinion as it does provide some background regarding how things were done. Also - it might be important to note in paragraph 2 that without the link layer address, there is no global way to identify DHCPv4 and DHCPv6 allocations to the same hardware as the IDs are not compatible. A lthough I have seen an RFC somewhere about making the IDs from DHCPv6 used in DHCPv4, it is unlikely that this will happen on any wide scale. It is also possible, in some cases, but not all, to extract the hardware address from the DUID (depending on what method of generation was used). Perhaps some of this logic should be added to the draft as further evidence for the need of this option? I don't know - the way it reads now, it sounds like it is just there to help people who haven't implemented some other available tracking method. The reality is that there isn't a reliable alternative to correlate between DHCPv4 and DHCPv6. ----- Original Message ----- > From: "Andre Kostur" > To: dhcwg@ietf.org > Sent: Tuesday, August 14, 2012 11:10:36 AM > Subject: Re: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt > On Mon, Aug 13, 2012 at 7:33 PM, 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 : Client Link-layer Address Option in DHCPv6 > > Author(s) : Gaurav Halwasia > > Shwetha Bhandari > > Wojciech Dec > > Filename : > > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt > > Pages : 6 > > Date : 2012-08-13 > I think section 2, paragraph 1 is somewhat superfluous (does it > really > matter how DHCPv4 carries the link-layer address, or merely that it > does carry it in every packet?). I think that it would be clearer to > start with paragraph 2, talking about how we wish to associate a > DHCPv6 lease with a DHCPv4 lease instead of focusing on the > link-layer > address first, then talking about why it's a problem. > -- > Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_120002_1250578011.1344963286072 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>
paragraph 1 is fine in my opinion as it d= oes provide some background regarding how things were done.

Also - it might be important to note in paragraph 2 that without the= link layer address, there is no global way to identify DHCPv4 and DHCPv6 a= llocations to the same hardware as the IDs are not compatible.  A= lthough I have seen an RFC somewhere about making the IDs from DHCPv6 used = in DHCPv4, it is unlikely that this will happen on any wide scale. It is al= so possible, in some cases, but not all, to extract the hardware address fr= om the DUID (depending on what method of generation was used).  Perhap= s some of this logic should be added to the draft as further evidence for t= he need of this option?

I don't know - the way it reads now, it sounds like = it is just there to help people who haven't implemented some other availabl= e tracking method.  The reality is that there isn't a reliable alterna= tive to correlate between DHCPv4 and DHCPv6.

From: "Andre Kostur" <akostur@incognito.com>
To: dhcwg@ietf.org
Sent: Tuesday, August 14, 2012 11:10:36 A= M
Subject: Re: [dhcwg] I-D Action:     &= nbsp;  draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt
On Mon, Aug 13, 2012 at 7:33 PM, <internet-drafts@ietf.org> wrot= e:
>
>
> A New Internet-Draft is available from the on-li= ne Internet-Drafts
> directories.
>  This draft is a work = item of the Dynamic Host Configuration Working Group
> of the IETF.>
>         Title        = ;   : Client Link-layer Address Option in DHCPv6
>    =     Author(s)       : Gaurav Halwasia
> &nb= sp;                     &= nbsp;   Shwetha Bhandari
>           &n= bsp;               Wojciech Dec
> =         Filename        :
> d= raft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt
>    = ;     Pages           : 6
>  =       Date            : 2012-= 08-13


I think section 2, paragraph 1 is somewhat superfluous (do= es it really
matter how DHCPv4 carries the link-layer address, or merely= that it
does carry it in every packet?).  I think that it would be= clearer to
start with paragraph 2, talking about how we wish to associa= te a
DHCPv6 lease with a DHCPv4 lease instead of focusing on the link-la= yer
address first, then talking about why it's a problem.

--
A= ndre Kostur
_______________________________________________
dhcwg mai= ling list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg<= br>

------=_Part_120002_1250578011.1344963286072-- From hermin.anggawijaya@gmail.com Tue Aug 14 15:07:44 2012 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 46E1821E80BB for ; Tue, 14 Aug 2012 15:07:44 -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=[BAYES_00=-2.599, 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 63pHmAB+qyEj for ; Tue, 14 Aug 2012 15:07:43 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B615F21E8050 for ; Tue, 14 Aug 2012 15:07:43 -0700 (PDT) Received: by qcac10 with SMTP id c10so865736qca.31 for ; Tue, 14 Aug 2012 15:07:43 -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=yUg6EQ1a+8KggcMnY1wJ4PrNC3S5CNF2d7GCn3aouU4=; b=G2iEM5sEJXjmF/RZ73OT9Won1hbFNo+THqiAAAch2nLqswtfvmrJHzo/OlPrvmOtbz p4jv38KVWz8/XHQK4SoZOdDlLci6D2ujg6AjEdIkT48KbmrqrQa5bF+TFQi0Il8gqEpM Vni84hsXow8YOQm3M1OwsZOgP3P8OHUfPgChCsfv1N8IsSZOiyuX1GOyNfwiNssCxdIv UTQJd51mzBr33o58RHrMFbGsymvBSQF9j+L9N0CR2P6t0XwBubUC+8PSH/zl8N0opg7y Njr33nHd0AILaykCHINEI8iYUJhd+uAS4hr7qZCgKyj2FE/dpnwj1Ht2QI3/uV3T7iQm d/IA== MIME-Version: 1.0 Received: by 10.224.213.198 with SMTP id gx6mr27466374qab.9.1344982063244; Tue, 14 Aug 2012 15:07:43 -0700 (PDT) Received: by 10.49.40.135 with HTTP; Tue, 14 Aug 2012 15:07:43 -0700 (PDT) In-Reply-To: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> References: <479C8CA3-A0BE-41C3-A986-1F6F3DB1C99B@nominum.com> Date: Wed, 15 Aug 2012 10:07:43 +1200 Message-ID: From: Hermin Anggawijaya To: dhc WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dhcwg] ADOPTION REQUEST: Modification to Default Value of SOL_MAX_RT (draft-droms-dhc-dhcpv6-solmaxrt-update-03) 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, 14 Aug 2012 22:07:44 -0000 I support the adoption. On Wed, Aug 8, 2012 at 9:54 AM, Ted Lemon wrote: > On Aug 7, 2012, at 5:44 PM, Brzozowski, John wrote: > > If there are any questions or concerns regarding adopting this draft as a > work item for the dhcwg please send mail no later than August 21, 2012 5PM > EDT. > > > Er, also if you favor adopting the draft please send mail! > > I'm in favor of adopting. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From leo.liubing@huawei.com Tue Aug 14 18:36:00 2012 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 41FF221E80E2 for ; Tue, 14 Aug 2012 18:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.333 X-Spam-Level: X-Spam-Status: No, score=-6.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 i1XtZOtgC+Pp for ; Tue, 14 Aug 2012 18:35:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB6B21E80E1 for ; Tue, 14 Aug 2012 18:35:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJK63162; Tue, 14 Aug 2012 17:35:57 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 18:32:26 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 18:32:30 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 09:32:20 +0800 From: "Liubing (Leo)" To: Sheng Jiang , Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdY5bRAgAAkl+CAAQ7iQA== Date: Wed, 15 Aug 2012 01:32:19 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F452932ED18@szxeml509-mbs> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <8AE0F17B87264D4CAC7DE0AA6C406F452932EAEC@szxeml509-mbs> <5D36713D8A4E7348A7E10DF7437A4B9239F059F5@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F059F5@szxeml545-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.42] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 01:36:00 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTaGVuZyBKaWFuZyANClNlbnQ6 IFR1ZXNkYXksIEF1Z3VzdCAxNCwgMjAxMiA1OjI2IFBNDQpUbzogTGl1YmluZyAoTGVvKTsgVGVk IExlbW9uOyBkaGMgV0cNClN1YmplY3Q6IFJFOiBXR0xDOiBkcmFmdC1pZXRmLWRoYy1ob3N0LWdl bi1pZC0wMg0KDQpIaSwgQmluZywNCg0KVGhhbmtzIGZvciB5b3VyIHN1cHBvcnQgYW5kIGNvbW1l bnRzLiBTZWUgbXkgcmVwbGllcyBpbiBsaW5lcy4NCg0KUmVnYXJkcywNCg0KU2hlbmcNCg0KPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPk9mIExpdWJpbmcgKExl bykNCj5TZW50OiBUdWVzZGF5LCBBdWd1c3QgMTQsIDIwMTIgMzo1OSBQTQ0KPlRvOiBUZWQgTGVt b247IGRoYyBXRw0KPlN1YmplY3Q6IFJlOiBbZGhjd2ddIFdHTEM6IGRyYWZ0LWlldGYtZGhjLWhv c3QtZ2VuLWlkLTAyDQo+DQo+U3VwcG9ydCBhZHZhbmNpbmcgaXQuIEZldyBtaW5vciBjb21tZW50 czoNCj4NCj5TZWN0aW9uIDMsIGZpcnN0IHBhcmFncmFwaC4gSXQgaXMgbm90IHByb3BlciB0byBz YXkgcm91dGVycyBjYW4gInNwZWNpZnkiIHRoZQ0KPmhvc3RzIHNob3VsZCB1c2UgREhDUHY2IGFu ZC9vciBzdGF0ZWxlc3MgYWRkcmVzcyBjb25maWd1cmF0aW9uLiBJbiBmYWN0IHRoZQ0KPlJGQzQ4 NjIgZG9lc24ndCBjbGVhcmx5IGRlZmluZWQgdGhlIGhvc3RzIHNob3VsZCBpbnRlcnByZXQgdGhl IE0vTyBmbGFncyBhcw0KPnByZXNjcmlwdGl2ZSwgYnV0IGp1c3QgYWR2aXNvcnkuIEluIG90aGVy IHdvcmQsIGl0IGlzIG5vdCBkZXRlcm1pbmVkIGJ5IHRoZQ0KPnJvdXRlcnMsIGJ1dCB0aGUgaG9z dHMgdGhlbXNlbHZlcy4NCg0KVGhpcyBzZW50ZW5jZSBpcyBhbG1vc3QgdGhlIHNhbWUgd2l0aCBv cmlnaW5hbCBzZW50ZW5jZSBpbiBSRkM0ODYyLCBpbmNsdWRpbmcgdGhlIHdvcmQgInNwZWNpZnki LiBUaGUgb2JqZWN0IG9mICJzcGVjaWZ5IiBpcyBhICJzaG91bGQiLCByYXRoZXIgdGhhbiAiTVVT VCIuIFNvLCByb3V0ZXIgaXMgbm90IGRldGVybWluZWQgdGhlIGFkZHJlc3MgY29uZmlndXJhdGlv biBtb2RlbC4gUm91dGVyIGdpdmVzIGFkdmljZXMuIFRoaXMgZGVzY3JpcHRpb24gaXMgY29tcGF0 aWJsZSB3aXRoIHlvdXIgdW5kZXJzdGFuZGluZywgSSBiZWxpZXZlLiANCg0KW0JpbmddIFRoYXQg aXMgd2hhdCBJIG1lYW4uIFRoYW5rcy4NCg0KPkluIGxhc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24g NCwgd2hhdCBpcyB0aGUgImFkZHJlc3MgcmVnaXN0cmF0aW9uIHByb2NlZHVyZSI/DQo+RG8geW91 IG1lYW4gdGhlIHByb2NlZHVyZSBkZWZpbmVkIGluIGRyYWZ0LWlldGYtZGhjLWFkZHItcmVnaXN0 cmF0aW9uID8gSWYgaXQgaXMsDQo+aXQncyBiZXR0ZXIgdG8gYWRkIGEgcmVmZXJlbmNlLg0KDQpF Y2hvLiBUaGFua3MuDQoNClNoZW5nDQoNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYNCj5PZiBUZWQgTGVtb24NCj5TZW50OiBNb25kYXksIEF1Z3VzdCAxMywg MjAxMiAxMDowNSBBTQ0KPlRvOiBkaGMgV0cNCj5TdWJqZWN0OiBbZGhjd2ddIFdHTEM6IGRyYWZ0 LWlldGYtZGhjLWhvc3QtZ2VuLWlkLTAyDQo+DQo+VGhlIGF1dGhvcnMgaGF2ZSByZXF1ZXN0ZWQg YSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgdGhpcyBkcmFmdC4gICBUaGUNCj5kcmFmdCBw cm92aWRlcyBhIG1lY2hhbmlzbSB3aGVyZWJ5IHRoZSBESENQIHNlcnZlciBjYW4gaW5kaWNhdGUg dG8gdGhlDQo+REhDUCBjbGllbnQgd2hpY2ggcHJlZml4IGl0IHNob3VsZCB1c2UgZm9yIGF1dG9j b25maWd1cmF0aW9uLCBmb3IgaW5zdGFuY2UgZm9yDQo+Q0dBIGFkZHJlc3MgZ2VuZXJhdGlvbi4g ICBUaGlzIGRyYWZ0IGhhcyBiZWVuIGhhbmdpbmcgYXJvdW5kIGZvciBhIHdoaWxlLA0KPmFuZCBj b3VsZCBkZWZpbml0ZWx5IHVzZSBtb3JlIGV5ZXMgb24gaXQuICAgUGxlYXNlIHRha2UgdGhlIHRp bWUgdG8gcmV2aWV3IGl0Ow0KPmlmIHlvdSB0aGluayBpdCdzIGEgZ29vZCBpZGVhLCBwbGVhc2Ug aW5kaWNhdGUgeW91ciBzdXBwb3J0IGZvciBhZHZhbmNpbmcgdGhlDQo+ZHJhZnQuICAgSWYgeW91 IHRoaW5rIGl0J3MgYSBiYWQgaWRlYSwgcGxlYXNlIGluZGljYXRlIHRoYXQgeW91IGRvIG5vdCBz dXBwb3J0DQo+YWR2YW5jaW5nIGl0LiAgIElmIHlvdSBoYXZlIGNvbW1lbnRzLCB0aGV5IHdvdWxk IGJlIHZlcnkgbXVjaCBhcHByZWNpYXRlZC4NCj4NCj5XZSB3aWxsIGRldGVybWluZSBjb25zZW5z dXMgb24gQXVndXN0IDI3Lg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBsaXN0DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5kaGN3ZyBtYWlsaW5nIGxpc3QNCj5k aGN3Z0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhj d2cNCg== From jiangsheng@huawei.com Tue Aug 14 20:15:24 2012 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 AC0D621F84FD for ; Tue, 14 Aug 2012 20:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 qiTqF7NJY2BT for ; Tue, 14 Aug 2012 20:15:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BACE021F84F8 for ; Tue, 14 Aug 2012 20:15:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIW59861; Tue, 14 Aug 2012 19:15:23 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 20:12:49 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 20:12:48 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 11:12:45 +0800 From: Sheng Jiang To: "Gaurav Halwasia (ghalwasi)" , Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+Bcg Date: Wed, 15 Aug 2012 03:12:44 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 03:15:24 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogU2hlbmcgSmlhbmcgW21haWx0bzpq aWFuZ3NoZW5nQGh1YXdlaS5jb21dDQo+U2VudDogTW9uZGF5LCBBdWd1c3QgMTMsIDIwMTIgMTow NSBQTQ0KPlRvOiBHYXVyYXYgSGFsd2FzaWEgKGdoYWx3YXNpKTsgVGVkIExlbW9uOyBkaGMgV0cN Cj5TdWJqZWN0OiBSRTogV0dMQzogZHJhZnQtaWV0Zi1kaGMtaG9zdC1nZW4taWQtMDINCj4NCj5I aSwgR2F1cmF2LA0KPg0KPlRoYW5rcyBmb3IgeW91ciBjYXJlZnVsbHkgcmV2aWV3LiBSZXBseSBp biBsaW5lcy4gV2l0aCBhbGwgeW91ciBjb21tZW50cw0KPmFkZHJlc3NlZCwgd291bGQgeW91IHN1 cHBvcnQgdGhpcyBkb2N1bWVudCBmb3J3YXJkPw0KPltHYXVyYXZdIENlcnRhaW5seS4gSSBzdXBw b3J0IHRoZSBkb2N1bWVudCBmb3J3YXJkLg0KPg0KPj5JIGxpa2UgdGhlIGlkZWEgYnV0IEkgZG8g aGF2ZSBmZXcgY29tbWVudHM6LS4NCj4+DQo+PjEuKSBBYnN0cmFjdCBkb2VzIG5vdCBzZWVtcyBj bGVhciB0byBtZS4NCj4+VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2UgYSBwcm9jZWR1cmUgZm9yIGNv bmZpZ3VyaW5nIGhvc3RzJyBJUHY2DQo+PiAgIGFkZHJlc3Mgd2hpY2ggdGhlIHByZWZpeCBpcyBh c3NpZ25lZCBmcm9tIGEgREhDUHY2IHNlcnZlciB0aHJvdWdoDQo+PiAgIERIQ1B2NiBwcm90b2Nv bCB3aGlsZSB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZXJzIGFyZSBpbmRlcGVuZGVudGx5DQo+PiAg IGdlbmVyYXRlZCBieSB0aGUgaG9zdHMuDQo+DQo+UmV3b3JkZWQ6IFRoaXMgZG9jdW1lbnQgaW50 cm9kdWNlcyBhIG5ldyBESENQdjYgcHJvY2VkdXJlIHRvIGNvbmZpZ3VyZQ0KPmhvc3RzJyBJUHY2 IGFkZHJlc3Nlcy4gSW4gdGhpcyBuZXcgcHJvY2VkdXJlLCB0aGUgcHJlZml4IGlzIGFkdmVydGlz ZWQgZnJvbSBhDQo+REhDUHY2IHNlcnZlciB0aHJvdWdoIERIQ1B2NiBwcm90b2NvbCB3aGlsZSB0 aGUgaW50ZXJmYWNlIGlkZW50aWZpZXJzIGFyZQ0KPmluZGVwZW5kZW50bHkgZ2VuZXJhdGVkIGJ5 IHRoZSBob3N0cy4NCj4NCj4+Mi4pIFNlY3Rpb24gMSAuIEludHJvZHVjdGlvbi4gQ2hhbmdlICJo b3N0LWdlbmFyYXRlZCIgdG8gImhvc3QtZ2VuZXJhdGVkIg0KPj4zLikgU2VjdGlvbiAxIC4gSW50 cm9kdWN0aW9uLiBDaGFuZ2UgInNlcGFyYXRzIiB0byAic2VwYXJhdGVzIg0KPj40LikgU2VjdGlv biAxIC4gSW50cm9kdWN0aW9uLiBDaGFuZ2UgImluZ2VyZmFjZSBpZGVudGlmaWVycyIgdG8NCj4+ ImludGVyZmFjZSBpZGVudGlmaWVycyINCj4NCj5BbGwgY2hhbmdlZC4NCj4NCj4+NS4pIFNlY3Rp b24gNC4gIFRoaXMgc2VjdGlvbiB0YWxrcyBhYm91dCB0aGUgbmV3IElBX1BBIG9wdGlvbiBidXQg ZG9lcw0KPj5ub3QgZXhwbGljaXRseSBzYXkgdGhhdCB0aGlzIG9wdGlvbiBuZWVkcyB0byBiZSBp bnNlcnRlZCBpbiBTT0xJQ0lUIG1lc3NhZ2UuDQo+DQo+SGF2ZSBhZGRlZCBhIHNlbnRlbmNlIGZv ciB0aGlzLiBIb3dldmVyLCB0aGlzIGlzIG9ubHkgYSBNQVkuICJBIGhvc3QgTUFZDQo+aW5jbHVk ZSBhIE9wdGlvbiBSZXF1ZXN0IE9wdGlvbiBpbiBhIFNvbGljaXQgb3IgUmVxdWVzdCBtZXNzYWdl IHRvIHJlcXVlc3QgYQ0KPklBX1BBIGV4cGxpY2l0bHkuIiBUaGUgcHJlZml4IGFzc2lnbm1lbnQg Y291bGQgYmUgaW4gYWR2ZXJ0aXNlIG1vZGVsLiBJdCBpcyBub3QNCj5uZWNlc3NhcnkgdGhhdCBh IGhvc3QgcmVxdWVzdCBhIElBX1BBLg0KPltHYXVyYXZdIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlz IHBhcnQgY29tcGxldGVseS4gU28geW91IGFyZSBzYXlpbmcgdGhhdCBob3N0DQo+Y2FuIHNlbmQg IkRIQ1AgUkVRVUVTVCIgbWVzc2FnZSBhcyB3ZWxsIGluc3RlYWQgb2YgU09MSUNJVC4/IENhbiB5 b3UNCj5wbGVhc2UgZWxhYm9yYXRlIGl0IGluIGRldGFpbC4NCg0KPFNoZW5nPlllcy4gQWZ0ZXIg ZGlzY292ZXJ5IGEgREhDUHY2IHNlcnZlciB3aXRoIHNvbGljaXQgbWVzc2FnZSwgYSBob3N0IGNh biB1c2UgYSBSZXF1ZXN0IG1lc3NhZ2UgdG8gcmVxdWVzdCBwcmVmaXggYXNzaWdubWVudCBieSBp bmNsdWRlIGEgSUFfUEEsIGluc3RlYWQgb2YgSUFfTkEgb3IgSUFfVEEuIFRoZSBzZXJ2ZXIgdGhl biByZXR1cm4gcHJlZml4IGluZm9ybWF0aW9uIHJhdGhlciB0aGFuIGFkZHJlc3MuIEluIG91ciB1 bmRlcnN0YW5kaW5nLCB0aGlzIHByb2NlZHVyZSBpcyBvbmUgd2F5IG9mIGFkZHJlc3MgY29uZmln dXJhdGlvbiwgbm90IG90aGVyIGluZm9ybWF0aW9uLg0KDQpPb3BzLi4uIFdpdGggdGhpcywgaXQg c2VlbXMgd2UgdXBkYXRlIFJGQzMzMTUgYSBsaXR0bGUgYml0LiBNYXliZSB3ZSBzaG91bGQgaW5j bHVkZSBhbiB1cGRhdGUgaGVhZGVyIGluIHRoZSBkb2N1bWVudC4NCg0KVGhlIGFib3ZlIHNlbnRl bmNlIG5lZWRzIGEgbGl0dGxlIGJpdCByZXZpc2U6ICJBIGhvc3QgTUFZIGluY2x1ZGUgYSBPcHRp b24gUmVxdWVzdCBPcHRpb24gaW4gYSBTb2xpY2l0IG9yIElBX1BBIGluIGEgUmVxdWVzdCBtZXNz YWdlIHRvIHJlcXVlc3QgYSBwcmVmaXggYXNzaWdubWVudCBleHBsaWNpdGx5LiINCg0KV2hlbiB0 aGUgcHJlZml4IGFzc2lnbm1lbnQgaW4gYWR2ZXJ0aXNlIG1vZGVsLCBldmVuIGlmIGEgaG9zdCBk b2VzIG5vdCByZXF1ZXN0LCBESENQdjYgc2VydmVyIGNhbiBwdXNoIGl0IGluaXRpYXRpdmVseS4N Cg0KPj42LikgQXMgdGhpcyBwcm9jZWR1cmUgaXMgaW5kZWVkICJzdGF0ZSBsZXNzIiBmcm9tIHRo ZSBESENQdjYNCj4+cGVyc3BlY3RpdmUsIHdoeSBkb24ndCB3ZSB3YW50IHRvIHVzZSAiSW5mb3Jt YXRpb24tUmVxdWVzdCIgbWVzc2FnZQ0KPj5pbnN0ZWFkIG9mIFNPTElDSVQgZnJvbSB0aGUgaG9z dC4/DQo+DQo+UmVxdWVzdCBtZXNzYWdlIGlzIHBvc3NpYmxlLCB0b28uIFNlZSB0aGUgYWJvdmUg bmV3IHNlbnRlbmNlLg0KPg0KPltHYXVyYXZdIEkgd2FzIHJlZmVycmluZyB0byAiSW5mb3JtYXRp b24tUmVxdWVzdCgxMSkiIG1lc3NhZ2Ugbm90DQo+IlJlcXVlc3QoMykiDQoNCkFzIGV4cGxhaW5l ZCBhYm92ZSwgd2UgdGhpbmsgdGhpcyBwcm9jZWR1cmUgaXMgYWRkcmVzcyBhc3NvY2lhdGVkLiBT bywgUmVxdWVzdCBpcyBtb3JlIHByb3Blci4NCg0KU2hlbmcNCg0KPj43LikgV2hhdCBzaG91bGQg dGhlIGhvc3QgZG8gYWZ0ZXIgdGltZXJzIGV4cGlyZS4/IEFuZCBpcyB0aGUgREhDUHY2DQo+PlJF Q09ORklHVVJFIG1lc3NhZ2Ugc3VwcG9ydGVkIGZvciB0aGlzIG9wdGlvbiB0eXBlLiBJIHRoaW5r IHRoaXMgc2hvdWxkDQo+PmJlIGNsYXJpZmllZCBpbiB0aGUgZHJhZnQuDQo+DQo+SGF2ZSBhZGRl ZCB0d28gc2VudGVuY2VzIGluIFNlY3Rpb24gNCB0byBkZXNjcmliZSB0aGUgcG90ZW50aWFsIGZv bGxvdyB1cA0KPm9wZXJhdGlvbjoNCj4NCj5XaGVuIHRoZSBob3N0IHJlYWNoZXMgVDEgb3IgVDIg ZGVmaW5lZCBpbiBTZWN0aW9uIDUuMSwgaXQgU0hPVUxEIHVzZSB0aGUNCj5zYW1lIG1lc3NhZ2Ug ZXhjaGFuZ2VzLCBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAxOCwgIkRIQ1AgQ2xpZW50LUluaXRp YXRlZA0KPkNvbmZpZ3VyYXRpb24gRXhjaGFuZ2UiIG9mIFtSRkMzMzE1XSwgdG8gb2J0YWluIG9y IHVwZGF0ZSBwcmVmaXgoZXMpIGZyb20gYQ0KPkRIQ1B2NiBzZXJ2ZXIuDQo+DQo+QSBESENQdjYg c2VydmVyIE1BWSBpbml0aWF0aXZlbHkgc2VuZCBhIHJlY29uZmlndXJhdGlvbiBtZXNzYWdlIHRv IHRoZSBob3N0LA0KPmFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDE5LCAiREhDUCBTZXJ2ZXItIElu aXRpYXRlZCBDb25maWd1cmF0aW9uIEV4Y2hhbmdlIg0KPm9mIFtSRkMzMzE1XSwgdG8gY2F1c2Ug cHJlZml4KGVzKSBpbmZvcm1hdGlvbiB1cGRhdGUuDQo+DQo+QmVzdCByZWdhcmRzLA0KPg0KPlNo ZW5nDQo+DQo+PlRoYW5rcywNCj4+R2F1cmF2DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj5Gcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNl c0BpZXRmLm9yZ10gT24NCj5CZWhhbGYNCj4+T2YgVGVkIExlbW9uDQo+PlNlbnQ6IE1vbmRheSwg QXVndXN0IDEzLCAyMDEyIDc6MzUgQU0NCj4+VG86IGRoYyBXRw0KPj5TdWJqZWN0OiBbTUFSS0VU SU5HXSBbZGhjd2ddIFdHTEM6IGRyYWZ0LWlldGYtZGhjLWhvc3QtZ2VuLWlkLTAyDQo+Pg0KPj5U aGUgYXV0aG9ycyBoYXZlIHJlcXVlc3RlZCBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciB0 aGlzIGRyYWZ0LiAgIFRoZQ0KPj5kcmFmdCBwcm92aWRlcyBhIG1lY2hhbmlzbSB3aGVyZWJ5IHRo ZSBESENQIHNlcnZlciBjYW4gaW5kaWNhdGUgdG8gdGhlDQo+PkRIQ1AgY2xpZW50IHdoaWNoIHBy ZWZpeCBpdCBzaG91bGQgdXNlIGZvciBhdXRvY29uZmlndXJhdGlvbiwgZm9yIGluc3RhbmNlIGZv cg0KPj5DR0EgYWRkcmVzcyBnZW5lcmF0aW9uLiAgIFRoaXMgZHJhZnQgaGFzIGJlZW4gaGFuZ2lu ZyBhcm91bmQgZm9yIGEgd2hpbGUsDQo+PmFuZCBjb3VsZCBkZWZpbml0ZWx5IHVzZSBtb3JlIGV5 ZXMgb24gaXQuICAgUGxlYXNlIHRha2UgdGhlIHRpbWUgdG8gcmV2aWV3IGl0Ow0KPj5pZiB5b3Ug dGhpbmsgaXQncyBhIGdvb2QgaWRlYSwgcGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBmb3Ig YWR2YW5jaW5nIHRoZQ0KPj5kcmFmdC4gICBJZiB5b3UgdGhpbmsgaXQncyBhIGJhZCBpZGVhLCBw bGVhc2UgaW5kaWNhdGUgdGhhdCB5b3UgZG8gbm90IHN1cHBvcnQNCj4+YWR2YW5jaW5nIGl0LiAg IElmIHlvdSBoYXZlIGNvbW1lbnRzLCB0aGV5IHdvdWxkIGJlIHZlcnkgbXVjaA0KPmFwcHJlY2lh dGVkLg0KPj4NCj4+V2Ugd2lsbCBkZXRlcm1pbmUgY29uc2Vuc3VzIG9uIEF1Z3VzdCAyNy4NCj4+ DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PmRo Y3dnIG1haWxpbmcgbGlzdA0KPj5kaGN3Z0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PmRoY3dnIG1haWxpbmcgbGlzdA0KPj5kaGN3Z0BpZXRmLm9y Zw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= From akostur@incognito.com Tue Aug 14 21:42:22 2012 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 24DE821E805E for ; Tue, 14 Aug 2012 21:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 2hxgXv6Z-0zF for ; Tue, 14 Aug 2012 21:42:20 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id 6139221E80AB for ; Tue, 14 Aug 2012 21:42:17 -0700 (PDT) Received: from mail-gg0-f181.google.com ([209.85.161.181]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUCsoqcqbeRsD7zEJvTiLjwVQH/Do9rLj@postini.com; Tue, 14 Aug 2012 21:42:18 PDT Received: by ggmb6 with SMTP id b6so1601391ggm.40 for ; Tue, 14 Aug 2012 21:42:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Q6dEvrSUZqm4XSMWDfRunIfDfbKpZFseMOBw/U9X9eI=; b=nI+tkuuKasKBrQRtKBOkwX/rvuliDYIrD1ykNA2zpUx4c0qyEBdpwR8l0kayidyUMy U4JZdy5rpUp0n7QMx94gMx6HOp33j+CxkgO4iiBojd+SqCJMVp7UtEmp+Q5+gC0zVc3v TX/X225KI+5BIjnIsdJFnZeHC6N56TEY1Z4+fDvPGteFD2A9W+S8k4ARSCsrwG5sW3mF /6yIHYAjCFbJ3DNCbwnhJFMr/QXbwZ0Li1xiXiFQGi3Fbt4Y7ADSUX4j0j9rNBMJUF10 q0i1Hvg5sgkFN/6gdkIZ3cEfCARNkxja5uaOgbcR0ACTRl7Sfxg3jnlCj5LUEvcgD2Sf uX+w== MIME-Version: 1.0 Received: by 10.50.77.131 with SMTP id s3mr15846710igw.20.1345005736553; Tue, 14 Aug 2012 21:42:16 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Tue, 14 Aug 2012 21:42:16 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> Date: Tue, 14 Aug 2012 21:42:16 -0700 Message-ID: From: Andre Kostur To: Sheng Jiang Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlrNPoFpd3fDXdtHoC9Fdh9bce/Fdm1uuBsKsi6Htf00WzmmEnIMQQLe/GnFn8Zt57u0e16 Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 04:42:22 -0000 I think that if the device wants a PA, it should supply an IA_PA in its Solicit. The device needs to specify an IAID. An ORO is insufficient. On Tue, Aug 14, 2012 at 8:12 PM, Sheng Jiang wrote: > > >-----Original Message----- > >From: Sheng Jiang [mailto:jiangsheng@huawei.com] > >Sent: Monday, August 13, 2012 1:05 PM > >To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG > >Subject: RE: WGLC: draft-ietf-dhc-host-gen-id-02 > > > >Hi, Gaurav, > > > >Thanks for your carefully review. Reply in lines. With all your comments > >addressed, would you support this document forward? > >[Gaurav] Certainly. I support the document forward. > > > >>I like the idea but I do have few comments:-. > >> > >>1.) Abstract does not seems clear to me. > >>This document introduce a procedure for configuring hosts' IPv6 > >> address which the prefix is assigned from a DHCPv6 server through > >> DHCPv6 protocol while the interface identifiers are independently > >> generated by the hosts. > > > >Reworded: This document introduces a new DHCPv6 procedure to configure > >hosts' IPv6 addresses. In this new procedure, the prefix is advertised f= rom a > >DHCPv6 server through DHCPv6 protocol while the interface identifiers ar= e > >independently generated by the hosts. > > > >>2.) Section 1 . Introduction. Change "host-genarated" to "host-generate= d" > >>3.) Section 1 . Introduction. Change "separats" to "separates" > >>4.) Section 1 . Introduction. Change "ingerface identifiers" to > >>"interface identifiers" > > > >All changed. > > > >>5.) Section 4. This section talks about the new IA_PA option but does > >>not explicitly say that this option needs to be inserted in SOLICIT mes= sage. > > > >Have added a sentence for this. However, this is only a MAY. "A host MAY > >include a Option Request Option in a Solicit or Request message to reque= st a > >IA_PA explicitly." The prefix assignment could be in advertise model. It= is not > >necessary that a host request a IA_PA. > >[Gaurav] I don't understand this part completely. So you are saying that= host > >can send "DHCP REQUEST" message as well instead of SOLICIT.? Can you > >please elaborate it in detail. > > Yes. After discovery a DHCPv6 server with solicit message, a host = can use a Request message to request prefix assignment by include a IA_PA, = instead of IA_NA or IA_TA. The server then return prefix information rather= than address. In our understanding, this procedure is one way of address c= onfiguration, not other information. > > Oops... With this, it seems we update RFC3315 a little bit. Maybe we shou= ld include an update header in the document. > > The above sentence needs a little bit revise: "A host MAY include a Optio= n Request Option in a Solicit or IA_PA in a Request message to request a pr= efix assignment explicitly." > > When the prefix assignment in advertise model, even if a host does not re= quest, DHCPv6 server can push it initiatively. > > >>6.) As this procedure is indeed "state less" from the DHCPv6 > >>perspective, why don't we want to use "Information-Request" message > >>instead of SOLICIT from the host.? > > > >Request message is possible, too. See the above new sentence. > > > >[Gaurav] I was referring to "Information-Request(11)" message not > >"Request(3)" > > As explained above, we think this procedure is address associated. So, Re= quest is more proper. > > Sheng > > >>7.) What should the host do after timers expire.? And is the DHCPv6 > >>RECONFIGURE message supported for this option type. I think this should > >>be clarified in the draft. > > > >Have added two sentences in Section 4 to describe the potential follow u= p > >operation: > > > >When the host reaches T1 or T2 defined in Section 5.1, it SHOULD use the > >same message exchanges, as described in section 18, "DHCP Client-Initiat= ed > >Configuration Exchange" of [RFC3315], to obtain or update prefix(es) fro= m a > >DHCPv6 server. > > > >A DHCPv6 server MAY initiatively send a reconfiguration message to the h= ost, > >as described in section 19, "DHCP Server- Initiated Configuration Exchan= ge" > >of [RFC3315], to cause prefix(es) information update. > > > >Best regards, > > > >Sheng > > > >>Thanks, > >>Gaurav > >> > >>-----Original Message----- > >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On > >Behalf > >>Of Ted Lemon > >>Sent: Monday, August 13, 2012 7:35 AM > >>To: dhc WG > >>Subject: [MARKETING] [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 > >> > >>The authors have requested a working group last call for this draft. = The > >>draft provides a mechanism whereby the DHCP server can indicate to the > >>DHCP client which prefix it should use for autoconfiguration, for insta= nce for > >>CGA address generation. This draft has been hanging around for a whil= e, > >>and could definitely use more eyes on it. Please take the time to rev= iew it; > >>if you think it's a good idea, please indicate your support for advanci= ng the > >>draft. If you think it's a bad idea, please indicate that you do not = support > >>advancing it. If you have comments, they would be very much > >appreciated. > >> > >>We will determine consensus on August 27. > >> > >>_______________________________________________ > >>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 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Andre Kostur From eleven.fuyu@huawei.com Tue Aug 14 21:59:22 2012 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 B01EB21E80BD for ; Tue, 14 Aug 2012 21:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 tWk89EVbgqGY for ; Tue, 14 Aug 2012 21:59:21 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8758321E80AB for ; Tue, 14 Aug 2012 21:59:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJK72811; Tue, 14 Aug 2012 20:59:20 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 21:54:32 -0700 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 21:54:35 -0700 Received: from SZXEML512-MBX.china.huawei.com ([169.254.5.25]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 12:54:33 +0800 From: "Fuyu (Eleven)" To: Ted Lemon Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdaQLLQ Date: Wed, 15 Aug 2012 04:54:32 +0000 Message-ID: References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> In-Reply-To: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 04:59:22 -0000 I am in favor of advancing this work. BTW, some comments below Section 4 part 1: This part describes that referring the IA_PD, a new IA_PA= option is defined to insert into the DHCP message.=20 And Section 5 the last sentence also describes that " However, the two opti= ons are different on the semantics and usage models."=20 I think it need some more words to describe the difference between these tw= o options in which scenario use IA_PD and in which scenario use the IA_PA in this part. Figure 1: I suggest to add message 4 (Request message) after the message 3 = to confirm the usage of the new address as the whole=20 configuration process. And I also think it is better to add the option name= after the DHCP message in the figure 1.=20 Some typo: Section 1 the last sentence: supports-support=20 Section 1 paragraph 4 the last sentence: separats->separates Cheers=20 Yu -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Monday, August 13, 2012 10:05 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 The authors have requested a working group last call for this draft. The = draft provides a mechanism whereby the DHCP server can indicate to the DHCP= client which prefix it should use for autoconfiguration, for instance for = CGA address generation. This draft has been hanging around for a while, a= nd could definitely use more eyes on it. Please take the time to review i= t; if you think it's a good idea, please indicate your support for advancin= g the draft. If you think it's a bad idea, please indicate that you do no= t support advancing it. If you have comments, they would be very much app= reciated. We will determine consensus on August 27. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Tue Aug 14 23:05:45 2012 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 64B5B11E80A6 for ; Tue, 14 Aug 2012 23:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 IlEfDmM0sf1q for ; Tue, 14 Aug 2012 23:05:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6578B21F85D1 for ; Tue, 14 Aug 2012 23:05:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJK76004; Tue, 14 Aug 2012 22:05:41 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 23:03:43 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 23:03:42 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 14:03:36 +0800 From: Sheng Jiang To: Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+Bcg//+14QCAAJkEMA== Date: Wed, 15 Aug 2012 06:03:35 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F06196@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 06:05:45 -0000 SGksIEFuZHJlLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuIE9STyBpbiBTb2xpY2l0IGlzIHN1 cHBvcnQgaW4gdGhlIGRvY3VtZW50LiANCg0KUmVxdWVzdCBwcmVmaXggYXNzaWdubWVudCB0aHJv dWdoIHNvbGljaXQgb3IgcmVxdWVzdCBtZXNzYWdlIGhhcHBlbiBpbiBkaWZmZXJlbnQgc2NlbmFy aW9zOiBPUk8gaW4gU29saWNpdCBpcyBmb3IgdHdvIG1lc3NhZ2UgbW9kdWxlLiBJbiBmb3VyIG1l c3NhZ2UgbW9kdWxlLiBTb2xpY2l0IGlzIG9ubHkgdXNlZCB0byBkaXNjb3ZlciBESENQdjYuIEFm dGVyIHRoYXQsIFJlcXVlc3QgbWVzc2FnZSBpcyB1c2VkIGZvciBpbmZvcm1hdGlvbiBvYnRhaW5p bmcuDQoNClJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PkZyb206IEFuZHJlIEtvc3R1ciBbbWFpbHRvOmFrb3N0dXJAaW5jb2duaXRvLmNvbV0NCj5TZW50 OiBXZWRuZXNkYXksIEF1Z3VzdCAxNSwgMjAxMiAxMjo0MiBQTQ0KPlRvOiBTaGVuZyBKaWFuZw0K PkNjOiBHYXVyYXYgSGFsd2FzaWEgKGdoYWx3YXNpKTsgVGVkIExlbW9uOyBkaGMgV0cNCj5TdWJq ZWN0OiBSZTogW2RoY3dnXSBXR0xDOiBkcmFmdC1pZXRmLWRoYy1ob3N0LWdlbi1pZC0wMg0KPg0K PkkgdGhpbmsgdGhhdCBpZiB0aGUgZGV2aWNlIHdhbnRzIGEgUEEsIGl0IHNob3VsZCBzdXBwbHkg YW4gSUFfUEEgaW4NCj5pdHMgU29saWNpdC4gIFRoZSBkZXZpY2UgbmVlZHMgdG8gc3BlY2lmeSBh biBJQUlELiAgQW4gT1JPIGlzDQo+aW5zdWZmaWNpZW50Lg0KPg0KPg0KPk9uIFR1ZSwgQXVnIDE0 LCAyMDEyIGF0IDg6MTIgUE0sIFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20+DQo+ d3JvdGU6DQo+Pg0KPj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+RnJvbTogU2hl bmcgSmlhbmcgW21haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb21dDQo+PiA+U2VudDogTW9uZGF5 LCBBdWd1c3QgMTMsIDIwMTIgMTowNSBQTQ0KPj4gPlRvOiBHYXVyYXYgSGFsd2FzaWEgKGdoYWx3 YXNpKTsgVGVkIExlbW9uOyBkaGMgV0cNCj4+ID5TdWJqZWN0OiBSRTogV0dMQzogZHJhZnQtaWV0 Zi1kaGMtaG9zdC1nZW4taWQtMDINCj4+ID4NCj4+ID5IaSwgR2F1cmF2LA0KPj4gPg0KPj4gPlRo YW5rcyBmb3IgeW91ciBjYXJlZnVsbHkgcmV2aWV3LiBSZXBseSBpbiBsaW5lcy4gV2l0aCBhbGwg eW91ciBjb21tZW50cw0KPj4gPmFkZHJlc3NlZCwgd291bGQgeW91IHN1cHBvcnQgdGhpcyBkb2N1 bWVudCBmb3J3YXJkPw0KPj4gPltHYXVyYXZdIENlcnRhaW5seS4gSSBzdXBwb3J0IHRoZSBkb2N1 bWVudCBmb3J3YXJkLg0KPj4gPg0KPj4gPj5JIGxpa2UgdGhlIGlkZWEgYnV0IEkgZG8gaGF2ZSBm ZXcgY29tbWVudHM6LS4NCj4+ID4+DQo+PiA+PjEuKSBBYnN0cmFjdCBkb2VzIG5vdCBzZWVtcyBj bGVhciB0byBtZS4NCj4+ID4+VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2UgYSBwcm9jZWR1cmUgZm9y IGNvbmZpZ3VyaW5nIGhvc3RzJyBJUHY2DQo+PiA+PiAgIGFkZHJlc3Mgd2hpY2ggdGhlIHByZWZp eCBpcyBhc3NpZ25lZCBmcm9tIGEgREhDUHY2IHNlcnZlciB0aHJvdWdoDQo+PiA+PiAgIERIQ1B2 NiBwcm90b2NvbCB3aGlsZSB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZXJzIGFyZSBpbmRlcGVuZGVu dGx5DQo+PiA+PiAgIGdlbmVyYXRlZCBieSB0aGUgaG9zdHMuDQo+PiA+DQo+PiA+UmV3b3JkZWQ6 IFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBhIG5ldyBESENQdjYgcHJvY2VkdXJlIHRvDQo+Y29u ZmlndXJlDQo+PiA+aG9zdHMnIElQdjYgYWRkcmVzc2VzLiBJbiB0aGlzIG5ldyBwcm9jZWR1cmUs IHRoZSBwcmVmaXggaXMgYWR2ZXJ0aXNlZCBmcm9tDQo+YQ0KPj4gPkRIQ1B2NiBzZXJ2ZXIgdGhy b3VnaCBESENQdjYgcHJvdG9jb2wgd2hpbGUgdGhlIGludGVyZmFjZSBpZGVudGlmaWVycyBhcmUN Cj4+ID5pbmRlcGVuZGVudGx5IGdlbmVyYXRlZCBieSB0aGUgaG9zdHMuDQo+PiA+DQo+PiA+PjIu KSBTZWN0aW9uIDEgLiBJbnRyb2R1Y3Rpb24uIENoYW5nZSAiaG9zdC1nZW5hcmF0ZWQiIHRvDQo+ Imhvc3QtZ2VuZXJhdGVkIg0KPj4gPj4zLikgU2VjdGlvbiAxIC4gSW50cm9kdWN0aW9uLiBDaGFu Z2UgInNlcGFyYXRzIiB0byAic2VwYXJhdGVzIg0KPj4gPj40LikgU2VjdGlvbiAxIC4gSW50cm9k dWN0aW9uLiBDaGFuZ2UgImluZ2VyZmFjZSBpZGVudGlmaWVycyIgdG8NCj4+ID4+ImludGVyZmFj ZSBpZGVudGlmaWVycyINCj4+ID4NCj4+ID5BbGwgY2hhbmdlZC4NCj4+ID4NCj4+ID4+NS4pIFNl Y3Rpb24gNC4gIFRoaXMgc2VjdGlvbiB0YWxrcyBhYm91dCB0aGUgbmV3IElBX1BBIG9wdGlvbiBi dXQgZG9lcw0KPj4gPj5ub3QgZXhwbGljaXRseSBzYXkgdGhhdCB0aGlzIG9wdGlvbiBuZWVkcyB0 byBiZSBpbnNlcnRlZCBpbiBTT0xJQ0lUDQo+bWVzc2FnZS4NCj4+ID4NCj4+ID5IYXZlIGFkZGVk IGEgc2VudGVuY2UgZm9yIHRoaXMuIEhvd2V2ZXIsIHRoaXMgaXMgb25seSBhIE1BWS4gIkEgaG9z dCBNQVkNCj4+ID5pbmNsdWRlIGEgT3B0aW9uIFJlcXVlc3QgT3B0aW9uIGluIGEgU29saWNpdCBv ciBSZXF1ZXN0IG1lc3NhZ2UgdG8gcmVxdWVzdA0KPmENCj4+ID5JQV9QQSBleHBsaWNpdGx5LiIg VGhlIHByZWZpeCBhc3NpZ25tZW50IGNvdWxkIGJlIGluIGFkdmVydGlzZSBtb2RlbC4gSXQgaXMN Cj5ub3QNCj4+ID5uZWNlc3NhcnkgdGhhdCBhIGhvc3QgcmVxdWVzdCBhIElBX1BBLg0KPj4gPltH YXVyYXZdIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIHBhcnQgY29tcGxldGVseS4gU28geW91IGFy ZSBzYXlpbmcgdGhhdA0KPmhvc3QNCj4+ID5jYW4gc2VuZCAiREhDUCBSRVFVRVNUIiBtZXNzYWdl IGFzIHdlbGwgaW5zdGVhZCBvZiBTT0xJQ0lULj8gQ2FuIHlvdQ0KPj4gPnBsZWFzZSBlbGFib3Jh dGUgaXQgaW4gZGV0YWlsLg0KPj4NCj4+IDxTaGVuZz5ZZXMuIEFmdGVyIGRpc2NvdmVyeSBhIERI Q1B2NiBzZXJ2ZXIgd2l0aCBzb2xpY2l0IG1lc3NhZ2UsIGEgaG9zdA0KPmNhbiB1c2UgYSBSZXF1 ZXN0IG1lc3NhZ2UgdG8gcmVxdWVzdCBwcmVmaXggYXNzaWdubWVudCBieSBpbmNsdWRlIGEgSUFf UEEsDQo+aW5zdGVhZCBvZiBJQV9OQSBvciBJQV9UQS4gVGhlIHNlcnZlciB0aGVuIHJldHVybiBw cmVmaXggaW5mb3JtYXRpb24gcmF0aGVyDQo+dGhhbiBhZGRyZXNzLiBJbiBvdXIgdW5kZXJzdGFu ZGluZywgdGhpcyBwcm9jZWR1cmUgaXMgb25lIHdheSBvZiBhZGRyZXNzDQo+Y29uZmlndXJhdGlv biwgbm90IG90aGVyIGluZm9ybWF0aW9uLg0KPj4NCj4+IE9vcHMuLi4gV2l0aCB0aGlzLCBpdCBz ZWVtcyB3ZSB1cGRhdGUgUkZDMzMxNSBhIGxpdHRsZSBiaXQuIE1heWJlIHdlIHNob3VsZA0KPmlu Y2x1ZGUgYW4gdXBkYXRlIGhlYWRlciBpbiB0aGUgZG9jdW1lbnQuDQo+Pg0KPj4gVGhlIGFib3Zl IHNlbnRlbmNlIG5lZWRzIGEgbGl0dGxlIGJpdCByZXZpc2U6ICJBIGhvc3QgTUFZIGluY2x1ZGUg YSBPcHRpb24NCj5SZXF1ZXN0IE9wdGlvbiBpbiBhIFNvbGljaXQgb3IgSUFfUEEgaW4gYSBSZXF1 ZXN0IG1lc3NhZ2UgdG8gcmVxdWVzdCBhIHByZWZpeA0KPmFzc2lnbm1lbnQgZXhwbGljaXRseS4i DQo+Pg0KPj4gV2hlbiB0aGUgcHJlZml4IGFzc2lnbm1lbnQgaW4gYWR2ZXJ0aXNlIG1vZGVsLCBl dmVuIGlmIGEgaG9zdCBkb2VzIG5vdA0KPnJlcXVlc3QsIERIQ1B2NiBzZXJ2ZXIgY2FuIHB1c2gg aXQgaW5pdGlhdGl2ZWx5Lg0KPj4NCj4+ID4+Ni4pIEFzIHRoaXMgcHJvY2VkdXJlIGlzIGluZGVl ZCAic3RhdGUgbGVzcyIgZnJvbSB0aGUgREhDUHY2DQo+PiA+PnBlcnNwZWN0aXZlLCB3aHkgZG9u J3Qgd2Ugd2FudCB0byB1c2UgIkluZm9ybWF0aW9uLVJlcXVlc3QiIG1lc3NhZ2UNCj4+ID4+aW5z dGVhZCBvZiBTT0xJQ0lUIGZyb20gdGhlIGhvc3QuPw0KPj4gPg0KPj4gPlJlcXVlc3QgbWVzc2Fn ZSBpcyBwb3NzaWJsZSwgdG9vLiBTZWUgdGhlIGFib3ZlIG5ldyBzZW50ZW5jZS4NCj4+ID4NCj4+ ID5bR2F1cmF2XSBJIHdhcyByZWZlcnJpbmcgdG8gIkluZm9ybWF0aW9uLVJlcXVlc3QoMTEpIiBt ZXNzYWdlIG5vdA0KPj4gPiJSZXF1ZXN0KDMpIg0KPj4NCj4+IEFzIGV4cGxhaW5lZCBhYm92ZSwg d2UgdGhpbmsgdGhpcyBwcm9jZWR1cmUgaXMgYWRkcmVzcyBhc3NvY2lhdGVkLiBTbywNCj5SZXF1 ZXN0IGlzIG1vcmUgcHJvcGVyLg0KPj4NCj4+IFNoZW5nDQo+Pg0KPj4gPj43LikgV2hhdCBzaG91 bGQgdGhlIGhvc3QgZG8gYWZ0ZXIgdGltZXJzIGV4cGlyZS4/IEFuZCBpcyB0aGUgREhDUHY2DQo+ PiA+PlJFQ09ORklHVVJFIG1lc3NhZ2Ugc3VwcG9ydGVkIGZvciB0aGlzIG9wdGlvbiB0eXBlLiBJ IHRoaW5rIHRoaXMgc2hvdWxkDQo+PiA+PmJlIGNsYXJpZmllZCBpbiB0aGUgZHJhZnQuDQo+PiA+ DQo+PiA+SGF2ZSBhZGRlZCB0d28gc2VudGVuY2VzIGluIFNlY3Rpb24gNCB0byBkZXNjcmliZSB0 aGUgcG90ZW50aWFsIGZvbGxvdyB1cA0KPj4gPm9wZXJhdGlvbjoNCj4+ID4NCj4+ID5XaGVuIHRo ZSBob3N0IHJlYWNoZXMgVDEgb3IgVDIgZGVmaW5lZCBpbiBTZWN0aW9uIDUuMSwgaXQgU0hPVUxE IHVzZSB0aGUNCj4+ID5zYW1lIG1lc3NhZ2UgZXhjaGFuZ2VzLCBhcyBkZXNjcmliZWQgaW4gc2Vj dGlvbiAxOCwgIkRIQ1ANCj5DbGllbnQtSW5pdGlhdGVkDQo+PiA+Q29uZmlndXJhdGlvbiBFeGNo YW5nZSIgb2YgW1JGQzMzMTVdLCB0byBvYnRhaW4gb3IgdXBkYXRlIHByZWZpeChlcykgZnJvbQ0K PmENCj4+ID5ESENQdjYgc2VydmVyLg0KPj4gPg0KPj4gPkEgREhDUHY2IHNlcnZlciBNQVkgaW5p dGlhdGl2ZWx5IHNlbmQgYSByZWNvbmZpZ3VyYXRpb24gbWVzc2FnZSB0byB0aGUNCj5ob3N0LA0K Pj4gPmFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDE5LCAiREhDUCBTZXJ2ZXItIEluaXRpYXRlZCBD b25maWd1cmF0aW9uDQo+RXhjaGFuZ2UiDQo+PiA+b2YgW1JGQzMzMTVdLCB0byBjYXVzZSBwcmVm aXgoZXMpIGluZm9ybWF0aW9uIHVwZGF0ZS4NCj4+ID4NCj4+ID5CZXN0IHJlZ2FyZHMsDQo+PiA+ DQo+PiA+U2hlbmcNCj4+ID4NCj4+ID4+VGhhbmtzLA0KPj4gPj5HYXVyYXYNCj4+ID4+DQo+PiA+ Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PkZyb206IGRoY3dnLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4gPkJlaGFsZg0KPj4g Pj5PZiBUZWQgTGVtb24NCj4+ID4+U2VudDogTW9uZGF5LCBBdWd1c3QgMTMsIDIwMTIgNzozNSBB TQ0KPj4gPj5UbzogZGhjIFdHDQo+PiA+PlN1YmplY3Q6IFtNQVJLRVRJTkddIFtkaGN3Z10gV0dM QzogZHJhZnQtaWV0Zi1kaGMtaG9zdC1nZW4taWQtMDINCj4+ID4+DQo+PiA+PlRoZSBhdXRob3Jz IGhhdmUgcmVxdWVzdGVkIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIHRoaXMgZHJhZnQu DQo+VGhlDQo+PiA+PmRyYWZ0IHByb3ZpZGVzIGEgbWVjaGFuaXNtIHdoZXJlYnkgdGhlIERIQ1Ag c2VydmVyIGNhbiBpbmRpY2F0ZSB0byB0aGUNCj4+ID4+REhDUCBjbGllbnQgd2hpY2ggcHJlZml4 IGl0IHNob3VsZCB1c2UgZm9yIGF1dG9jb25maWd1cmF0aW9uLCBmb3IgaW5zdGFuY2UNCj5mb3IN Cj4+ID4+Q0dBIGFkZHJlc3MgZ2VuZXJhdGlvbi4gICBUaGlzIGRyYWZ0IGhhcyBiZWVuIGhhbmdp bmcgYXJvdW5kIGZvciBhDQo+d2hpbGUsDQo+PiA+PmFuZCBjb3VsZCBkZWZpbml0ZWx5IHVzZSBt b3JlIGV5ZXMgb24gaXQuICAgUGxlYXNlIHRha2UgdGhlIHRpbWUgdG8NCj5yZXZpZXcgaXQ7DQo+ PiA+PmlmIHlvdSB0aGluayBpdCdzIGEgZ29vZCBpZGVhLCBwbGVhc2UgaW5kaWNhdGUgeW91ciBz dXBwb3J0IGZvciBhZHZhbmNpbmcNCj50aGUNCj4+ID4+ZHJhZnQuICAgSWYgeW91IHRoaW5rIGl0 J3MgYSBiYWQgaWRlYSwgcGxlYXNlIGluZGljYXRlIHRoYXQgeW91IGRvIG5vdA0KPnN1cHBvcnQN Cj4+ID4+YWR2YW5jaW5nIGl0LiAgIElmIHlvdSBoYXZlIGNvbW1lbnRzLCB0aGV5IHdvdWxkIGJl IHZlcnkgbXVjaA0KPj4gPmFwcHJlY2lhdGVkLg0KPj4gPj4NCj4+ID4+V2Ugd2lsbCBkZXRlcm1p bmUgY29uc2Vuc3VzIG9uIEF1Z3VzdCAyNy4NCj4+ID4+DQo+PiA+Pl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PmRoY3dnIG1haWxpbmcgbGlzdA0K Pj4gPj5kaGN3Z0BpZXRmLm9yZw0KPj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RoY3dnDQo+PiA+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiA+PmRoY3dnIG1haWxpbmcgbGlzdA0KPj4gPj5kaGN3Z0BpZXRmLm9yZw0K Pj4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gZGhjd2cgbWFp bGluZyBsaXN0DQo+PiBkaGN3Z0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaGN3Zw0KPg0KPg0KPg0KPg0KPi0tDQo+QW5kcmUgS29zdHVyDQo= From jiangsheng@huawei.com Tue Aug 14 23:14:09 2012 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 4168711E80A6 for ; Tue, 14 Aug 2012 23:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 ls+N-Lvw6dqs for ; Tue, 14 Aug 2012 23:14:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB4011E80A4 for ; Tue, 14 Aug 2012 23:14:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJK76428; Tue, 14 Aug 2012 22:14:08 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 23:11:18 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 23:11:22 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 14:10:56 +0800 From: Sheng Jiang To: "Fuyu (Eleven)" , Ted Lemon Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdaQLLQgAAgdoA= Date: Wed, 15 Aug 2012 06:10:56 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F061A5@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 06:14:09 -0000 SGksIFl1LA0KDQpUaGFua3MgeW91ciBzdXBwb3J0IGFuZCBjb21tZW50cy4gU29tZSByZXBsaWVz IGluIGxpbmVzLg0KDQpSZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj5Gcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+T2YgRnV5dSAoRWxldmVuKQ0KPlNlbnQ6IFdlZG5lc2Rh eSwgQXVndXN0IDE1LCAyMDEyIDEyOjU1IFBNDQo+VG86IFRlZCBMZW1vbg0KPkNjOiBkaGMgV0cN Cj5TdWJqZWN0OiBSZTogW2RoY3dnXSBXR0xDOiBkcmFmdC1pZXRmLWRoYy1ob3N0LWdlbi1pZC0w Mg0KPg0KPkkgYW0gaW4gZmF2b3Igb2YgYWR2YW5jaW5nIHRoaXMgd29yay4NCj4NCj5CVFcsIHNv bWUgY29tbWVudHMgYmVsb3cNCj5TZWN0aW9uIDQgcGFydCAxOiBUaGlzIHBhcnQgZGVzY3JpYmVz IHRoYXQgcmVmZXJyaW5nIHRoZSBJQV9QRCwgYSBuZXcgSUFfUEENCj5vcHRpb24gaXMgZGVmaW5l ZCB0byBpbnNlcnQgaW50byB0aGUgREhDUCBtZXNzYWdlLg0KPkFuZCBTZWN0aW9uIDUgdGhlIGxh c3Qgc2VudGVuY2UgYWxzbyBkZXNjcmliZXMgdGhhdCAiIEhvd2V2ZXIsIHRoZSB0d28NCj5vcHRp b25zIGFyZSBkaWZmZXJlbnQgb24gdGhlIHNlbWFudGljcyBhbmQgdXNhZ2UgbW9kZWxzLiINCj5J IHRoaW5rIGl0IG5lZWQgc29tZSBtb3JlIHdvcmRzIHRvIGRlc2NyaWJlIHRoZSBkaWZmZXJlbmNl IGJldHdlZW4gdGhlc2UNCj50d28gb3B0aW9ucyBpbiB3aGljaCBzY2VuYXJpbyB1c2UgSUFfUEQg YW5kIGluIHdoaWNoIHNjZW5hcmlvDQo+dXNlIHRoZSBJQV9QQSBpbiB0aGlzIHBhcnQuDQoNClBy ZWZpeCBkZWxlZ2F0aW9uIGFuZCBQcmVmaXggYXNzaWdubWVudCBhcmUgcXVpdGUgZGlmZmVyZW50 OiBJQV9QRCBpcyBhY3R1YWxseSB1c2VkIGFtb25nIHJvdXRlcnMuIFRoaXMgaGFzIGJlZW4gZGVz Y3JpYmVkIGluIHRoaXJkIHBhcmFncmFwaCBvZiBpbnRyb2R1Y3Rpb24gc2Vzc2lvbi4NCg0KPkZp Z3VyZSAxOiBJIHN1Z2dlc3QgdG8gYWRkIG1lc3NhZ2UgNCAoUmVxdWVzdCBtZXNzYWdlKSBhZnRl ciB0aGUgbWVzc2FnZSAzDQo+dG8gY29uZmlybSB0aGUgdXNhZ2Ugb2YgdGhlIG5ldyBhZGRyZXNz IGFzIHRoZSB3aG9sZQ0KPmNvbmZpZ3VyYXRpb24gcHJvY2Vzcy4NCg0KV2UgaGF2ZSBzdGF0ZWQg dGhpcyBpcyBvdXQgb2Ygc2NvcGUgYW5kIGFkZGVkIGEgcmVmZXJlbmNlIHRvIEktRC5pZXRmLWRo Yy1hZGRyLXJlZ2lzdHJhdGlvbiwgd2hpY2ggZGVmaW5lcyB0aGUgYWRkcmVzcyBjb25maXJtYXRp b24vcmVnaXN0cmF0aW9uIHByb2Nlc3MuDQoNCj5BbmQgSSBhbHNvIHRoaW5rIGl0IGlzIGJldHRl ciB0byBhZGQgdGhlIG9wdGlvbiBuYW1lDQo+YWZ0ZXIgdGhlIERIQ1AgbWVzc2FnZSBpbiB0aGUg ZmlndXJlIDEuDQoNCkFkZGVkDQoNCj5Tb21lIHR5cG86IFNlY3Rpb24gMSB0aGUgbGFzdCBzZW50 ZW5jZTogc3VwcG9ydHMtc3VwcG9ydA0KPiAgICAgICAgIFNlY3Rpb24gMSBwYXJhZ3JhcGggNCB0 aGUgbGFzdCBzZW50ZW5jZTogc2VwYXJhdHMtPnNlcGFyYXRlcw0KDQpFY2hvLg0KDQpTaGVuZw0K DQo+Q2hlZXJzDQo+WXUNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGRo Y3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYNCj5PZiBUZWQgTGVtb24NCj5TZW50OiBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAxMDow NSBBTQ0KPlRvOiBkaGMgV0cNCj5TdWJqZWN0OiBbZGhjd2ddIFdHTEM6IGRyYWZ0LWlldGYtZGhj LWhvc3QtZ2VuLWlkLTAyDQo+DQo+VGhlIGF1dGhvcnMgaGF2ZSByZXF1ZXN0ZWQgYSB3b3JraW5n IGdyb3VwIGxhc3QgY2FsbCBmb3IgdGhpcyBkcmFmdC4gICBUaGUNCj5kcmFmdCBwcm92aWRlcyBh IG1lY2hhbmlzbSB3aGVyZWJ5IHRoZSBESENQIHNlcnZlciBjYW4gaW5kaWNhdGUgdG8gdGhlDQo+ REhDUCBjbGllbnQgd2hpY2ggcHJlZml4IGl0IHNob3VsZCB1c2UgZm9yIGF1dG9jb25maWd1cmF0 aW9uLCBmb3IgaW5zdGFuY2UgZm9yDQo+Q0dBIGFkZHJlc3MgZ2VuZXJhdGlvbi4gICBUaGlzIGRy YWZ0IGhhcyBiZWVuIGhhbmdpbmcgYXJvdW5kIGZvciBhIHdoaWxlLA0KPmFuZCBjb3VsZCBkZWZp bml0ZWx5IHVzZSBtb3JlIGV5ZXMgb24gaXQuICAgUGxlYXNlIHRha2UgdGhlIHRpbWUgdG8gcmV2 aWV3IGl0Ow0KPmlmIHlvdSB0aGluayBpdCdzIGEgZ29vZCBpZGVhLCBwbGVhc2UgaW5kaWNhdGUg eW91ciBzdXBwb3J0IGZvciBhZHZhbmNpbmcgdGhlDQo+ZHJhZnQuICAgSWYgeW91IHRoaW5rIGl0 J3MgYSBiYWQgaWRlYSwgcGxlYXNlIGluZGljYXRlIHRoYXQgeW91IGRvIG5vdCBzdXBwb3J0DQo+ YWR2YW5jaW5nIGl0LiAgIElmIHlvdSBoYXZlIGNvbW1lbnRzLCB0aGV5IHdvdWxkIGJlIHZlcnkg bXVjaCBhcHByZWNpYXRlZC4NCj4NCj5XZSB3aWxsIGRldGVybWluZSBjb25zZW5zdXMgb24gQXVn dXN0IDI3Lg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ZGhjd2cgbWFpbGluZyBsaXN0DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5kaGN3ZyBtYWlsaW5nIGxpc3QNCj5kaGN3Z0BpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg== From shenshuo@cnnic.cn Wed Aug 15 00:51:08 2012 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 760F421F86F9 for ; Wed, 15 Aug 2012 00:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.765 X-Spam-Level: **** X-Spam-Status: No, score=4.765 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] 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 D741jIiiIkJ9 for ; Wed, 15 Aug 2012 00:51:06 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 3A1C221F86F4 for ; Wed, 15 Aug 2012 00:51:05 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: shenshuo@cnnic.cn Received: from unknown127.0.0.1 (HELO sonyvaio) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 15 Aug 2012 15:50:53 +0800 From: =?gb2312?B?U2VhbiBTaGVuIMnyy7g=?= To: "'Ted Lemon'" , "'dhc WG'" Date: Wed, 15 Aug 2012 15:50:59 +0800 Organization: CNNIC Message-ID: <059301cd7aba$b5f83220$21e89660$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16unpRXD+uKr6wSLyG33U6ppRo0g== Content-Language: zh-cn Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 07:51:08 -0000 I am support this idea and the solution looks fine for me. -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] =B4=FA=B1=ED Ted Lemon =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA8=D4=C213=C8=D5 10:05 =CA=D5=BC=FE=C8=CB: dhc WG =D6=F7=CC=E2: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 The authors have requested a working group last call for this draft. = The draft provides a mechanism whereby the DHCP server can indicate to the = DHCP client which prefix it should use for autoconfiguration, for instance = for CGA address generation. This draft has been hanging around for a = while, and could definitely use more eyes on it. Please take the time to = review it; if you think it's a good idea, please indicate your support for advancing the draft. If you think it's a bad idea, please indicate = that you do not support advancing it. If you have comments, they would be = very much appreciated. We will determine consensus on August 27. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From guodayong@huawei.com Wed Aug 15 01:07:28 2012 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 0933821F874C for ; Wed, 15 Aug 2012 01:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 6NJEhEFMikWQ for ; Wed, 15 Aug 2012 01:07:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7362E21F8749 for ; Wed, 15 Aug 2012 01:07:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIW75977; Wed, 15 Aug 2012 00:07:27 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 01:05:15 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 01:05:13 -0700 Received: from peky1g577751 (10.111.54.53) by smtpscn.huawei.com (10.82.67.152) with Microsoft SMTP Server id 14.1.323.3; Wed, 15 Aug 2012 16:05:08 +0800 From: g57775 To: 'Ted Lemon' , dhc WG References: <4D779082-B182-4728-9534-39456573682E@nominum.com> In-Reply-To: <4D779082-B182-4728-9534-39456573682E@nominum.com> Date: Wed, 15 Aug 2012 16:05:08 +0800 Message-ID: <000101cd7abc$afd45160$0f7cf420$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNdvWqSDMOAnuzpUmlatl1eCUEGJdafJzg Content-Language: zh-cn X-Originating-IP: [10.111.54.53] X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-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: Wed, 15 Aug 2012 08:07:28 -0000 I support advancing it. Thanks. Dayong Guo -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] =B4=FA=B1=ED Ted Lemon =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA8=D4=C210=C8=D5 20:43 =CA=D5=BC=FE=C8=CB: dhc WG =D6=F7=CC=E2: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt The authors of this draft have requested a working group last call. = The draft explains how DHCP clients operate in an environment where the interface being configured doesn't support multicast (e.g., 6RD). If = this is a matter of interest to you, please review the draft and send = comments to the list. If you are in favor of advancing the draft, please say so on the list; = if nobody supports it, it won't advance. If you oppose advancing it, = please also say so. We will determine consensus on August 24. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From zhangdacheng@huawei.com Wed Aug 15 02:12:26 2012 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 2D2EA21F875D for ; Wed, 15 Aug 2012 02:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=0.947, 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 0Uzq1BjBjx1t for ; Wed, 15 Aug 2012 02:12:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 87F1D21F8757 for ; Wed, 15 Aug 2012 02:12:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJK86180; Wed, 15 Aug 2012 01:12:20 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 02:10:12 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 02:10:10 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.24]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 17:10:06 +0800 From: "Zhangdacheng (Dacheng)" To: Ted Lemon , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNdvWqSDMOAnuzpUmlatl1eCUEGJdanYZw Date: Wed, 15 Aug 2012 09:10:05 +0000 Message-ID: References: <4D779082-B182-4728-9534-39456573682E@nominum.com> In-Reply-To: <4D779082-B182-4728-9534-39456573682E@nominum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-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: Wed, 15 Aug 2012 09:12:26 -0000 +1 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Ted Lemon > Sent: Friday, August 10, 2012 8:43 PM > To: dhc WG > Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt >=20 > The authors of this draft have requested a working group last call. The= draft > explains how DHCP clients operate in an environment where the interface > being configured doesn't support multicast (e.g., 6RD). If this is a ma= tter of > interest to you, please review the draft and send comments to the list. >=20 > If you are in favor of advancing the draft, please say so on the list; if= nobody > supports it, it won't advance. If you oppose advancing it, please also = say so. > We will determine consensus on August 24. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Aug 15 06:11:42 2012 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 CDCBB21F8805 for ; Wed, 15 Aug 2012 06:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2c8YHBFmkLJK for ; Wed, 15 Aug 2012 06:11:42 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id E3FB621F87C3 for ; Wed, 15 Aug 2012 06:11:41 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUCugBhg7flFPuP1aFtcrVcmW5vj/mc3M@postini.com; Wed, 15 Aug 2012 06:11:41 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 BDA861B82CB for ; Wed, 15 Aug 2012 06:11:33 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 B2BFB190052; Wed, 15 Aug 2012 06:11:33 -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.02.0247.003; Wed, 15 Aug 2012 06:11:33 -0700 From: Ted Lemon To: Sheng Jiang Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggAE/oYA= Date: Wed, 15 Aug 2012 13:11:33 +0000 Message-ID: <1FCEAFB3-2942-4D31-B955-DCC167F69562@nominum.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.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: multipart/alternative; boundary="_000_1FCEAFB329424D31B955DCC167F69562nominumcom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 13:11:42 -0000 --_000_1FCEAFB329424D31B955DCC167F69562nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 14, 2012, at 11:12 PM, Sheng Jiang wrote: When the prefix assignment in advertise model, even if a host does not requ= est, DHCPv6 server can push it initiatively. It's hard to imagine a situation where this would be useful. If the clien= t doesn't already know about IA_PA, how is it going to know what to do when= it gets one? It seems to me that it would make more sense either to requ= est an IA_PA in the ORO (in which case it would come in the advertise) or e= lse just include an IA_PA in the Solicit. --_000_1FCEAFB329424D31B955DCC167F69562nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6B6D316C61162A49B026CE7F317708B1@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 14, 2012, at 11:12 PM, Sheng Jiang wrote:
When the prefix assignment in advertise model, even if a host does not request,= DHCPv6 server can push it initiatively.

It's hard to imagine a situation where this would be useful.   If= the client doesn't already know about IA_PA, how is it going to know what = to do when it gets one?   It seems to me that it would make more sense= either to request an IA_PA in the ORO (in which case it would come in the advertise) or else just include an IA_PA i= n the Solicit.

--_000_1FCEAFB329424D31B955DCC167F69562nominumcom_-- From Ted.Lemon@nominum.com Wed Aug 15 06:14:56 2012 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 C2DE621F883B for ; Wed, 15 Aug 2012 06:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3-rCEA8ORj2P for ; Wed, 15 Aug 2012 06:14:56 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5BE21F8827 for ; Wed, 15 Aug 2012 06:14:56 -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 DSNKUCugz3w3i9klYoJORLRF2QJE+cAnX71d@postini.com; Wed, 15 Aug 2012 06:14:56 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 8D6651B82D6 for ; Wed, 15 Aug 2012 06:14:54 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 83029190052; Wed, 15 Aug 2012 06:14:54 -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.02.0247.003; Wed, 15 Aug 2012 06:14:54 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggACxVgCAAI83gA== Date: Wed, 15 Aug 2012 13:14:53 +0000 Message-ID: <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.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: multipart/alternative; boundary="_000_388CD21617F9463E8CDBF084C9D43C54nominumcom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 13:14:56 -0000 --_000_388CD21617F9463E8CDBF084C9D43C54nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote: I think that if the device wants a PA, it should supply an IA_PA in its Solicit. The device needs to specify an IAID. An ORO is insufficient. The prefix is not necessarily specific to an individual client=97it's not a= prefix delegation. So I don't think an IAID is necessary at all. --_000_388CD21617F9463E8CDBF084C9D43C54nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <024C7F8054E2C749956704DE19FFC7A7@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote:
I think that if the device wants a PA, it should supply an IA_PA in
its Solicit.  The device needs to specify an IAID.  An ORO is
insufficient.

The prefix is not necessarily specific to an individual client=97it's = not a prefix delegation.   So I don't think an IAID is necessary at al= l.

--_000_388CD21617F9463E8CDBF084C9D43C54nominumcom_-- From guodayong@huawei.com Tue Aug 14 20:55:53 2012 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 79DDE21F85BB for ; Tue, 14 Aug 2012 20:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 fAfrQ0dhoxTl for ; Tue, 14 Aug 2012 20:55:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CCE9521F85B8 for ; Tue, 14 Aug 2012 20:55:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIW62081; Tue, 14 Aug 2012 19:55:51 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 20:52:43 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Aug 2012 20:52:46 -0700 Received: from SZXEML531-MBS.china.huawei.com ([169.254.4.65]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 11:52:41 +0800 From: Guodayong To: Ted Lemon , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNdvWqSDMOAnuzpUmlatl1eCUEGJdaQ8Og Date: Wed, 15 Aug 2012 03:52:41 +0000 Message-ID: <6352836D25052841AA6AD80481DF20E439939A4E@szxeml531-mbs.china.huawei.com> References: <4D779082-B182-4728-9534-39456573682E@nominum.com> In-Reply-To: <4D779082-B182-4728-9534-39456573682E@nominum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.54.53] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 15 Aug 2012 06:15:55 -0700 Subject: [dhcwg] =?gb2312?b?tPC4tDogIFdHTEM6IGRyYWZ0LWlldGYtZGhjLWRoY3B2?= =?gb2312?b?Ni10dW5uZWwtMDEudHh0?= 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, 15 Aug 2012 05:58:48 -0000 SSBzdXBwb3J0IGFkdmFuY2luZyBpdC4NCg0KVGhhbmtzLiANCg0KLS0tLS3Tyrz+1K28/i0tLS0t DQq3orz+yMs6IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIFRlZCBMZW1vbg0Kt6LLzcqxvOQ6IDIwMTLE6jjUwjEwyNUgMjA6NDMNCsrV vP7IyzogZGhjIFdHDQrW98ziOiBbZGhjd2ddIFdHTEM6IGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni10 dW5uZWwtMDEudHh0DQoNClRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQgaGF2ZSByZXF1ZXN0ZWQg YSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4gICBUaGUgZHJhZnQgZXhwbGFpbnMgaG93IERIQ1Ag Y2xpZW50cyBvcGVyYXRlIGluIGFuIGVudmlyb25tZW50IHdoZXJlIHRoZSBpbnRlcmZhY2UgYmVp bmcgY29uZmlndXJlZCBkb2Vzbid0IHN1cHBvcnQgbXVsdGljYXN0IChlLmcuLCA2UkQpLiAgIElm IHRoaXMgaXMgYSBtYXR0ZXIgb2YgaW50ZXJlc3QgdG8geW91LCBwbGVhc2UgcmV2aWV3IHRoZSBk cmFmdCBhbmQgc2VuZCBjb21tZW50cyB0byB0aGUgbGlzdC4NCg0KSWYgeW91IGFyZSBpbiBmYXZv ciBvZiBhZHZhbmNpbmcgdGhlIGRyYWZ0LCBwbGVhc2Ugc2F5IHNvIG9uIHRoZSBsaXN0OyBpZiBu b2JvZHkgc3VwcG9ydHMgaXQsIGl0IHdvbid0IGFkdmFuY2UuICAgSWYgeW91IG9wcG9zZSBhZHZh bmNpbmcgaXQsIHBsZWFzZSBhbHNvIHNheSBzby4gICBXZSB3aWxsIGRldGVybWluZSBjb25zZW5z dXMgb24gQXVndXN0IDI0Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KZGhjd2cgbWFpbGluZyBsaXN0DQpkaGN3Z0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0K From ghalwasi@cisco.com Wed Aug 15 06:27:07 2012 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 758C021F86F7 for ; Wed, 15 Aug 2012 06:27:07 -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 zd9NPcfdo3Bg for ; Wed, 15 Aug 2012 06:27:06 -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 499C521F8613 for ; Wed, 15 Aug 2012 06:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=6278; q=dns/txt; s=iport; t=1345037226; x=1346246826; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N43JV8375GPT6r7iM+Cum1Xb7Ng3p5YVw5/Su2DoZFE=; b=VIOvV/eF/ry9SmHcNkIpjPOtK4Le9icwEi5FYp7CJK8eAd6yCsX7tknN QAfR4IRASaXgRaa6HMv3yJeZ8QJaxWXNNvQtUV38wMncYVezIux5wzhO6 hVjMGSEu10o641EwB78tTXdQUUl+dzttUCIohjpkck1q2oZGCqTBPPjTH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABCjK1CtJV2Z/2dsb2JhbABFgkq3TYEHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEAQ0FCBqHa5lJoEqLCIV3YAOje4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,773,1336348800"; d="scan'208,217";a="111833971" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 15 Aug 2012 13:27:05 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7FDR5s8014167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 13:27:05 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 08:27:05 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggACPzwCAAI85gP//roIg Date: Wed, 15 Aug 2012 13:27:03 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0D55C1@xmb-aln-x06.cisco.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> In-Reply-To: <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.80.34] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.004 x-tm-as-result: No--38.752800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB0D55C1xmbalnx06ciscocom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 13:27:07 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB0D55C1xmbalnx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, I agree. It's 'state-less' usage of DHCPv6 Protocol. Also, may I am missing anything. Why do we think client using "Information-= Request" message is inappropriate in this case in comparison to using SOLIC= IT.? Thanks, Gaurav From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, August 15, 2012 6:45 PM To: Andre Kostur Cc: Sheng Jiang; Gaurav Halwasia (ghalwasi); dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote: I think that if the device wants a PA, it should supply an IA_PA in its Solicit. The device needs to specify an IAID. An ORO is insufficient. The prefix is not necessarily specific to an individual client-it's not a p= refix delegation. So I don't think an IAID is necessary at all. --_000_90903C21C73202418A48BFBE80AEE5EB0D55C1xmbalnx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ted,=

I agree. It’s ̵= 6;state-less’ usage of DHCPv6 Protocol.

 <= /p>

Also, may I am missing an= ything. Why do we think client using “Information-Request” mess= age is inappropriate in this case in comparison to using SOLICIT.?

 <= /p>

Thanks,=

Gaurav<= /p>

 <= /p>

From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
Sent: Wednesday, August 15, 2012 6:45 PM
To: Andre Kostur
Cc: Sheng Jiang; Gaurav Halwasia (ghalwasi); dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02<= /span>

 

On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote:

I th= ink that if the device wants a PA, it should supply an IA_PA in
its Solicit.  The device needs to spe= cify an IAID.  An ORO is
insufficient.

 

The prefix is not necessarily specific to an individ= ual client—it's not a prefix delegation.   So I don't think an I= AID is necessary at all.

 

--_000_90903C21C73202418A48BFBE80AEE5EB0D55C1xmbalnx06ciscocom_-- From Ted.Lemon@nominum.com Wed Aug 15 07:00:12 2012 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 AA9B321F889D for ; Wed, 15 Aug 2012 07:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JGY97l4KnvKc for ; Wed, 15 Aug 2012 07:00:12 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 46A1021F889A for ; Wed, 15 Aug 2012 07:00:11 -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 DSNKUCurautAVOaPm4KJ7NDSBZIxuEvePH4M@postini.com; Wed, 15 Aug 2012 07:00:11 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 0C0A71B8313 for ; Wed, 15 Aug 2012 07:00:10 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 F01FE190052; Wed, 15 Aug 2012 07:00:09 -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.02.0247.003; Wed, 15 Aug 2012 07:00:10 -0700 From: Ted Lemon To: "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggACxVgCAAI83gIAAA2iAgAAJQIA= Date: Wed, 15 Aug 2012 14:00:09 +0000 Message-ID: <434BDF4B-D6E7-4008-99F7-68B604E3587D@nominum.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D55C1@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB0D55C1@xmb-aln-x06.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: multipart/alternative; boundary="_000_434BDF4BD6E7400899F768B604E3587Dnominumcom_" MIME-Version: 1.0 Cc: dhc WG , Andre Kostur Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 14:00:12 -0000 --_000_434BDF4BD6E7400899F768B604E3587Dnominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Aug 15, 2012, at 9:27 AM, Gaurav Halwasia (ghalwasi) wrote: Also, may I am missing anything. Why do we think client using =93Informatio= n-Request=94 message is inappropriate in this case in comparison to using S= OLICIT.? What would the source address be? --_000_434BDF4BD6E7400899F768B604E3587Dnominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 15, 2012, at 9:27 AM, Gaurav Halwasia (ghalwasi) wrote:
Also, may I am missing anything. Why do we think client u= sing =93Information-Request=94 message is inappropriate in this case in com= parison to using SOLICIT.?

What would the source address be?


--_000_434BDF4BD6E7400899F768B604E3587Dnominumcom_-- From volz@cisco.com Wed Aug 15 07:01:17 2012 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 13B8721F8800 for ; Wed, 15 Aug 2012 07:01:17 -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 V+gCRQnLYjPO for ; Wed, 15 Aug 2012 07:01:14 -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 7E96821F86F6 for ; Wed, 15 Aug 2012 07:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=22685; q=dns/txt; s=iport; t=1345039274; x=1346248874; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4IW7ki/wE50KWnjtW9Y0OF97fbwbNcl96TBuXcn2Axk=; b=Dgk0LQNOzN99pCwLTJCBjP45LTS1IVNA8UdkfHD5q+gjqCmwMwIm1IMZ nZwLG+Zty0M+P9z5/FP8zkmADBYBHO9hzREjeX7lP2ZQatWF0LEMqujZZ WYAq3M8eBYhykf850+u9WxXpdXzTh/a8BSRq4V56vVpA4loBNvc3K1hlb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEerK1CtJXG+/2dsb2JhbABFgkq3TYEHgiABAQEEEgEaTBACAQgRBAEBCxYHBzIUCQgCBAENBQgXA4drmUugS4sIhXdgA6N7gWaCXw X-IronPort-AV: E=Sophos;i="4.77,773,1336348800"; d="scan'208,217";a="111841183" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 15 Aug 2012 14:01:13 +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 q7FE1AcR022044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 14:01:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 09:01:11 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggACPzwCAAI85gP//tRyg Date: Wed, 15 Aug 2012 14:01:11 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> In-Reply-To: <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.006 x-tm-as-result: No--38.587600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E0F4EBE06xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 14:01:17 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E0F4EBE06xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ted: If that is the case, why is there an IAID in the option (see below)? Should= n't that be removed?? If we have an IAID, then the client MUST provide this= option. If there is no IAID, then it may be possible to just put the optio= n in the ORO. However, I'd personally prefer we stick with the IA_NA/IA_TA/= IA_PD conventions and require this to be supplied by the client. If the ser= ver doesn't understand the option, it won't send it back in the Advertise/R= eply. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IA_PA | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IA_PA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I'd also suggest the following be clarified (section 4, bullet 2): If there is not a proper prefix available, a status- code is returned to the host and the procedure is terminated. What status code and where is this status code returned. Let's hope it foll= ows the IA_PD conventions (especially if we keep the IAID in the IA_PA). Th= ere is no new status code requested, do apparently it is one of the existin= g codes (RFC 3315/3633)? This work also seems to be to replacing Router Solicitation/Router Advertis= ement messages to advertise the prefixes (for stateless autoconfiguration).= Do we really want this. And, might not this be something to discuss in a s= lightly wider IETF audience. Perhaps it has already been (I haven't followe= d this work that closely). Another issue that should be addressed in the document is what a client sho= uld send when it connects to a network. How does it know that the server su= pports IA_PA and that it should be used, instead of the traditional IA_NA? = Should a client request both? Does it send some kind of probe (Solicit with= IA_PA [perhaps only in the ORO]) - and what does it do if it doesn't get a= ny response; try again for IA_NA. Personally, I do NOT think this work is ready and needs more clarity. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, August 15, 2012 9:15 AM To: Andre Kostur Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote: I think that if the device wants a PA, it should supply an IA_PA in its Solicit. The device needs to specify an IAID. An ORO is insufficient. The prefix is not necessarily specific to an individual client-it's not a p= refix delegation. So I don't think an IAID is necessary at all. --_000_489D13FBFA9B3E41812EA89F188F018E0F4EBE06xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ted:

 <= /p>

If that is the case, why = is there an IAID in the option (see below)? Shouldn’t that be removed= ?? If we have an IAID, then the client MUST provide this option. If there is no IAID, then it may be possible to just put the option in the= ORO. However, I’d personally prefer we stick with the IA_NA/IA_TA/IA= _PD conventions and require this to be supplied by the client. If the serve= r doesn’t understand the option, it won’t send it back in the Advertise/Reply.

 <= /p>

        0&n= bsp;            = ;      1       =             2 &= nbsp;           &nbs= p;     3

        0 1= 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;       OPTION_IA_PA   &nbs= p;      |       = ;  option-length         |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;            = ;           IAID (4 octet= s)            &= nbsp;          |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;            = ;            &n= bsp;   T1         &n= bsp;            = ;         |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;            = ;            &n= bsp;   T2         &n= bsp;            = ;         |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       . &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;           .

       . &n= bsp;            = ;            IA_PA-o= ptions           &nb= sp;            .

       . &n= bsp;            = ;             &= nbsp;           &nbs= p;            &= nbsp;          .

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

 <= /p>

 <= /p>

I’d also suggest th= e following be clarified (section 4, bullet 2):

 <= /p> 

       If th=
ere is not a proper prefix available, a status-
       code =
is returned to the host and the procedure is terminated.<=
/pre>

 <=
/p>

What status code and wher=
e is this status code returned. Let’s hope it follows the IA_PD conve=
ntions (especially if we keep the IAID in the IA_PA). There is
 no new status code requested, do apparently it is one of the existing code=
s (RFC 3315/3633)?




 




 <=
/p>

This work also seems to b=
e to replacing Router Solicitation/Router Advertisement messages to adverti=
se the prefixes (for stateless autoconfiguration). Do we
 really want this. And, might not this be something to discuss in a slightl=
y wider IETF audience. Perhaps it has already been (I haven’t followe=
d this work that closely).




 




 <=
/p>

Another issue that should=
 be addressed in the document is what a client should send when it connects=
 to a network. How does it know that the server supports
 IA_PA and that it should be used, instead of the traditional IA_NA? Should=
 a client request both? Does it send some kind of probe (Solicit with IA_PA=
 [perhaps only in the ORO]) – and what does it do if it doesn’t=
 get any response; try again for IA_NA.


 <=
/p>

Personally, I do NOT thin=
k this work is ready and needs more clarity.


 <=
/p>

- =
        
Bernie=



 <=
/p>





From: dhcwg-bo=
unces@ietf.org [mailto:dhcwg-bounces@ietf.org]
On Behalf Of Ted Lemon

Sent: Wednesday, August 15, 2012 9:15 AM

To: Andre Kostur

Cc: dhc WG

Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02<=
/span>






 






On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote:






I th=
ink that if the device wants a PA, it should supply an IA_PA in

its Solicit.  The device needs to spe=
cify an IAID.  An ORO is

insufficient.






 




The prefix is not necessarily specific to an individ=
ual client—it's not a prefix delegation.   So I don't think an I=
AID is necessary at all.






 
--_000_489D13FBFA9B3E41812EA89F188F018E0F4EBE06xmbrcdx04ciscoc_-- From Ted.Lemon@nominum.com Wed Aug 15 07:02:33 2012 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 8509B21F88A8 for ; Wed, 15 Aug 2012 07:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 orKUblhWgfFX for ; Wed, 15 Aug 2012 07:02:33 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id B590121F88A1 for ; Wed, 15 Aug 2012 07:02:32 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUCur+GBlkXKotHZUUvP5eKcm9K2KuBpA@postini.com; Wed, 15 Aug 2012 07:02:32 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 E2C2A1B8307 for ; Wed, 15 Aug 2012 07:02:31 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 DB4B5190052; Wed, 15 Aug 2012 07:02:31 -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.02.0247.003; Wed, 15 Aug 2012 07:02:32 -0700 From: Ted Lemon To: "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggACxVgCAAI83gIAAA2iAgAAJQICAAACpgA== Date: Wed, 15 Aug 2012 14:02:30 +0000 Message-ID: <791B411E-88FE-4E02-B486-632EEE758208@nominum.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D55C1@xmb-aln-x06.cisco.com> <434BDF4B-D6E7-4008-99F7-68B604E3587D@nominum.com> In-Reply-To: <434BDF4B-D6E7-4008-99F7-68B604E3587D@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: multipart/alternative; boundary="_000_791B411E88FE4E02B486632EEE758208nominumcom_" MIME-Version: 1.0 Cc: dhc WG , Andre Kostur Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 14:02:33 -0000 --_000_791B411E88FE4E02B486632EEE758208nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Aug 15, 2012, at 10:00 AM, Ted Lemon wrote: What would the source address be? Actually, this was a dumb question. The other answer is that the client h= as no way of knowing whether the network to which it is attaching supports = this protocol, so it has to send a solicit with an IA_NA in case that's wha= t the network administration supports. --_000_791B411E88FE4E02B486632EEE758208nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2176824D3998D14F8A82CD42A4206FCD@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 15, 2012, at 10:00 AM, Ted Lemon wrote:
What would the source address be?

Actually, this was a dumb question.   The other answer is that th= e client has no way of knowing whether the network to which it is attaching= supports this protocol, so it has to send a solicit with an IA_NA in case = that's what the network administration supports.


--_000_791B411E88FE4E02B486632EEE758208nominumcom_-- From ghalwasi@cisco.com Wed Aug 15 07:18:29 2012 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 3B42C21F87E4 for ; Wed, 15 Aug 2012 07:18:29 -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 lSKK0NiS2gX3 for ; Wed, 15 Aug 2012 07:18:28 -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 4B04A21F87E3 for ; Wed, 15 Aug 2012 07:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=5356; q=dns/txt; s=iport; t=1345040308; x=1346249908; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eMWHonASFh+Bt9J59S+lcqwCKrLRoHjwrRGU2m9R2lw=; b=XmkSO3sZXsaXSlyrWGj1tcUZH/6tD5UHr5rpVq6hREsIkRkKibpzaReq aMsk9ctfHCQH30oXHelWTN38tr11PVxTbVMizYKpOFyTldkpXzJN20iUk ZYvgKZ/Ay/ttvj0BGmgVID0wpIMIf38kQxs65HTwZX5pn4X6IzfXAyyBq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAKvK1CtJXHB/2dsb2JhbABFgkq3TIEHgiABAQEEEgEaTBACAQgRBAEBCx0HMhQJCAIEDgUIGodrmVGgSYsIhXdgA6N7gWaCXw X-IronPort-AV: E=Sophos;i="4.77,773,1336348800"; d="scan'208,217";a="111819541" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 15 Aug 2012 14:18:27 +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 q7FEIR1f023498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 14:18:27 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 09:18:27 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggACPzwCAAI85gP//roIggABeJICAAACoAP//sCEw Date: Wed, 15 Aug 2012 14:18:26 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0D5856@xmb-aln-x06.cisco.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D55C1@xmb-aln-x06.cisco.com> <434BDF4B-D6E7-4008-99F7-68B604E3587D@nominum.com> <791B411E-88FE-4E02-B486-632EEE758208@nominum.com> In-Reply-To: <791B411E-88FE-4E02-B486-632EEE758208@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.80.34] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.006 x-tm-as-result: No--34.842800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB0D5856xmbalnx06ciscocom_" MIME-Version: 1.0 Cc: dhc WG , Andre Kostur Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 14:18:29 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB0D5856xmbalnx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ted, Thanks, I get your point. -Gaurav From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, August 15, 2012 7:33 PM To: Gaurav Halwasia (ghalwasi) Cc: dhc WG; Andre Kostur Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 On Aug 15, 2012, at 10:00 AM, Ted Lemon wrote: What would the source address be? Actually, this was a dumb question. The other answer is that the client h= as no way of knowing whether the network to which it is attaching supports = this protocol, so it has to send a solicit with an IA_NA in case that's wha= t the network administration supports. --_000_90903C21C73202418A48BFBE80AEE5EB0D5856xmbalnx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ted,

 <= /p>

Thanks, I get your point.=

 <= /p>

-Gaurav=

 <= /p>

From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
Sent: Wednesday, August 15, 2012 7:33 PM
To: Gaurav Halwasia (ghalwasi)
Cc: dhc WG; Andre Kostur
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02<= /span>

 

On Aug 15, 2012, at 10:00 AM, Ted Lemon wrote:<= /o:p>

What would the source address be?

 

Actually, this was a dumb question.   The other= answer is that the client has no way of knowing whether the network to whi= ch it is attaching supports this protocol, so it has to send a solicit with= an IA_NA in case that's what the network administration supports.

 

 

--_000_90903C21C73202418A48BFBE80AEE5EB0D5856xmbalnx06ciscocom_-- From ghalwasi@cisco.com Wed Aug 15 07:33:04 2012 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 4FAF621F86F3 for ; Wed, 15 Aug 2012 07:33: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=[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 yYa-RtikGeOD for ; Wed, 15 Aug 2012 07:33:01 -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 5304421F879F for ; Wed, 15 Aug 2012 07:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=28332; q=dns/txt; s=iport; t=1345041181; x=1346250781; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ly7PXO7k7NQo2Fw7xTUK+b6zgI6yFv1ZRV4kmvPFqRE=; b=Lt73KnDpAvayjShtDpfOX2D2SY1j6/5YfGeztDGPerIM2K54O6W2blVC xNKlEa0K2fneD3/jvKiDnYIH09KiWNZDvmt8jjCVnJgnFGC2qJAGcJsgd ygDFSriX8YvD0xy0f0/n4gOlQZqH4CDrG/Mq00Ny4jDsMd4GEReoWnQ31 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACGyK1CtJV2Z/2dsb2JhbABFgkq3TIEHgiABAQEDARIBGkwFCwIBCBEEAQELFgEGBzIUCQgCBAENBQgXA4dlBplYoEuLCIV3YAOje4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,773,1336348800"; d="scan'208,217";a="111851905" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 15 Aug 2012 14:33:00 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7FEX0kR004408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 14:33:00 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 09:32:59 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "Bernie Volz (volz)" , Ted Lemon , Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggACPzwCAAI85gP//tRyggAAK8AA= Date: Wed, 15 Aug 2012 14:32:58 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0D58A2@xmb-aln-x06.cisco.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@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.80.34] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.006 x-tm-as-result: No--41.855400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB0D58A2xmbalnx06ciscocom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 14:33:04 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB0D58A2xmbalnx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernie, > Another issue that should be addressed in the document is what a client s= hould send when it connects to a network. How does >it know that the server= supports IA_PA and that it should be used, instead of the traditional IA_N= A? Should a client request >both? Does it send some kind of probe (Solicit = with IA_PA [perhaps only in the ORO]) - and what does it do if it doesn't g= et any >response; try again for IA_NA. I see your point which you are making. Further, draft says following:- Up to now, there is no mechanism that allows host self-generated addresses to be used in the DHCPv6-managed network. So, what about continuing with IA_NA itself but perhaps including host gene= rated "Interface-identifier" (as a new sub-option) as a hint in IA_NA optio= n which server *might* want to use while assigning the IPv6 address. ? Thanks, Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Wednesday, August 15, 2012 7:31 PM To: Ted Lemon; Andre Kostur Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Ted: If that is the case, why is there an IAID in the option (see below)? Should= n't that be removed?? If we have an IAID, then the client MUST provide this= option. If there is no IAID, then it may be possible to just put the optio= n in the ORO. However, I'd personally prefer we stick with the IA_NA/IA_TA/= IA_PD conventions and require this to be supplied by the client. If the ser= ver doesn't understand the option, it won't send it back in the Advertise/R= eply. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IA_PA | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IA_PA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I'd also suggest the following be clarified (section 4, bullet 2): If there is not a proper prefix available, a status- code is returned to the host and the procedure is terminated. What status code and where is this status code returned. Let's hope it foll= ows the IA_PD conventions (especially if we keep the IAID in the IA_PA). Th= ere is no new status code requested, do apparently it is one of the existin= g codes (RFC 3315/3633)? This work also seems to be to replacing Router Solicitation/Router Advertis= ement messages to advertise the prefixes (for stateless autoconfiguration).= Do we really want this. And, might not this be something to discuss in a s= lightly wider IETF audience. Perhaps it has already been (I haven't followe= d this work that closely). Another issue that should be addressed in the document is what a client sho= uld send when it connects to a network. How does it know that the server su= pports IA_PA and that it should be used, instead of the traditional IA_NA? = Should a client request both? Does it send some kind of probe (Solicit with= IA_PA [perhaps only in the ORO]) - and what does it do if it doesn't get a= ny response; try again for IA_NA. Personally, I do NOT think this work is ready and needs more clarity. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of Ted L= emon Sent: Wednesday, August 15, 2012 9:15 AM To: Andre Kostur Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote: I think that if the device wants a PA, it should supply an IA_PA in its Solicit. The device needs to specify an IAID. An ORO is insufficient. The prefix is not necessarily specific to an individual client-it's not a p= refix delegation. So I don't think an IAID is necessary at all. --_000_90903C21C73202418A48BFBE80AEE5EB0D58A2xmbalnx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernie,=

 <= /p>

> Another issue that should be addressed in the document is wha= t a client should send when it connects to a network. How does >it know that the s= erver supports IA_PA and that it should be used, instead of the traditional= IA_NA? Should a client request >both? Does it send some kind of probe (= Solicit with IA_PA [perhaps only in the ORO]) – and what does it do if it doesn’t get any >response= ; try again for IA_NA.

 <= /p>

I see your point which yo= u are making. Further, draft says following:-

 

   Up to now, there is no mechanism that allows = host self-generated

   addresses to be used in the DHCPv6-managed ne= twork.

 <= /p>

So, what about continuing= with IA_NA itself but perhaps including host generated “Interface-id= entifier” (as a new sub-option) as a hint in IA_NA option which server *might* want to use while assigning the IPv6 address. ?<= /span>

 <= /p>

Thanks,=

Gaurav<= /p>

 <= /p>

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, August 15, 2012 7:31 PM
To: Ted Lemon; Andre Kostur
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02<= /span>

 

Ted:

 <= /p>

If that is the case, why = is there an IAID in the option (see below)? Shouldn’t that be removed= ?? If we have an IAID, then the client MUST provide this option. If there is no IAID, then it may be possible to just put the option in the= ORO. However, I’d personally prefer we stick with the IA_NA/IA_TA/IA= _PD conventions and require this to be supplied by the client. If the serve= r doesn’t understand the option, it won’t send it back in the Advertise/Reply.

 <= /p>

        0&n= bsp;            = ;      1       =             2 &= nbsp;           &nbs= p;     3

        0 1= 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;       OPTION_IA_PA   &nbs= p;      |       = ;  option-length         |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;            = ;           IAID (4 octet= s)            &= nbsp;          |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;            = ;            &n= bsp;   T1         &n= bsp;            = ;         |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;            = ;            &n= bsp;   T2         &n= bsp;            = ;         |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       . &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;           .

       . &n= bsp;            = ;            IA_PA-o= ptions           &nb= sp;            .

       . &n= bsp;            = ;             &= nbsp;           &nbs= p;            &= nbsp;          .

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

 <= /p>

 <= /p>

I’d also suggest th= e following be clarified (section 4, bullet 2):

 <= /p> 

       If th=
ere is not a proper prefix available, a status-
       code =
is returned to the host and the procedure is terminated.<=
/pre>

 <=
/p>

What status code and wher=
e is this status code returned. Let’s hope it follows the IA_PD conve=
ntions (especially if we keep the IAID in the IA_PA). There is
 no new status code requested, do apparently it is one of the existing code=
s (RFC 3315/3633)?




 <=
/p>



 <=
/p>

This work also seems to b=
e to replacing Router Solicitation/Router Advertisement messages to adverti=
se the prefixes (for stateless autoconfiguration). Do we
 really want this. And, might not this be something to discuss in a slightl=
y wider IETF audience. Perhaps it has already been (I haven’t followe=
d this work that closely).




 <=
/p>



 <=
/p>

Another issue that should=
 be addressed in the document is what a client should send when it connects=
 to a network. How does it know that the server supports
 IA_PA and that it should be used, instead of the traditional IA_NA? Should=
 a client request both? Does it send some kind of probe (Solicit with IA_PA=
 [perhaps only in the ORO]) – and what does it do if it doesn’t=
 get any response; try again for IA_NA.


 <=
/p>

Personally, I do NOT thin=
k this work is ready and needs more clarity.


 <=
/p>

- =
        
Bernie=



 <=
/p>





From:
dhcwg-bounces@ietf.org 
[mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon

Sent: Wednesday, August 15, 2012 9:15 AM

To: Andre Kostur

Cc: dhc WG

Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02<=
/span>






 






On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote:






I th=
ink that if the device wants a PA, it should supply an IA_PA in

its Solicit.  The device needs to spe=
cify an IAID.  An ORO is

insufficient.






 




The prefix is not necessarily specific to an individ=
ual client—it's not a prefix delegation.   So I don't think an I=
AID is necessary at all.






 
--_000_90903C21C73202418A48BFBE80AEE5EB0D58A2xmbalnx06ciscocom_-- From volz@cisco.com Wed Aug 15 07:47:59 2012 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 E77B521F8697 for ; Wed, 15 Aug 2012 07:47:58 -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 WCuQFzANt9+W for ; Wed, 15 Aug 2012 07:47:55 -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 C2F3421F871C for ; Wed, 15 Aug 2012 07:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=36862; q=dns/txt; s=iport; t=1345042074; x=1346251674; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8hBco030mya+1JvCgQMuIKJnA9JddlxlwsGbGM9Tpak=; b=dLrCuz0j3G6HPFpYCHT3qo0nsJHGM+79RKV0tmPX0slWbuvkQ0F0bYoO zA0HTIVAYDFRw4B2TyFwF+Oq5yiU+pSuQksdU+sIEe2XvHiJWVGFPkth2 vlHeNTg3uzcFWGah183fqGH8U16RNorr9YHD+YxVFsDUvP7TJS3h3Ulv+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAM+1K1CtJXHB/2dsb2JhbABFgkq3TYEHgiABAQEDARIBGkwFCwIBCBEEAQELFgEGBzIUCQgCBAENBQgXA4dlBplZoEyLCIV3YAOje4Fmgl+BViM X-IronPort-AV: E=Sophos;i="4.77,773,1336348800"; d="scan'208,217";a="111811265" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 15 Aug 2012 14:47:53 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7FElrQb011495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Aug 2012 14:47:53 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 09:47:52 -0500 From: "Bernie Volz (volz)" To: "Gaurav Halwasia (ghalwasi)" , Ted Lemon , Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggACPzwCAAI85gP//tRyggAAK8ACAAAMKsA== Date: Wed, 15 Aug 2012 14:47:52 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4EBF41@xmb-rcd-x04.cisco.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB0D58A2@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB0D58A2@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19114.006 x-tm-as-result: No--44.856500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E0F4EBF41xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 15 Aug 2012 14:47:59 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E0F4EBF41xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd really like to understand exactly what the problem/requirement here is? >From the document, I gather the issue is: Up to now, there is no mechanism that allows host self-generated addresses to be used in the DHCPv6-managed network. But why does the host care what its address is? And if it needs multiple ad= dresses, DHCPv6 already provides a mechanism for this (IA_NAs with unique I= AIDs). Later there is some mention of CGAs and there was a separate draft being wo= rked on for that, draft-ietf-dhc-cga-config-dhcpv6-02? So, if CGAs are the = goal, isn't that document perhaps the better one to one forward (perhaps wi= th changes if there are some additional items to be accommodated). And, there's also temporary addresses mentioned - but why aren't IA_TAs app= ropriate? Also, why is the RS/RA mechanism that a host could use NOT appropriate? The= re is no mention of this? And, RS/RA and prefix information communicate more information such as whet= her the prefix is on-link or not, which is NOT information that is provided= by this mechanism - what does the host assume? - Bernie From: Gaurav Halwasia (ghalwasi) Sent: Wednesday, August 15, 2012 10:33 AM To: Bernie Volz (volz); Ted Lemon; Andre Kostur Cc: dhc WG Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Bernie, > Another issue that should be addressed in the document is what a client s= hould send when it connects to a network. How does >it know that the server= supports IA_PA and that it should be used, instead of the traditional IA_N= A? Should a client request >both? Does it send some kind of probe (Solicit = with IA_PA [perhaps only in the ORO]) - and what does it do if it doesn't g= et any >response; try again for IA_NA. I see your point which you are making. Further, draft says following:- Up to now, there is no mechanism that allows host self-generated addresses to be used in the DHCPv6-managed network. So, what about continuing with IA_NA itself but perhaps including host gene= rated "Interface-identifier" (as a new sub-option) as a hint in IA_NA optio= n which server *might* want to use while assigning the IPv6 address. ? Thanks, Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of Berni= e Volz (volz) Sent: Wednesday, August 15, 2012 7:31 PM To: Ted Lemon; Andre Kostur Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Ted: If that is the case, why is there an IAID in the option (see below)? Should= n't that be removed?? If we have an IAID, then the client MUST provide this= option. If there is no IAID, then it may be possible to just put the optio= n in the ORO. However, I'd personally prefer we stick with the IA_NA/IA_TA/= IA_PD conventions and require this to be supplied by the client. If the ser= ver doesn't understand the option, it won't send it back in the Advertise/R= eply. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IA_PA | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IA_PA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I'd also suggest the following be clarified (section 4, bullet 2): If there is not a proper prefix available, a status- code is returned to the host and the procedure is terminated. What status code and where is this status code returned. Let's hope it foll= ows the IA_PD conventions (especially if we keep the IAID in the IA_PA). Th= ere is no new status code requested, do apparently it is one of the existin= g codes (RFC 3315/3633)? This work also seems to be to replacing Router Solicitation/Router Advertis= ement messages to advertise the prefixes (for stateless autoconfiguration).= Do we really want this. And, might not this be something to discuss in a s= lightly wider IETF audience. Perhaps it has already been (I haven't followe= d this work that closely). Another issue that should be addressed in the document is what a client sho= uld send when it connects to a network. How does it know that the server su= pports IA_PA and that it should be used, instead of the traditional IA_NA? = Should a client request both? Does it send some kind of probe (Solicit with= IA_PA [perhaps only in the ORO]) - and what does it do if it doesn't get a= ny response; try again for IA_NA. Personally, I do NOT think this work is ready and needs more clarity. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of Ted L= emon Sent: Wednesday, August 15, 2012 9:15 AM To: Andre Kostur Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote: I think that if the device wants a PA, it should supply an IA_PA in its Solicit. The device needs to specify an IAID. An ORO is insufficient. The prefix is not necessarily specific to an individual client-it's not a p= refix delegation. So I don't think an IAID is necessary at all. --_000_489D13FBFA9B3E41812EA89F188F018E0F4EBF41xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d really like to = understand exactly what the problem/requirement here is?

 <= /p>

From the document, I gath= er the issue is:

 <= /p>

   Up to now, there is no mechanism = that allows host self-generated

   addresses to be used in the DHCPv= 6-managed network.

 <= /p>

But why does the host car= e what its address is? And if it needs multiple addresses, DHCPv6 already p= rovides a mechanism for this (IA_NAs with unique IAIDs).<= /p>

 <= /p>

Later there is some menti= on of CGAs and there was a separate draft being worked on for that, draft-i= etf-dhc-cga-config-dhcpv6-02? So, if CGAs are the goal, isn’t that document perhaps the better one to one forward (perhaps w= ith changes if there are some additional items to be accommodated).

 <= /p>

And, there’s also t= emporary addresses mentioned – but why aren’t IA_TAs appropriat= e?

 <= /p>

Also, why is the RS/RA me= chanism that a host could use NOT appropriate? There is no mention of this?=

 <= /p>

And, RS/RA and prefix inf= ormation communicate more information such as whether the prefix is on-link= or not, which is NOT information that is provided by this mechanism – what does the host assume?

 <= /p>

- =          Bernie=

 <= /p>

From: Gaurav H= alwasia (ghalwasi)
Sent: Wednesday, August 15, 2012 10:33 AM
To: Bernie Volz (volz); Ted Lemon; Andre Kostur
Cc: dhc WG
Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02<= /span>

 

Bernie,=

 <= /p>

> Another issue that s= hould be addressed in the document is what a client should send when it con= nects to a network. How does >it know that the server supports IA_PA and that it should be used, instead of the traditional IA_NA? Should= a client request >both? Does it send some kind of probe (Solicit with I= A_PA [perhaps only in the ORO]) – and what does it do if it doesnR= 17;t get any >response; try again for IA_NA.

 <= /p>

I see your point which yo= u are making. Further, draft says following:-

 

   Up to now, there is no mechanism that allows = host self-generated

   addresses to be used in the DHCPv6-managed ne= twork.

 <= /p>

So, what about continuing= with IA_NA itself but perhaps including host generated “Interface-id= entifier” (as a new sub-option) as a hint in IA_NA option which server *might* want to use while assigning the IPv6 address. ?<= /span>

 <= /p>

Thanks,=

Gaurav<= /p>

 <= /p>

 <= /p>

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)<= br> Sent: Wednesday, August 15, 2012 7:31 PM
To: Ted Lemon; Andre Kostur
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02<= /span>

 

Ted:

 <= /p>

If that is the case, why = is there an IAID in the option (see below)? Shouldn’t that be removed= ?? If we have an IAID, then the client MUST provide this option. If there is no IAID, then it may be possible to just put the option in the= ORO. However, I’d personally prefer we stick with the IA_NA/IA_TA/IA= _PD conventions and require this to be supplied by the client. If the serve= r doesn’t understand the option, it won’t send it back in the Advertise/Reply.

 <= /p>

        0&n= bsp;            = ;      1       =             2 &= nbsp;           &nbs= p;     3

        0 1= 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;       OPTION_IA_PA   &nbs= p;      |       = ;  option-length         |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;            = ;           IAID (4 octet= s)            &= nbsp;          |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;            = ;            &n= bsp;   T1         &n= bsp;            = ;         |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       | &n= bsp;            = ;            &n= bsp;   T2         &n= bsp;            = ;         |

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

       . &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;           .

       . &n= bsp;            = ;            IA_PA-o= ptions           &nb= sp;            .

       . &n= bsp;            = ;             &= nbsp;           &nbs= p;            &= nbsp;          .

       +-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+

 <= /p>

 <= /p>

I’d also suggest th= e following be clarified (section 4, bullet 2):

 <= /p> 

       If th=
ere is not a proper prefix available, a status-
       code =
is returned to the host and the procedure is terminated.<=
/pre>

 <=
/p>

What status code and wher=
e is this status code returned. Let’s hope it follows the IA_PD conve=
ntions (especially if we keep the IAID in the IA_PA). There is
 no new status code requested, do apparently it is one of the existing code=
s (RFC 3315/3633)?




 <=
/p>



 <=
/p>

This work also seems to b=
e to replacing Router Solicitation/Router Advertisement messages to adverti=
se the prefixes (for stateless autoconfiguration). Do we
 really want this. And, might not this be something to discuss in a slightl=
y wider IETF audience. Perhaps it has already been (I haven’t followe=
d this work that closely).




 <=
/p>



 <=
/p>

Another issue that should=
 be addressed in the document is what a client should send when it connects=
 to a network. How does it know that the server supports
 IA_PA and that it should be used, instead of the traditional IA_NA? Should=
 a client request both? Does it send some kind of probe (Solicit with IA_PA=
 [perhaps only in the ORO]) – and what does it do if it doesn’t=
 get any response; try again for IA_NA.


 <=
/p>

Personally, I do NOT thin=
k this work is ready and needs more clarity.


 <=
/p>

- =
        
Bernie=



 <=
/p>





From:
dhcwg-bounces@ietf.org 
[mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon

Sent: Wednesday, August 15, 2012 9:15 AM

To: Andre Kostur

Cc: dhc WG

Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02<=
/span>






 






On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote:






I th=
ink that if the device wants a PA, it should supply an IA_PA in

its Solicit.  The device needs to spe=
cify an IAID.  An ORO is

insufficient.






 




The prefix is not necessarily specific to an individ=
ual client—it's not a prefix delegation.   So I don't think an I=
AID is necessary at all.






 
--_000_489D13FBFA9B3E41812EA89F188F018E0F4EBF41xmbrcdx04ciscoc_-- From jiangsheng@huawei.com Wed Aug 15 17:19:45 2012 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 3C68C11E808A for ; Wed, 15 Aug 2012 17:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqRI4Z+j+9dJ for ; Wed, 15 Aug 2012 17:19:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 949B421F85F0 for ; Wed, 15 Aug 2012 17:19:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIX31260; Wed, 15 Aug 2012 16:19:44 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 17:18:33 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 17:18:38 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Thu, 16 Aug 2012 08:18:31 +0800 From: Sheng Jiang To: Ted Lemon Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggAE/oYCAAESVIA== Date: Thu, 16 Aug 2012 00:18:31 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F06653@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <1FCEAFB3-2942-4D31-B955-DCC167F69562@nominum.com> In-Reply-To: <1FCEAFB3-2942-4D31-B955-DCC167F69562@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.99.31] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9239F06653szxeml545mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 16 Aug 2012 00:19:45 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9239F06653szxeml545mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFRlZCwNCg0KVGhlIHNjZW5hcmlvIGlzIGp1c3QgbGlrZSBSQSBicm9hZGNhc3QgcHJlZml4 IGZvciBzdGF0ZWxlc3MgYWRkcmVzcyBjb25maWd1cmF0aW9uLiBUaGUgb25seSBkaWZmZXJlbnQg aXMgYnJvYWRjYXN0IHRob3VnaCBESENQdjYuDQoNClNoZW5nDQoNCkZyb206IFRlZCBMZW1vbiBb bWFpbHRvOlRlZC5MZW1vbkBub21pbnVtLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE1 LCAyMDEyIDk6MTIgUE0NClRvOiBTaGVuZyBKaWFuZw0KQ2M6IEdhdXJhdiBIYWx3YXNpYSAoZ2hh bHdhc2kpOyBkaGMgV0cNClN1YmplY3Q6IFJlOiBXR0xDOiBkcmFmdC1pZXRmLWRoYy1ob3N0LWdl bi1pZC0wMg0KDQpPbiBBdWcgMTQsIDIwMTIsIGF0IDExOjEyIFBNLCBTaGVuZyBKaWFuZyB3cm90 ZToNCldoZW4gdGhlIHByZWZpeCBhc3NpZ25tZW50IGluIGFkdmVydGlzZSBtb2RlbCwgZXZlbiBp ZiBhIGhvc3QgZG9lcyBub3QgcmVxdWVzdCwgREhDUHY2IHNlcnZlciBjYW4gcHVzaCBpdCBpbml0 aWF0aXZlbHkuDQoNCg0KSXQncyBoYXJkIHRvIGltYWdpbmUgYSBzaXR1YXRpb24gd2hlcmUgdGhp cyB3b3VsZCBiZSB1c2VmdWwuICAgSWYgdGhlIGNsaWVudCBkb2Vzbid0IGFscmVhZHkga25vdyBh Ym91dCBJQV9QQSwgaG93IGlzIGl0IGdvaW5nIHRvIGtub3cgd2hhdCB0byBkbyB3aGVuIGl0IGdl dHMgb25lPyAgIEl0IHNlZW1zIHRvIG1lIHRoYXQgaXQgd291bGQgbWFrZSBtb3JlIHNlbnNlIGVp dGhlciB0byByZXF1ZXN0IGFuIElBX1BBIGluIHRoZSBPUk8gKGluIHdoaWNoIGNhc2UgaXQgd291 bGQgY29tZSBpbiB0aGUgYWR2ZXJ0aXNlKSBvciBlbHNlIGp1c3QgaW5jbHVkZSBhbiBJQV9QQSBp biB0aGUgU29saWNpdC4NCg0K --_000_5D36713D8A4E7348A7E10DF7437A4B9239F06653szxeml545mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNh Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxl LW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOy13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTstd2Via2l0LWxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpLCBUZWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoZSBzY2VuYXJpbyBpcyBqdXN0IGxpa2UgUkEgYnJvYWRjYXN0IHByZWZpeCBmb3Igc3Rh dGVsZXNzIGFkZHJlc3MgY29uZmlndXJhdGlvbi4gVGhlIG9ubHkgZGlmZmVyZW50IGlzIGJyb2Fk Y2FzdCB0aG91Z2ggREhDUHY2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5T aGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWQgTGVtb24gW21haWx0bzpUZWQuTGVt b25Abm9taW51bS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMTUs IDIwMTIgOToxMiBQTTxicj4NCjxiPlRvOjwvYj4gU2hlbmcgSmlhbmc8YnI+DQo8Yj5DYzo8L2I+ IEdhdXJhdiBIYWx3YXNpYSAoZ2hhbHdhc2kpOyBkaGMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFdHTEM6IGRyYWZ0LWlldGYtZGhjLWhvc3QtZ2VuLWlkLTAyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBBdWcgMTQsIDIwMTIsIGF0IDExOjEy IFBNLCBTaGVuZyBKaWFuZyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2hlbiB0aGUgcHJlZml4IGFz c2lnbm1lbnQgaW4gYWR2ZXJ0aXNlIG1vZGVsLCBldmVuIGlmIGEgaG9zdCBkb2VzIG5vdCByZXF1 ZXN0LCBESENQdjYgc2VydmVyIGNhbiBwdXNoIGl0IGluaXRpYXRpdmVseS48L3NwYW4+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkl0J3MgaGFyZCB0byBpbWFnaW5lIGEgc2l0dWF0aW9uIHdoZXJl IHRoaXMgd291bGQgYmUgdXNlZnVsLiAmbmJzcDsgSWYgdGhlIGNsaWVudCBkb2Vzbid0IGFscmVh ZHkga25vdyBhYm91dCBJQV9QQSwgaG93IGlzIGl0IGdvaW5nIHRvIGtub3cgd2hhdCB0byBkbyB3 aGVuIGl0IGdldHMgb25lPyAmbmJzcDsgSXQgc2VlbXMgdG8gbWUgdGhhdCBpdCB3b3VsZCBtYWtl IG1vcmUgc2Vuc2UgZWl0aGVyDQogdG8gcmVxdWVzdCBhbiBJQV9QQSBpbiB0aGUgT1JPIChpbiB3 aGljaCBjYXNlIGl0IHdvdWxkIGNvbWUgaW4gdGhlIGFkdmVydGlzZSkgb3IgZWxzZSBqdXN0IGlu Y2x1ZGUgYW4gSUFfUEEgaW4gdGhlIFNvbGljaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B9239F06653szxeml545mbxchi_-- From Ted.Lemon@nominum.com Wed Aug 15 17:40:07 2012 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 0A9F621F84F7 for ; Wed, 15 Aug 2012 17:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsvtrK8wv0OD for ; Wed, 15 Aug 2012 17:40:06 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 597C521F84F5 for ; Wed, 15 Aug 2012 17:40:06 -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 DSNKUCxBZc9B4VLK9qfLSAmjPtQFxlsigDjl@postini.com; Wed, 15 Aug 2012 17:40: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 743E91B82F7 for ; Wed, 15 Aug 2012 17:40:05 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 68943190052; Wed, 15 Aug 2012 17:40:05 -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.02.0247.003; Wed, 15 Aug 2012 17:40:05 -0700 From: Ted Lemon To: Sheng Jiang Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggAE/oYCAAESVIIAAe8iA Date: Thu, 16 Aug 2012 00:40:04 +0000 Message-ID: <3447D11C-E8F9-470E-8307-017CA2DF7C99@nominum.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <1FCEAFB3-2942-4D31-B955-DCC167F69562@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B9239F06653@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F06653@szxeml545-mbx.china.huawei.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: multipart/alternative; boundary="_000_3447D11CE8F9470E8307017CA2DF7C99nominumcom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 16 Aug 2012 00:40:07 -0000 --_000_3447D11CE8F9470E8307017CA2DF7C99nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 15, 2012, at 8:18 PM, Sheng Jiang wrote: The scenario is just like RA broadcast prefix for stateless address configu= ration. The only different is broadcast though DHCPv6. So why not use RA in this case? --_000_3447D11CE8F9470E8307017CA2DF7C99nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 15, 2012, at 8:18 PM, Sheng Jiang wrote:
The scenario is just like RA broadcast p= refix for stateless address configuration. The only different is broadcast = though DHCPv6.

So why not use RA in this case?

--_000_3447D11CE8F9470E8307017CA2DF7C99nominumcom_-- From jiangsheng@huawei.com Wed Aug 15 17:45:58 2012 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 E8A3211E80CC for ; Wed, 15 Aug 2012 17:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OjphVIPQVdT for ; Wed, 15 Aug 2012 17:45:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 51E3111E8098 for ; Wed, 15 Aug 2012 17:45:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJL32680; Wed, 15 Aug 2012 16:45:57 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 17:44:51 -0700 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 17:44:49 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Thu, 16 Aug 2012 08:44:42 +0800 From: Sheng Jiang To: Ted Lemon Thread-Topic: WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggAE/oYCAAESVIIAAe8iA//+K1eA= Date: Thu, 16 Aug 2012 00:44:41 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F0668F@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <1FCEAFB3-2942-4D31-B955-DCC167F69562@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B9239F06653@szxeml545-mbx.china.huawei.com> <3447D11C-E8F9-470E-8307-017CA2DF7C99@nominum.com> In-Reply-To: <3447D11C-E8F9-470E-8307-017CA2DF7C99@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.99.31] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9239F0668Fszxeml545mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 16 Aug 2012 00:45:59 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9239F0668Fszxeml545mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGFzc3VtcHRpb24gd2UgdGFrZSBoZXJlIGlzOiB0aGlzIGlzIGEgZnVsbHkgREhDUHY2LW1h bmFnZWQgbmV0d29yaywgU0xBQ0MgdGhyb3VnaCBSQSBpcyBub3QgYWxsb3dlZC4NCg0KRnJvbTog VGVkIExlbW9uIFttYWlsdG86VGVkLkxlbW9uQG5vbWludW0uY29tXQ0KU2VudDogVGh1cnNkYXks IEF1Z3VzdCAxNiwgMjAxMiA4OjQwIEFNDQpUbzogU2hlbmcgSmlhbmcNCkNjOiBHYXVyYXYgSGFs d2FzaWEgKGdoYWx3YXNpKTsgZGhjIFdHDQpTdWJqZWN0OiBSZTogV0dMQzogZHJhZnQtaWV0Zi1k aGMtaG9zdC1nZW4taWQtMDINCg0KT24gQXVnIDE1LCAyMDEyLCBhdCA4OjE4IFBNLCBTaGVuZyBK aWFuZyB3cm90ZToNClRoZSBzY2VuYXJpbyBpcyBqdXN0IGxpa2UgUkEgYnJvYWRjYXN0IHByZWZp eCBmb3Igc3RhdGVsZXNzIGFkZHJlc3MgY29uZmlndXJhdGlvbi4gVGhlIG9ubHkgZGlmZmVyZW50 IGlzIGJyb2FkY2FzdCB0aG91Z2ggREhDUHY2Lg0KDQpTbyB3aHkgbm90IHVzZSBSQSBpbiB0aGlz IGNhc2U/DQoNCg== --_000_5D36713D8A4E7348A7E10DF7437A4B9239F0668Fszxeml545mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1u YW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGUgYXNzdW1wdGlvbiB3ZSB0YWtlIGhlcmUgaXM6IHRoaXMgaXMgYSBm dWxseSBESENQdjYtbWFuYWdlZCBuZXR3b3JrLCBTTEFDQyB0aHJvdWdoIFJBIGlzIG5vdCBhbGxv d2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWQgTGVtb24gW21haWx0bzpUZWQuTGVt b25Abm9taW51bS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxNiwg MjAxMiA4OjQwIEFNPGJyPg0KPGI+VG86PC9iPiBTaGVuZyBKaWFuZzxicj4NCjxiPkNjOjwvYj4g R2F1cmF2IEhhbHdhc2lhIChnaGFsd2FzaSk7IGRoYyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogV0dMQzogZHJhZnQtaWV0Zi1kaGMtaG9zdC1nZW4taWQtMDI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIEF1ZyAxNSwgMjAxMiwgYXQgODoxOCBQ TSwgU2hlbmcgSmlhbmcgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBzY2VuYXJpbyBpcyBqdXN0IGxpa2UgUkEgYnJv YWRjYXN0IHByZWZpeCBmb3Igc3RhdGVsZXNzIGFkZHJlc3MgY29uZmlndXJhdGlvbi4gVGhlIG9u bHkgZGlmZmVyZW50IGlzIGJyb2FkY2FzdCB0aG91Z2ggREhDUHY2Ljwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlNvIHdoeSBub3QgdXNlIFJBIGluIHRoaXMgY2FzZT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B9239F0668Fszxeml545mbxchi_-- From jiangsheng@huawei.com Wed Aug 15 17:51:21 2012 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 D522811E80D9 for ; Wed, 15 Aug 2012 17:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrFnsskh6p0s for ; Wed, 15 Aug 2012 17:51:21 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1F54511E80CC for ; Wed, 15 Aug 2012 17:51:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIX32706; Wed, 15 Aug 2012 16:51:20 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 17:49:59 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 17:50:03 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Thu, 16 Aug 2012 08:50:00 +0800 From: Sheng Jiang To: "Bernie Volz (volz)" , Ted Lemon , Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+Bcg//+14QCAAI85gIAADPCAgAE0l2A= Date: Thu, 16 Aug 2012 00:49:59 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F066A2@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@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.99.31] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9239F066A2szxeml545mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 16 Aug 2012 00:51:21 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9239F066A2szxeml545mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEJlcm5pZSwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBTZWUgbXkgcmVwbHkgaW4g bGluZXMuDQoNClNoZW5nDQoNCknigJlkIGFsc28gc3VnZ2VzdCB0aGUgZm9sbG93aW5nIGJlIGNs YXJpZmllZCAoc2VjdGlvbiA0LCBidWxsZXQgMik6DQoNCg0KICAgICAgIElmIHRoZXJlIGlzIG5v dCBhIHByb3BlciBwcmVmaXggYXZhaWxhYmxlLCBhIHN0YXR1cy0NCg0KICAgICAgIGNvZGUgaXMg cmV0dXJuZWQgdG8gdGhlIGhvc3QgYW5kIHRoZSBwcm9jZWR1cmUgaXMgdGVybWluYXRlZC4NCg0K V2hhdCBzdGF0dXMgY29kZSBhbmQgd2hlcmUgaXMgdGhpcyBzdGF0dXMgY29kZSByZXR1cm5lZC4g TGV04oCZcyBob3BlIGl0IGZvbGxvd3MgdGhlIElBX1BEIGNvbnZlbnRpb25zIChlc3BlY2lhbGx5 IGlmIHdlIGtlZXAgdGhlIElBSUQgaW4gdGhlIElBX1BBKS4gVGhlcmUgaXMgbm8gbmV3IHN0YXR1 cyBjb2RlIHJlcXVlc3RlZCwgZG8gYXBwYXJlbnRseSBpdCBpcyBvbmUgb2YgdGhlIGV4aXN0aW5n IGNvZGVzIChSRkMgMzMxNS8zNjMzKT8NCg0KPFNoZW5nPiBJdCBpcyB0aGUgZXhpc3RpbmcgTm9Q cmVmaXhBdmFpbCBzdGF0dXMgY29kZSwgZGVmaW5lZCBpbiBSRkMgMzYzMy4gSSBoYXZlIGp1c3Qg YWRkZWQgYW4gZXhwbGljaXQgZXhwbGFuYXRpb24gZm9yIHRoaXMuDQoNCg0KVGhpcyB3b3JrIGFs c28gc2VlbXMgdG8gYmUgdG8gcmVwbGFjaW5nIFJvdXRlciBTb2xpY2l0YXRpb24vUm91dGVyIEFk dmVydGlzZW1lbnQgbWVzc2FnZXMgdG8gYWR2ZXJ0aXNlIHRoZSBwcmVmaXhlcyAoZm9yIHN0YXRl bGVzcyBhdXRvY29uZmlndXJhdGlvbikuIERvIHdlIHJlYWxseSB3YW50IHRoaXMuIEFuZCwgbWln aHQgbm90IHRoaXMgYmUgc29tZXRoaW5nIHRvIGRpc2N1c3MgaW4gYSBzbGlnaHRseSB3aWRlciBJ RVRGIGF1ZGllbmNlLiBQZXJoYXBzIGl0IGhhcyBhbHJlYWR5IGJlZW4gKEkgaGF2ZW7igJl0IGZv bGxvd2VkIHRoaXMgd29yayB0aGF0IGNsb3NlbHkpLg0KDQo8U2hlbmc+IEl0IGlzIHRoZSBhc3N1 bXB0aW9uIHdlIHRha2UuIEkgYmVsaWV2ZSB3ZSBoYWQgdGhlIFdHIGNvbnNlbnN1cywgYnkgYWRv cHRpbmcgYXMgV0cgZG9jdW1lbnQuIEJlY2F1c2UgdGhpcyBvbmx5IGhhcHBlbnMgaW4gYSBmdWxs eSBESENQdjYtbWFuYWdlZCBuZXR3b3JrLCBkb2VzIG5vdCBpbXBhY3QgYW55IG90aGVyIG5ldHdv cmsgdGhhdCB1c2UgUkEgZm9yIFNMQUNDLCBzbyBJIHRoaW5rIGRpc2N1c3Npb24gaW4gREhDIGlz IGVub3VnaC4NCg0KUmVnYXJkcywNCg0KU2hlbmcNCg== --_000_5D36713D8A4E7348A7E10DF7437A4B9239F066A2szxeml545mbxchi_ 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 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5 bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpwLkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0ZWQs IGRpdi5IVE1MUHJlZm9ybWF0dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjYwNDU4MTA1Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjIzNDk1Mzg4IC0xMzkwMDkz NTQ2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSwgQmVybmllLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFu a3MgZm9yIHlvdXIgY29tbWVudHMuIFNlZSBteSByZXBseSBpbiBsaW5lcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2hlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJlkIGFsc28gc3VnZ2VzdCB0aGUg Zm9sbG93aW5nIGJlIGNsYXJpZmllZCAoc2VjdGlvbiA0LCBidWxsZXQgMik6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiB0aGVyZSBpcyBub3QgYSBwcm9wZXIgcHJl Zml4IGF2YWlsYWJsZSwgYSBzdGF0dXMtPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBjb2RlIGlzIHJldHVybmVkIHRvIHRoZSBob3N0IGFuZCB0aGUgcHJv Y2VkdXJlIGlzIHRlcm1pbmF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+V2hhdCBzdGF0dXMgY29kZSBhbmQgd2hlcmUgaXMgdGhpcyBzdGF0dXMgY29kZSByZXR1cm5l ZC4gTGV04oCZcyBob3BlIGl0IGZvbGxvd3MgdGhlIElBX1BEIGNvbnZlbnRpb25zIChlc3BlY2lh bGx5IGlmIHdlIGtlZXAgdGhlIElBSUQgaW4gdGhlIElBX1BBKS4NCiBUaGVyZSBpcyBubyBuZXcg c3RhdHVzIGNvZGUgcmVxdWVzdGVkLCBkbyBhcHBhcmVudGx5IGl0IGlzIG9uZSBvZiB0aGUgZXhp c3RpbmcgY29kZXMgKFJGQyAzMzE1LzM2MzMpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbHQ7U2hlbmcmZ3Q7IEl0IGlzIHRoZSBleGlzdGluZyBOb1ByZWZpeEF2YWlsIHN0 YXR1cyBjb2RlLCBkZWZpbmVkIGluIFJGQyAzNjMzLiBJIGhhdmUganVzdCBhZGRlZCBhbiBleHBs aWNpdCBleHBsYW5hdGlvbiBmb3IgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDEuMHB0IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgd29yayBhbHNvIHNl ZW1zIHRvIGJlIHRvIHJlcGxhY2luZyBSb3V0ZXIgU29saWNpdGF0aW9uL1JvdXRlciBBZHZlcnRp c2VtZW50IG1lc3NhZ2VzIHRvIGFkdmVydGlzZSB0aGUgcHJlZml4ZXMgKGZvciBzdGF0ZWxlc3Mg YXV0b2NvbmZpZ3VyYXRpb24pLg0KIERvIHdlIHJlYWxseSB3YW50IHRoaXMuIEFuZCwgbWlnaHQg bm90IHRoaXMgYmUgc29tZXRoaW5nIHRvIGRpc2N1c3MgaW4gYSBzbGlnaHRseSB3aWRlciBJRVRG IGF1ZGllbmNlLiBQZXJoYXBzIGl0IGhhcyBhbHJlYWR5IGJlZW4gKEkgaGF2ZW7igJl0IGZvbGxv d2VkIHRoaXMgd29yayB0aGF0IGNsb3NlbHkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbHQ7U2hlbmcmZ3Q7IEl0IGlzIHRoZSBhc3N1bXB0aW9uIHdlIHRha2UuIEkgYmVs aWV2ZSB3ZSBoYWQgdGhlIFdHIGNvbnNlbnN1cywgYnkgYWRvcHRpbmcgYXMgV0cgZG9jdW1lbnQu IEJlY2F1c2UgdGhpcyBvbmx5IGhhcHBlbnMgaW4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmEgZnVsbHkgREhDUHY2LW1hbmFn ZWQgbmV0d29yaywgZG9lcyBub3QgaW1wYWN0IGFueSBvdGhlciBuZXR3b3JrIHRoYXQgdXNlIFJB IGZvciBTTEFDQywgc28gSSB0aGluayBkaXNjdXNzaW9uIGluIERIQyBpcyBlbm91Z2guPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlNoZW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B9239F066A2szxeml545mbxchi_-- From akostur@incognito.com Wed Aug 15 18:07:55 2012 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 998DE21F8534 for ; Wed, 15 Aug 2012 18:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQk1JmVQGPRQ for ; Wed, 15 Aug 2012 18:07:55 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with SMTP id EB7A711E809B for ; Wed, 15 Aug 2012 18:07:54 -0700 (PDT) Received: from mail-yw0-f41.google.com ([209.85.213.41]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKUCxH6nCuW1buEA1WwyMdhuw5XEaQ8ViF@postini.com; Wed, 15 Aug 2012 18:07:55 PDT Received: by yhr47 with SMTP id 47so2700222yhr.0 for ; Wed, 15 Aug 2012 18:07:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=pQtnkXapP97+HvLOClLHa/K+J1o3tHJ5L2nqeciRmBA=; b=PqGEQcjRTixksvGS//H5nEtQBIMpBiPBtJxuiSlLa23zo6UmB+0oKtZnjZ4NXUtPxK z8YH52NfxkpyBrBtLgqKXm/GSsc7FpK88G3zaqOtH3vLFnk8wxlB/bjJhskAoeaU56Wi WdKoBlUt5lJwESF9ilUmWK1ImgdUnWpw0k8WldGkasM4zVh47y2h5ORRANHOAlXurTlx xz/tKLnwxzNhJfDCS2az3kA7hRudrm0cqBXxCeAl0NcXAKixjr16k2+NT5IBsKxH7p2y 7ODGetVaSthW4q5Jb6I+tSKtHtCI4fHAE2BS0f/hqq3YsG/YuM2vcR7IHzFot1JzWxyy aAmg== MIME-Version: 1.0 Received: by 10.50.207.73 with SMTP id lu9mr429226igc.19.1345079273644; Wed, 15 Aug 2012 18:07:53 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Wed, 15 Aug 2012 18:07:53 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F066A2@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F066A2@szxeml545-mbx.china.huawei.com> Date: Wed, 15 Aug 2012 18:07:53 -0700 Message-ID: From: Andre Kostur To: Sheng Jiang Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlEUN2X3fSBjSCrq+cyOSvC1FL0oTiDe074HfjuX+PPKy/P9pIYlPOl0ywJ84jMcNEzV/hK Cc: dhc WG , "Bernie Volz \(volz\)" , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 16 Aug 2012 01:07:55 -0000 Leaving aside the issue of whether this "prefix announcement" should be carried over DHCPv6, I wonder if trying to fit this into an Identity Association isn't quite right since there is no identity to be managed? Perhaps a cleaner solution would be for the device to ask for an IAPREFIX in an ORO in an Information-Request, and the server can reply with an IAPREFIX (that isn't in any IA_* option). Having said that, I'm with Ted in that I don't quite grasp why we're trying to do this. It the network is "fully DHCPv6-managed", wouldn't that mean that the administrators would want to control the address generation instead of leaving it up to the client to do with it as it will? On Wed, Aug 15, 2012 at 5:49 PM, Sheng Jiang wrote: > > Hi, Bernie, > > > > Thanks for your comments. See my reply in lines. > > > > Sheng > > > > I=92d also suggest the following be clarified (section 4, bullet 2): > > > > If there is not a proper prefix available, a status- > > code is returned to the host and the procedure is terminated. > > > > What status code and where is this status code returned. Let=92s hope it > follows the IA_PD conventions (especially if we keep the IAID in the IA_P= A). > There is no new status code requested, do apparently it is one of the > existing codes (RFC 3315/3633)? > > > > It is the existing NoPrefixAvail status code, defined in RFC 3633= . > I have just added an explicit explanation for this. > > > > > > This work also seems to be to replacing Router Solicitation/Router > Advertisement messages to advertise the prefixes (for stateless > autoconfiguration). Do we really want this. And, might not this be someth= ing > to discuss in a slightly wider IETF audience. Perhaps it has already been= (I > haven=92t followed this work that closely). > > > > It is the assumption we take. I believe we had the WG consensus, > by adopting as WG document. Because this only happens in a fully > DHCPv6-managed network, does not impact any other network that use RA for > SLACC, so I think discussion in DHC is enough. -- Andre Kostur From volz@cisco.com Wed Aug 15 19:58:42 2012 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 04E9811E80E4 for ; Wed, 15 Aug 2012 19:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FJoMHlXl3cP for ; Wed, 15 Aug 2012 19:58:41 -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 E690221F84FD for ; Wed, 15 Aug 2012 19:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=5287; q=dns/txt; s=iport; t=1345085921; x=1346295521; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/MhgUNQuEqMIv1aTOQmJLU2+H8IjeI9GpjtxshN/eb4=; b=YLGrkFAL3ZotfXSGLSXNS2QZxj2uep23W7PIk2AW7Dox+bOG1TN+Uioj 2CMTOv/5QuWeOqnbeT2Cc5YI5SxArYmI185trhX7J4mwWg3QvyWcawn9T BeL7NKjv5IyMaNYl7dqA5/CoGe2hciE9b6GI0uYTfC+QVUJVEQRMe5CCS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD1hLFCtJV2b/2dsb2JhbAA8CbojgQeCIAEBAQMBAQEBDwFUBwsFCwIBCA4KHREnCyUCBAENBRsHh2UGC5oLoDoEiwgRBIViYAOVT44sgWaCX4FX X-IronPort-AV: E=Sophos;i="4.77,776,1336348800"; d="scan'208";a="111837243" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 16 Aug 2012 02:58:40 +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 q7G2wdR9028641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 02:58:40 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Wed, 15 Aug 2012 21:58:39 -0500 From: "Bernie Volz (volz)" To: Andre Kostur , "jiangsheng@huawei.com" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+BcggACPzwCAAI85gP//tRyggAENGoCAAAUAgP//yyEg Date: Thu, 16 Aug 2012 02:58:39 +0000 Message-ID: <0E81DDB0-29DA-4B8F-A336-FDE9FDA663D2@cisco.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F066A2@szxeml545-mbx.china.huawei.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--45.264500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 16 Aug 2012 02:58:42 -0000 What about the other things RAs provide? Such as the routers and on-link no= tification ... Are RAs active in these networks or not? Also how is the client's assignment of addresses considered DHCPv6-managed? How is this any different from stateless? The only difference with this over normal stateless is that you could give = each client its own prefix, whereas RAs are sent to all devices on the link= . But I don't recall the document mentioning such a network (and in some ca= ses where this might occur, usually there are tunnels involved and protocol= s such as ppp). And you would have to describe such a network and explain w= hy RSs and RAs are insufficent or not usuable/pratical. When the working group adopts a document to work on, that does not mean it = will necessarily advance. Sometimes not all of the issues are well understo= od early in the process. There are other cases where it can take many years= to work out the details and address the concerns before the document is re= ady. The process can be frustrating and demotivating. But the result is usu= ally for the best. Also, as CGAs are mentioned as one possible usage model, I think it would a= gain be important to understand why the other works in this area (draft-iet= f-dhc-cga-config-dhcpv6 and draft-ietf-dhc-secure-dhcpv6) are not appropria= te or do not cover all of the requirements - and it might be worth consider= ing working with those authors? Note also that in normal DHCPv6, clients ma= y request explicit addresses and so using CGA addresses via DHCPv6 isn't im= possible (some servers do require a range of addresses to be configured jus= t like for v4, but I consider that approach to limit what v6 has to offer -= - the server I work on does not have this restriction). I can agree with you that the world isn't as simple as we would like - ther= e are plenty of devices that only support stateless and this makes running = a "fully" DHCPv6 managed network where you don't have total control of the = devices that may connect impossible. But building more complexity and choic= es into DHCPv6 hardly seems like the a good approach to solving this since = it will be even longer before all of the devices support these new configur= ation models - or some may chose not to implement DHCPv6 at all. Anyway, if I haven't said it before or it isn't yet clear, I have serious o= bjections to advancing this work in its current form and given its current = motivation. If the rational for needing these capabilities and how they are= used between clients, relays, and servers and the network are explained, I= will be happy to remove my objections. - Bernie On Aug 15, 2012, at 9:08 PM, "Andre Kostur" wrote: > Leaving aside the issue of whether this "prefix announcement" should > be carried over DHCPv6, I wonder if trying to fit this into an > Identity Association isn't quite right since there is no identity to > be managed? Perhaps a cleaner solution would be for the device to > ask for an IAPREFIX in an ORO in an Information-Request, and the > server can reply with an IAPREFIX (that isn't in any IA_* option). >=20 > Having said that, I'm with Ted in that I don't quite grasp why we're > trying to do this. It the network is "fully DHCPv6-managed", wouldn't > that mean that the administrators would want to control the address > generation instead of leaving it up to the client to do with it as it > will? >=20 > On Wed, Aug 15, 2012 at 5:49 PM, Sheng Jiang wrot= e: >>=20 >> Hi, Bernie, >>=20 >>=20 >>=20 >> Thanks for your comments. See my reply in lines. >>=20 >>=20 >>=20 >> Sheng >>=20 >>=20 >>=20 >> I=92d also suggest the following be clarified (section 4, bullet 2): >>=20 >>=20 >>=20 >> If there is not a proper prefix available, a status- >>=20 >> code is returned to the host and the procedure is terminated. >>=20 >>=20 >>=20 >> What status code and where is this status code returned. Let=92s hope it >> follows the IA_PD conventions (especially if we keep the IAID in the IA_= PA). >> There is no new status code requested, do apparently it is one of the >> existing codes (RFC 3315/3633)? >>=20 >>=20 >>=20 >> It is the existing NoPrefixAvail status code, defined in RFC 363= 3. >> I have just added an explicit explanation for this. >>=20 >>=20 >>=20 >>=20 >>=20 >> This work also seems to be to replacing Router Solicitation/Router >> Advertisement messages to advertise the prefixes (for stateless >> autoconfiguration). Do we really want this. And, might not this be somet= hing >> to discuss in a slightly wider IETF audience. Perhaps it has already bee= n (I >> haven=92t followed this work that closely). >>=20 >>=20 >>=20 >> It is the assumption we take. I believe we had the WG consensus, >> by adopting as WG document. Because this only happens in a fully >> DHCPv6-managed network, does not impact any other network that use RA fo= r >> SLACC, so I think discussion in DHC is enough. >=20 > -- > Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Wed Aug 15 20:52:12 2012 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 EEDE611E80E8 for ; Wed, 15 Aug 2012 20:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vJKfZBCL7By for ; Wed, 15 Aug 2012 20:52:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 04ABC11E80E4 for ; Wed, 15 Aug 2012 20:52:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJL41635; Wed, 15 Aug 2012 19:52:11 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 20:48:07 -0700 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 20:48:05 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Thu, 16 Aug 2012 11:48:01 +0800 From: Sheng Jiang To: "Bernie Volz (volz)" , Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+Bcg//+14QCAAI85gIAADPCAgAE0l2D//4WvgIAAHvOAgACIrLA= Date: Thu, 16 Aug 2012 03:48:00 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F067D3@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F066A2@szxeml545-mbx.china.huawei.com>, <0E81DDB0-29DA-4B8F-A336-FDE9FDA663D2@cisco.com> In-Reply-To: <0E81DDB0-29DA-4B8F-A336-FDE9FDA663D2@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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 16 Aug 2012 03:52:13 -0000 SGksIEJlcm5pZSBhbmQgQW5kcmUNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBBY3R1YWxs eSwgd2UgYXJlIHF1aXRlIG9wZW4gdG8gZGlzY3Vzcy4gVGhlIG9ubHkgcmVhc29uIHdlIHJlcXVl c3QgV0dMQyBpcyB0aGVyZSBpcyBubyBhbnkgZGlzY3Vzc2lvbiBmb3IgdGhpcyBkcmFmdCBmb3Ig bGFzdCAxMiBtb250aHMgYW5kIHdlIGhhdmUgYWRkcmVzc2VkIGFsbCBjb21tZW50cyB3ZSByZWNl aXZlZC4NCg0KU2luY2UgeW91IGhhdmUgcmFpc2VkIG5ldyBkaXNjdXNzaW9uLCB3ZSBhcmUgaGFw cHkgdG8gZGVsYXkgdGhlIHByb2Nlc3MgdGlsbCBhbGwgb3BlbiBpc3N1ZXMgZ2V0IGFkZHJlc3Nl ZC4gVGhpcyBpcyBnb29kIGZvciBvdXIgd29yayB0byBiZSByZWFsIG1hdHVyZS4gOikNCg0KU2Vl IG15IHJlcGx5IGluIGxpbmVzLg0KDQpTaGVuZw0KDQo+V2hhdCBhYm91dCB0aGUgb3RoZXIgdGhp bmdzIFJBcyBwcm92aWRlPyBTdWNoIGFzIHRoZSByb3V0ZXJzIGFuZCBvbi1saW5rDQo+bm90aWZp Y2F0aW9uIC4uLiBBcmUgUkFzIGFjdGl2ZSBpbiB0aGVzZSBuZXR3b3JrcyBvciBub3Q/DQoNClRo aXMgd29yayBkb2VzIE5PVCByZXBsYWNlIG5laWdoYm9yIGRpc2NvdmVyeS4gUkEgaXMgYWN0aXZl IGluIG91ciB0YXJnZXQgbmV0d29yay4gTkQgaXMgbWFpbmx5IGZvciByZWFjaGFiaWxpdHkvcm91 dGluZyBwdXJwb3NlLg0KDQpUaGlzIHdvcmsgaXMgdG8gbWFrZSB0aGUgYWRkcmVzcyBjb25maWd1 cmF0aW9uIGFsbCBieSBESENQdjYsIHJhdGhlciB0aGFuIHBhcnQgYnkgUkEsIHBhcnQgYnkgREhD UHY2LiBXaXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgREhDUHY2IHRha2VzIG92ZXIgYWxsIGFkZHJl c3MgY29uZmlndXJhdGlvbiwgYXNzaWduaW5nIDEyOC1iaXQgYWRkcmVzcyBpcyBpbnN1ZmZpY2ll bnQuIFNvbWUgaG9zdCB3YW50IHRvIHVzZSBzZWxmLWdlbmVyYXRlZCBhZGRyZXNzLCBDR0EgaXMg b25seSBvbmUgZXhhbXBsZSwgb3RoZXJzIGluY2x1ZGluZyBFVUk2NCBhbmQgcHJpdmFjeSBhZGRy ZXNzLg0KDQpUaGlzIHdvcmsgaXMgYSBnZW5lcmljIHByZWZpeCBhc3NpZ25tZW50L2Fubm91bmNl bWVudCBtZWNoYW5pc20uIEl0IGlzIGFsdGVybmF0aXZlIG9mIFJBIHByZWZpeCBhc3NpZ25tZW50 L2Fubm91bmNlbWVudC4NCg0KDQpkcmFmdC1pZXRmLWRoYy1zZWN1cmUtZGhjcHY2IGlzIG5vdGhp bmcgdG8gZG8gd2l0aCBhZGRyZXNzIGNvbmZpZ3VyYXRpb24uIEl0IGlzIEFGVEVSIENHQSBhZGRy ZXNzZXMgZ2VuZXJhdGVkLCB1c2luZyB0aGVtIHRvIHByb3RlY3QgREhDUHY2IG1lc3NhZ2UgZXhj aGFuZ2luZy4NCg0KZHJhZnQtaWV0Zi1kaGMtY2dhLWNvbmZpZy1kaGNwdjYgaXMgc3BlY2lmaWMg Q0dBIGNvbmZpZ3VyYXRpb24uIFNpbmNlIHdlIHNlcGFyYXRlZCBwcmVmaXggYXNzaWdubWVudCB0 byBiZSB0aGlzIGdlbmVyaWMgbWVjaGFuaXNtLCB0aGF0IGRyYWZ0IGlzIG9ubHkgZm9jdXNpbmcg b24gQ0dBIGFwcHJvdmUgcHJvY2Vzcy4gSG93ZXZlciwgaWYgdGhlIGRpc2N1c3Npb24gdGhpbmsg cHJlZml4IGFzc2lnbm1lbnQgaXMgb25seSBtZWFuaW5nZnVsIGZvciBDR0EsIHdlIGhhdmUgbm8g cHJvYmxlbSB0byBjb21iaW5lIHRoaXMgYmFjayB0byBDR0EgY29uZmlndXJhdGlvbiBkcmFmdC4N Cg0KTGV0J3MgZmlyc3QgZGlzY3VzcyB0aGUgcmVxdWlyZW1lbnQvcHJvYmxlbSBmaXJzdC4gV2Ug Y2FuIGNvbWUgYmFjayB0byB0ZWNobmljYWwgZGV0YWlscyBsYXRlci4NCg0KUmVnYXJkcywNCg0K U2hlbmcNCg0KPkFsc28gaG93IGlzIHRoZSBjbGllbnQncyBhc3NpZ25tZW50IG9mIGFkZHJlc3Nl cyBjb25zaWRlcmVkDQo+REhDUHY2LW1hbmFnZWQ/DQo+DQo+SG93IGlzIHRoaXMgYW55IGRpZmZl cmVudCBmcm9tIHN0YXRlbGVzcz8NCj4NCj5UaGUgb25seSBkaWZmZXJlbmNlIHdpdGggdGhpcyBv dmVyIG5vcm1hbCBzdGF0ZWxlc3MgaXMgdGhhdCB5b3UgY291bGQgZ2l2ZSBlYWNoDQo+Y2xpZW50 IGl0cyBvd24gcHJlZml4LCB3aGVyZWFzIFJBcyBhcmUgc2VudCB0byBhbGwgZGV2aWNlcyBvbiB0 aGUgbGluay4gQnV0IEkNCj5kb24ndCByZWNhbGwgdGhlIGRvY3VtZW50IG1lbnRpb25pbmcgc3Vj aCBhIG5ldHdvcmsgKGFuZCBpbiBzb21lIGNhc2VzDQo+d2hlcmUgdGhpcyBtaWdodCBvY2N1ciwg dXN1YWxseSB0aGVyZSBhcmUgdHVubmVscyBpbnZvbHZlZCBhbmQgcHJvdG9jb2xzIHN1Y2gNCj5h cyBwcHApLiBBbmQgeW91IHdvdWxkIGhhdmUgdG8gZGVzY3JpYmUgc3VjaCBhIG5ldHdvcmsgYW5k IGV4cGxhaW4gd2h5IFJTcw0KPmFuZCBSQXMgYXJlIGluc3VmZmljZW50IG9yIG5vdCB1c3VhYmxl L3ByYXRpY2FsLg0KPg0KPldoZW4gdGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRzIGEgZG9jdW1lbnQg dG8gd29yayBvbiwgdGhhdCBkb2VzIG5vdCBtZWFuDQo+aXQgd2lsbCBuZWNlc3NhcmlseSBhZHZh bmNlLiBTb21ldGltZXMgbm90IGFsbCBvZiB0aGUgaXNzdWVzIGFyZSB3ZWxsDQo+dW5kZXJzdG9v ZCBlYXJseSBpbiB0aGUgcHJvY2Vzcy4gVGhlcmUgYXJlIG90aGVyIGNhc2VzIHdoZXJlIGl0IGNh biB0YWtlIG1hbnkNCj55ZWFycyB0byB3b3JrIG91dCB0aGUgZGV0YWlscyBhbmQgYWRkcmVzcyB0 aGUgY29uY2VybnMgYmVmb3JlIHRoZSBkb2N1bWVudA0KPmlzIHJlYWR5LiBUaGUgcHJvY2VzcyBj YW4gYmUgZnJ1c3RyYXRpbmcgYW5kIGRlbW90aXZhdGluZy4gQnV0IHRoZSByZXN1bHQgaXMNCj51 c3VhbGx5IGZvciB0aGUgYmVzdC4NCj4NCj5BbHNvLCBhcyBDR0FzIGFyZSBtZW50aW9uZWQgYXMg b25lIHBvc3NpYmxlIHVzYWdlIG1vZGVsLCBJIHRoaW5rIGl0IHdvdWxkDQo+YWdhaW4gYmUgaW1w b3J0YW50IHRvIHVuZGVyc3RhbmQgd2h5IHRoZSBvdGhlciB3b3JrcyBpbiB0aGlzIGFyZWENCj4o ZHJhZnQtaWV0Zi1kaGMtY2dhLWNvbmZpZy1kaGNwdjYgYW5kIGRyYWZ0LWlldGYtZGhjLXNlY3Vy ZS1kaGNwdjYpIGFyZSBub3QNCj5hcHByb3ByaWF0ZSBvciBkbyBub3QgY292ZXIgYWxsIG9mIHRo ZSByZXF1aXJlbWVudHMgLSBhbmQgaXQgbWlnaHQgYmUgd29ydGgNCj5jb25zaWRlcmluZyB3b3Jr aW5nIHdpdGggdGhvc2UgYXV0aG9ycz8gTm90ZSBhbHNvIHRoYXQgaW4gbm9ybWFsIERIQ1B2NiwN Cj5jbGllbnRzIG1heSByZXF1ZXN0IGV4cGxpY2l0IGFkZHJlc3NlcyBhbmQgc28gdXNpbmcgQ0dB IGFkZHJlc3NlcyB2aWEgREhDUHY2DQo+aXNuJ3QgaW1wb3NzaWJsZSAoc29tZSBzZXJ2ZXJzIGRv IHJlcXVpcmUgYSByYW5nZSBvZiBhZGRyZXNzZXMgdG8gYmUNCj5jb25maWd1cmVkIGp1c3QgbGlr ZSBmb3IgdjQsIGJ1dCBJIGNvbnNpZGVyIHRoYXQgYXBwcm9hY2ggdG8gbGltaXQgd2hhdCB2NiBo YXMgdG8NCj5vZmZlciAtLSB0aGUgc2VydmVyIEkgd29yayBvbiBkb2VzIG5vdCBoYXZlIHRoaXMg cmVzdHJpY3Rpb24pLg0KPg0KPkkgY2FuIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIHdvcmxkIGlz bid0IGFzIHNpbXBsZSBhcyB3ZSB3b3VsZCBsaWtlIC0gdGhlcmUgYXJlDQo+cGxlbnR5IG9mIGRl dmljZXMgdGhhdCBvbmx5IHN1cHBvcnQgc3RhdGVsZXNzIGFuZCB0aGlzIG1ha2VzIHJ1bm5pbmcg YSAiZnVsbHkiDQo+REhDUHY2IG1hbmFnZWQgbmV0d29yayB3aGVyZSB5b3UgZG9uJ3QgaGF2ZSB0 b3RhbCBjb250cm9sIG9mIHRoZSBkZXZpY2VzDQo+dGhhdCBtYXkgY29ubmVjdCBpbXBvc3NpYmxl LiBCdXQgYnVpbGRpbmcgbW9yZSBjb21wbGV4aXR5IGFuZCBjaG9pY2VzIGludG8NCj5ESENQdjYg aGFyZGx5IHNlZW1zIGxpa2UgdGhlIGEgZ29vZCBhcHByb2FjaCB0byBzb2x2aW5nIHRoaXMgc2lu Y2UgaXQgd2lsbCBiZQ0KPmV2ZW4gbG9uZ2VyIGJlZm9yZSBhbGwgb2YgdGhlIGRldmljZXMgc3Vw cG9ydCB0aGVzZSBuZXcgY29uZmlndXJhdGlvbiBtb2RlbHMNCj4tIG9yIHNvbWUgbWF5IGNob3Nl IG5vdCB0byBpbXBsZW1lbnQgREhDUHY2IGF0IGFsbC4NCj4NCj5Bbnl3YXksIGlmIEkgaGF2ZW4n dCBzYWlkIGl0IGJlZm9yZSBvciBpdCBpc24ndCB5ZXQgY2xlYXIsIEkgaGF2ZSBzZXJpb3VzIG9i amVjdGlvbnMNCj50byBhZHZhbmNpbmcgdGhpcyB3b3JrIGluIGl0cyBjdXJyZW50IGZvcm0gYW5k IGdpdmVuIGl0cyBjdXJyZW50IG1vdGl2YXRpb24uIElmDQo+dGhlIHJhdGlvbmFsIGZvciBuZWVk aW5nIHRoZXNlIGNhcGFiaWxpdGllcyBhbmQgaG93IHRoZXkgYXJlIHVzZWQgYmV0d2Vlbg0KPmNs aWVudHMsIHJlbGF5cywgYW5kIHNlcnZlcnMgYW5kIHRoZSBuZXR3b3JrIGFyZSBleHBsYWluZWQs IEkgd2lsbCBiZSBoYXBweSB0bw0KPnJlbW92ZSBteSBvYmplY3Rpb25zLg0KPg0KPi0gQmVybmll DQo+DQo+T24gQXVnIDE1LCAyMDEyLCBhdCA5OjA4IFBNLCAiQW5kcmUgS29zdHVyIiA8YWtvc3R1 ckBpbmNvZ25pdG8uY29tPg0KPndyb3RlOg0KPg0KPj4gTGVhdmluZyBhc2lkZSB0aGUgaXNzdWUg b2Ygd2hldGhlciB0aGlzICJwcmVmaXggYW5ub3VuY2VtZW50IiBzaG91bGQNCj4+IGJlIGNhcnJp ZWQgb3ZlciBESENQdjYsIEkgd29uZGVyIGlmIHRyeWluZyB0byBmaXQgdGhpcyBpbnRvIGFuDQo+ PiBJZGVudGl0eSBBc3NvY2lhdGlvbiBpc24ndCBxdWl0ZSByaWdodCBzaW5jZSB0aGVyZSBpcyBu byBpZGVudGl0eSB0bw0KPj4gYmUgbWFuYWdlZD8gICBQZXJoYXBzIGEgY2xlYW5lciBzb2x1dGlv biB3b3VsZCBiZSBmb3IgdGhlIGRldmljZSB0bw0KPj4gYXNrIGZvciBhbiBJQVBSRUZJWCBpbiBh biBPUk8gaW4gYW4gSW5mb3JtYXRpb24tUmVxdWVzdCwgYW5kIHRoZQ0KPj4gc2VydmVyIGNhbiBy ZXBseSB3aXRoIGFuIElBUFJFRklYICh0aGF0IGlzbid0IGluIGFueSBJQV8qIG9wdGlvbikuDQo+ Pg0KPj4gSGF2aW5nIHNhaWQgdGhhdCwgSSdtIHdpdGggVGVkIGluIHRoYXQgSSBkb24ndCBxdWl0 ZSBncmFzcCB3aHkgd2UncmUNCj4+IHRyeWluZyB0byBkbyB0aGlzLiAgSXQgdGhlIG5ldHdvcmsg aXMgImZ1bGx5IERIQ1B2Ni1tYW5hZ2VkIiwgd291bGRuJ3QNCj4+IHRoYXQgbWVhbiB0aGF0IHRo ZSBhZG1pbmlzdHJhdG9ycyB3b3VsZCB3YW50IHRvIGNvbnRyb2wgdGhlIGFkZHJlc3MNCj4+IGdl bmVyYXRpb24gaW5zdGVhZCBvZiBsZWF2aW5nIGl0IHVwIHRvIHRoZSBjbGllbnQgdG8gZG8gd2l0 aCBpdCBhcyBpdA0KPj4gd2lsbD8NCj4+DQo+PiBPbiBXZWQsIEF1ZyAxNSwgMjAxMiBhdCA1OjQ5 IFBNLCBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPg0KPndyb3RlOg0KPj4+DQo+ Pj4gSGksIEJlcm5pZSwNCj4+Pg0KPj4+DQo+Pj4NCj4+PiBUaGFua3MgZm9yIHlvdXIgY29tbWVu dHMuIFNlZSBteSByZXBseSBpbiBsaW5lcy4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBTaGVuZw0KPj4+ DQo+Pj4NCj4+Pg0KPj4+IEnigJlkIGFsc28gc3VnZ2VzdCB0aGUgZm9sbG93aW5nIGJlIGNsYXJp ZmllZCAoc2VjdGlvbiA0LCBidWxsZXQgMik6DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgICBJZiB0 aGVyZSBpcyBub3QgYSBwcm9wZXIgcHJlZml4IGF2YWlsYWJsZSwgYSBzdGF0dXMtDQo+Pj4NCj4+ PiAgICAgIGNvZGUgaXMgcmV0dXJuZWQgdG8gdGhlIGhvc3QgYW5kIHRoZSBwcm9jZWR1cmUgaXMg dGVybWluYXRlZC4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBXaGF0IHN0YXR1cyBjb2RlIGFuZCB3aGVy ZSBpcyB0aGlzIHN0YXR1cyBjb2RlIHJldHVybmVkLiBMZXTigJlzIGhvcGUgaXQNCj4+PiBmb2xs b3dzIHRoZSBJQV9QRCBjb252ZW50aW9ucyAoZXNwZWNpYWxseSBpZiB3ZSBrZWVwIHRoZSBJQUlE IGluIHRoZSBJQV9QQSkuDQo+Pj4gVGhlcmUgaXMgbm8gbmV3IHN0YXR1cyBjb2RlIHJlcXVlc3Rl ZCwgZG8gYXBwYXJlbnRseSBpdCBpcyBvbmUgb2YgdGhlDQo+Pj4gZXhpc3RpbmcgY29kZXMgKFJG QyAzMzE1LzM2MzMpPw0KPj4+DQo+Pj4NCj4+Pg0KPj4+IDxTaGVuZz4gSXQgaXMgdGhlIGV4aXN0 aW5nIE5vUHJlZml4QXZhaWwgc3RhdHVzIGNvZGUsIGRlZmluZWQgaW4gUkZDIDM2MzMuDQo+Pj4g SSBoYXZlIGp1c3QgYWRkZWQgYW4gZXhwbGljaXQgZXhwbGFuYXRpb24gZm9yIHRoaXMuDQo+Pj4N Cj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFRoaXMgd29yayBhbHNvIHNlZW1zIHRvIGJlIHRvIHJl cGxhY2luZyBSb3V0ZXIgU29saWNpdGF0aW9uL1JvdXRlcg0KPj4+IEFkdmVydGlzZW1lbnQgbWVz c2FnZXMgdG8gYWR2ZXJ0aXNlIHRoZSBwcmVmaXhlcyAoZm9yIHN0YXRlbGVzcw0KPj4+IGF1dG9j b25maWd1cmF0aW9uKS4gRG8gd2UgcmVhbGx5IHdhbnQgdGhpcy4gQW5kLCBtaWdodCBub3QgdGhp cyBiZQ0KPnNvbWV0aGluZw0KPj4+IHRvIGRpc2N1c3MgaW4gYSBzbGlnaHRseSB3aWRlciBJRVRG IGF1ZGllbmNlLiBQZXJoYXBzIGl0IGhhcyBhbHJlYWR5IGJlZW4gKEkNCj4+PiBoYXZlbuKAmXQg Zm9sbG93ZWQgdGhpcyB3b3JrIHRoYXQgY2xvc2VseSkuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gPFNo ZW5nPiBJdCBpcyB0aGUgYXNzdW1wdGlvbiB3ZSB0YWtlLiBJIGJlbGlldmUgd2UgaGFkIHRoZSBX RyBjb25zZW5zdXMsDQo+Pj4gYnkgYWRvcHRpbmcgYXMgV0cgZG9jdW1lbnQuIEJlY2F1c2UgdGhp cyBvbmx5IGhhcHBlbnMgaW4gYSBmdWxseQ0KPj4+IERIQ1B2Ni1tYW5hZ2VkIG5ldHdvcmssIGRv ZXMgbm90IGltcGFjdCBhbnkgb3RoZXIgbmV0d29yayB0aGF0IHVzZQ0KPlJBIGZvcg0KPj4+IFNM QUNDLCBzbyBJIHRoaW5rIGRpc2N1c3Npb24gaW4gREhDIGlzIGVub3VnaC4NCj4+DQo+PiAtLQ0K Pj4gQW5kcmUgS29zdHVyDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+PiBkaGN3Z0BpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KDQo= From Ted.Lemon@nominum.com Thu Aug 16 07:09:34 2012 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 0747A21F85D0 for ; Thu, 16 Aug 2012 07:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6c3Bs-aFO4l for ; Thu, 16 Aug 2012 07:09:33 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 016DD21F85C5 for ; Thu, 16 Aug 2012 07:09:32 -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 DSNKUCz/HItIh3rFCs7HhUdLKTn0XM9OIqYn@postini.com; Thu, 16 Aug 2012 07:09:33 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 1D1671B82E0 for ; Thu, 16 Aug 2012 07:09:32 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 13026190052 for ; Thu, 16 Aug 2012 07:09:32 -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.02.0247.003; Thu, 16 Aug 2012 07:09:31 -0700 From: Ted Lemon To: dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 Thread-Index: AQHNe7jBKYqvqlvJTk2cfeufL7tTPA== Date: Thu, 16 Aug 2012 14:09:31 +0000 Message-ID: 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: <213425207EC6E04E8EA7C65A7CFBC3F0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 14:09:34 -0000 The authors of this document have requested a working group last call. Th= ere's already been some good review on the list, but more is always welcome= . Please post comments if you have any, and also indicate whether you sup= port advancing the draft as written, or oppose doing so. We will evaluate= consensus on August 31. I should point out that despite its title, this document is about the relay= agent forwarding the client link layer address. There has been discussio= n on the mailing list about other use cases that involve the client sending= its own link layer address; while these use cases may be of interest to th= e working group in a later draft, they are out of scope for this draft, so = please indicate the status of your support for the draft as currently scope= d. Once this work is done, if someone wants to take up work on a new draf= t with a wider scope, the working group will consider doing so. From dankney@network1.net Thu Aug 16 08:08:31 2012 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 A346B21F85BB for ; Thu, 16 Aug 2012 08:08:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY87W+Oczn6E for ; Thu, 16 Aug 2012 08:08:31 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 016E421F85AC for ; Thu, 16 Aug 2012 08:08:30 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id D5A3C540E14; Thu, 16 Aug 2012 11:08:29 -0400 (EDT) Date: Thu, 16 Aug 2012 11:08:29 -0400 (EDT) From: perl-list To: Ted Lemon Message-ID: <999424231.125294.1345129709761.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_125293_569672251.1345129709760" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 15:08:31 -0000 ------=_Part_125293_569672251.1345129709760 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I support moving this draft forward as-is ... The rewording I suggested is not necessary for the success of the document me thinks. Having this option available sooner rather than later is preferable. ----- Original Message ----- > From: "Ted Lemon" > To: "dhc WG" > Sent: Thursday, August 16, 2012 10:09:31 AM > Subject: [dhcwg] WGLC: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > The authors of this document have requested a working group last > call. There's already been some good review on the list, but more is > always welcome. Please post comments if you have any, and also > indicate whether you support advancing the draft as written, or > oppose doing so. We will evaluate consensus on August 31. > I should point out that despite its title, this document is about the > relay agent forwarding the client link layer address. There has been > discussion on the mailing list about other use cases that involve > the client sending its own link layer address; while these use cases > may be of interest to the working group in a later draft, they are > out of scope for this draft, so please indicate the status of your > support for the draft as currently scoped. Once this work is done, > if someone wants to take up work on a new draft with a wider scope, > the working group will consider doing so. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_125293_569672251.1345129709760 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>I support moving this draft forward as-is ... The rewording I s= uggested is not necessary for the success of the document me thinks.  = Having this option available sooner rather than later is preferable.
From: "Ted Lemon" <Ted.Lemon@nominum.com>
To:= "dhc WG" <dhcwg@ietf.org>
Sent: Thursday, August 16, 2= 012 10:09:31 AM
Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-clie= nt-link-layer-addr-opt-01

The authors of this document have requeste= d a working group last call.   There's already been some good review o= n the list, but more is always welcome.   Please post comments if you = have any, and also indicate whether you support advancing the draft as writ= ten, or oppose doing so.   We will evaluate consensus on August 31.
I should point out that despite its title, this document is about the = relay agent forwarding the client link layer address.   There has been= discussion on the mailing list about other use cases that involve the clie= nt sending its own link layer address; while these use cases may be of inte= rest to the working group in a later draft, they are out of scope for this = draft, so please indicate the status of your support for the draft as curre= ntly scoped.   Once this work is done, if someone wants to take up wor= k on a new draft with a wider scope, the working group will consider doing = so.

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

------=_Part_125293_569672251.1345129709760-- From Ted.Lemon@nominum.com Thu Aug 16 09:21:31 2012 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 B557221F8611 for ; Thu, 16 Aug 2012 09:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpBaHiLzuRVd for ; Thu, 16 Aug 2012 09:21:31 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1664B21F85CD for ; Thu, 16 Aug 2012 09:21:31 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUC0eCh7OG2Pqa8YbDkdDH8gV8tPkSnTR@postini.com; Thu, 16 Aug 2012 09:21: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 4F79E1B82F2 for ; Thu, 16 Aug 2012 09:21:30 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 45B46190052 for ; Thu, 16 Aug 2012 09:21:30 -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.02.0247.003; Thu, 16 Aug 2012 09:21:30 -0700 From: Ted Lemon To: dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpddHmiA Date: Thu, 16 Aug 2012 16:21:29 +0000 Message-ID: <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> In-Reply-To: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@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: <456BCB8C62421A43B1BC759817FB39DB@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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: Thu, 16 Aug 2012 16:21:31 -0000 Not wearing my chair hat, I support what this draft is trying to do. Howe= ver, the draft makes a decision to unify the state machines of the IA_NA an= d IA_PD maintenance process. We've had some discussions about this with c= ustomers, and one question that came up was whether it might make sense to = have different DHCP servers answering IA_NA and IA_PD requests. Obviously= this is not possible if the transaction can't be split. Have the authors considered this issue? Any opinions on the topic? The reason for the potential separation is that in some cases the business = logic involved in delegating prefixes may be different than the logic used = to allocate addresses. Keeping the two functions separate enables signifi= cant additional flexibility when provisioning CPE devices. This draft, if= it were to progress in its current state, would rule out any such flexibil= ity. This is not an absolute deal breaker for me, but I wanted to raise t= he issue and see if anybody else has thought about this. From greg.rabil@jagornet.com Thu Aug 16 09:56:08 2012 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 13F9421F860D for ; Thu, 16 Aug 2012 09:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2l0wrYFWhJz for ; Thu, 16 Aug 2012 09:56:07 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E47BB21F85DB for ; Thu, 16 Aug 2012 09:56:06 -0700 (PDT) Received: by bkty7 with SMTP id y7so1198011bkt.31 for ; Thu, 16 Aug 2012 09:56:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=z3/itUNOBMhpaXH+5RT0BJPTUQ8FPDMqtgVr7eYRuW4=; b=bgcEG8ESmR97vOldvXwDiTu7glO3luwxEmCuMd4g5XfOqc40BuejbbI/djaf0glQCi tDTLLssc394Janugb0eN2RsnMd4pd4EnDba54F2MbgQ4/EbcY0ZICSpDSzmukJpJNS1p uV1lt5EFSKB/6gjYyHFmn6KRCqAYAXHbGtzQ93ncdKim54vEyvH5dVnoWwqJCoIp4W2V oEA1o4kO2PGSIEAclMCuvamypr/QBwkIuKXemeBrSn/HFBuGWUFhlq9KOfeEh7Czl5OZ sYwKmQnUjCkBs9i2NY56+sbLzCOrYTEWjCX0isvEHsawr2ZTAjcuncOwMt0MV23AW4OE JkpA== MIME-Version: 1.0 Received: by 10.204.5.144 with SMTP id 16mr893055bkv.128.1345136165771; Thu, 16 Aug 2012 09:56:05 -0700 (PDT) Received: by 10.204.189.6 with HTTP; Thu, 16 Aug 2012 09:56:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Aug 2012 12:56:05 -0400 Message-ID: From: "A. Gregory Rabil" To: dhc WG , Ted Lemon Content-Type: multipart/alternative; boundary=00151758af6455dbe504c764eb12 X-Gm-Message-State: ALoCoQlch+7npDhduTr2h1e58FIw+hUlYOQOhTmbnRhRLR8D36Rh/th+V26PICdXW6XlTv091Sv6 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 16:56:08 -0000 --00151758af6455dbe504c764eb12 Content-Type: text/plain; charset=ISO-8859-1 While I am generally in support of this draft, I have previously expressed that I believe that there are some clear benefits to having the client send its link layer address instead of the relay. I completely understand that from a deployment standpoint, it is much easier to upgrade relays and servers than to wait for clients to implement a new option. In any case, I believe this draft should clarify some items. For example, 1. As it stands, the draft talks only about networks where a relay agent is used. The draft should specify the expected behavior for networks without a relay. 2. Since the option will only appear in RELAY_FORWARD messages, what is the expected behavior for requests that are not forwarded by a relay? Are there any implications to the fact that the information will not be in every packet that the server receives from the client? 3. In section 4, how is the relay agent expected to obtain the client's link-layer address? Is the relay agent code required to be implemented at layer 2? Could it, for example, determine the LL address by reverse-engineering the client's EUI-64 link-local IPv6 address? 4. If there is no relay, is the DHCPv6 server expected or required to obtain this information itself? If so, the same questions regarding the layer-2 implementation requirements are probably applicable. Regards, Greg On Thu, Aug 16, 2012 at 10:09 AM, Ted Lemon wrote: > The authors of this document have requested a working group last call. > There's already been some good review on the list, but more is always > welcome. Please post comments if you have any, and also indicate whether > you support advancing the draft as written, or oppose doing so. We will > evaluate consensus on August 31. > > I should point out that despite its title, this document is about the > relay agent forwarding the client link layer address. There has been > discussion on the mailing list about other use cases that involve the > client sending its own link layer address; while these use cases may be of > interest to the working group in a later draft, they are out of scope for > this draft, so please indicate the status of your support for the draft as > currently scoped. Once this work is done, if someone wants to take up > work on a new draft with a wider scope, the working group will consider > doing so. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --00151758af6455dbe504c764eb12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable While I am generally in support of this draft, I have previously expressed = that I believe that there are some clear benefits to having the client send= its link layer address instead of the relay. =A0I completely understand th= at from a deployment standpoint, it is much easier to upgrade relays and se= rvers than to wait for clients to implement a new option.

In any case, I believe this draft should clarify some items.= =A0For example,

1. As it stands, the draft talks = only about networks where a relay agent is used. =A0The draft should specif= y the expected behavior for networks without a relay.
2. Since the option will only appear in RELAY_FORWARD messages, what i= s the expected behavior for requests that are not forwarded by a relay? Are= there any implications to the fact that the information will not be in eve= ry packet that the server receives from the client?
3. In section 4, how is the relay agent expected to obtain the client&= #39;s link-layer address? =A0Is the relay agent code required to be impleme= nted at layer 2? =A0Could it, for example, determine the LL address by reve= rse-engineering the client's EUI-64 link-local IPv6 address?
4. If there is no relay, is the DHCPv6 server expected or required to = obtain this information itself? =A0If so, the same questions regarding the = layer-2 implementation requirements are probably applicable.

Regards,
Greg

On Thu, Aug 16, 2012 at 10:09 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
The authors of this document have requested = a working group last call. =A0 There's already been some good review on= the list, but more is always welcome. =A0 Please post comments if you have= any, and also indicate whether you support advancing the draft as written,= or oppose doing so. =A0 We will evaluate consensus on August 31.

I should point out that despite its title, this document is about the relay= agent forwarding the client link layer address. =A0 There has been discuss= ion on the mailing list about other use cases that involve the client sendi= ng its own link layer address; while these use cases may be of interest to = the working group in a later draft, they are out of scope for this draft, s= o please indicate the status of your support for the draft as currently sco= ped. =A0 Once this work is done, if someone wants to take up work on a new = draft with a wider scope, the working group will consider doing so.

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

--00151758af6455dbe504c764eb12-- From cra@WPI.EDU Thu Aug 16 10:37:47 2012 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 2634E21F860D for ; Thu, 16 Aug 2012 10:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dFrs0YEYQ+y for ; Thu, 16 Aug 2012 10:37:46 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1E321F85FF for ; Thu, 16 Aug 2012 10:37:46 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GHbjWT004257; Thu, 16 Aug 2012 13:37:45 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q7GHbjWT004257 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1345138665; bh=wiBln6P3sm8yz9BWuehgWD4FAFDQzcFt6YGxXf+0+KM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=Ia/xorczDLvUgICgJ4NvvseiryZWr/Zx5qXHGYXkzBnGddNPPeM6pustD20FgzsKk 9yAYQchTU8vSeJ3UofYtRxmthYLRQVEu+9Cty9L6tT9ddUugTkJShd1hhWe0pxqyES CBT/Hft2PuubrSEa4W2/gjdgEK2J906tIv277o5Q= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GHbjT7004254; Thu, 16 Aug 2012 13:37:45 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GHbhRF007539; Thu, 16 Aug 2012 13:37:44 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GHbh7N026858; Thu, 16 Aug 2012 13:37:43 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id q7GHbgY2026857; Thu, 16 Aug 2012 13:37:42 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 16 Aug 2012 13:37:42 -0400 From: Chuck Anderson To: "A. Gregory Rabil" Message-ID: <20120816173740.GD4612@angus.ind.WPI.EDU> Mail-Followup-To: "A. Gregory Rabil" , dhc WG , Ted Lemon References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 17:37:47 -0000 On Thu, Aug 16, 2012 at 12:56:05PM -0400, A. Gregory Rabil wrote: > While I am generally in support of this draft, I have previously expressed > that I believe that there are some clear benefits to having the client send > its link layer address instead of the relay. I completely understand that > from a deployment standpoint, it is much easier to upgrade relays and > servers than to wait for clients to implement a new option. > > In any case, I believe this draft should clarify some items. For example, > > 1. As it stands, the draft talks only about networks where a relay agent is > used. The draft should specify the expected behavior for networks without > a relay. I disagree. This draft is only about a relay option. There is no change to servers or clients with this draft, except that a server may use the additional information in the RELAY-FORW message. > 2. Since the option will only appear in RELAY_FORWARD messages, what is the > expected behavior for requests that are not forwarded by a relay? Are there > any implications to the fact that the information will not be in every > packet that the server receives from the client? There is no required behavior change for clients or servers specified in this draft, therefore what you ask is out of scope. This is no different than Option82 in DHCPv4--if the information is missing or the packet wasn't relayed, then the server can't use it to classify clients. > 3. In section 4, how is the relay agent expected to obtain the client's > link-layer address? Is the relay agent code required to be implemented at > layer 2? Could it, for example, determine the LL address by > reverse-engineering the client's EUI-64 link-local IPv6 address? I could go along with additional text in Section 4 to specify that the Relay Agent should insert the LL address of the IPv6 interface that is being configured on the client. How an implementation does that is an implementation detail and doesn't need to be specified here, but I don't think EUI-64 can be relied upon to contain the proper client LL address in all cases. > 4. If there is no relay, is the DHCPv6 server expected or required to > obtain this information itself? If so, the same questions regarding the > layer-2 implementation requirements are probably applicable. No, that functionality is out of scope for this draft. A server could extract a LL address in the same way that a relay would, but that behavior isn't specified. I don't think we should block this draft in order to extend it to specify how the server may acquire a client's LL address other than via a RELAY-FORW message. For the intended use cases as described in Section 2, an operator can easily design their network to be sure that all DHCPv6 traffic passes through a relay. For the non-relayed case, it would be much easier to modify an open source DHCPv6 server to implement whatever behavior is wanted without affecting other parts of the network--hence there is less need to standardize that behavior through the IETF. The Relay Agent option described in this draft does benefit from standardization since an agreed format for passing the information from the Relay to the Server will need to be implemented by many switch/router vendors as well as server software vendors. If it is desired to specify additional client and/or server behavior for other use cases such as non-relayed packets, I would prefer that it be done in separate draft(s). From Ted.Lemon@nominum.com Thu Aug 16 10:38:44 2012 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 E163721F865C for ; Thu, 16 Aug 2012 10:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVbB876UmgEY for ; Thu, 16 Aug 2012 10:38:42 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB7721F860D for ; Thu, 16 Aug 2012 10:38:42 -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 DSNKUC0wBOjKjtOAByVYDpFuFn96BqgBZK4m@postini.com; Thu, 16 Aug 2012 10:38:42 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 6C9441B82F9 for ; Thu, 16 Aug 2012 10:37:52 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 60BBF19005C for ; Thu, 16 Aug 2012 10:37: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.02.0247.003; Thu, 16 Aug 2012 10:37:52 -0700 From: Ted Lemon To: dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpddHmiAgAAVWYA= Date: Thu, 16 Aug 2012 17:37:51 +0000 Message-ID: <5AAE3B81-ABDE-49AF-BD14-C5307EC7CA7E@nominum.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> In-Reply-To: <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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: Thu, 16 Aug 2012 17:38:44 -0000 One other question about this draft: it proposes extending the Confirm mess= age to stateful options other than IA_NA. Presumably, the option we're mo= st interested in is IA_PD, but how would a DHCP server without access to th= e client binding state know that a PD was valid? Are we talking about a s= cenario like Leaf Yeh's prefix pool option, whether the server simply valid= ates that the proposed prefixes are within the pool that is assigned to the= specific PE router? From Ted.Lemon@nominum.com Thu Aug 16 10:43:14 2012 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 6953921F866A for ; Thu, 16 Aug 2012 10:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhDrKSSCop2l for ; Thu, 16 Aug 2012 10:43:14 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id D5EB621F853E for ; Thu, 16 Aug 2012 10:43:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUC0xMW10ftbHyIhfPADtc/nuoFpsQQSQ@postini.com; Thu, 16 Aug 2012 10:43: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 DA5231B82F9 for ; Thu, 16 Aug 2012 10:43:12 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 D020B190052; Thu, 16 Aug 2012 10:43:12 -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.02.0247.003; Thu, 16 Aug 2012 10:43:12 -0700 From: Ted Lemon To: Chuck Anderson Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 Thread-Index: AQHNe7jBKYqvqlvJTk2cfeufL7tTPJddHfOAgAALoQCAAAGIgA== Date: Thu, 16 Aug 2012 17:43:12 +0000 Message-ID: <0016C6A9-CD91-4A4C-8303-8A53A45C8AF4@nominum.com> References: <20120816173740.GD4612@angus.ind.WPI.EDU> In-Reply-To: <20120816173740.GD4612@angus.ind.WPI.EDU> 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: <8C9AE0D1EF2A0848BF39ABB39402F035@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 17:43:14 -0000 Chuck, I think I can read your response as saying that you are happy with t= he draft as it is, and while you would not oppose having the draft say how = the DHCP server might acquire the link local address for a packet that arri= ved without being relayed, you don't think it's necessary or desirable, cor= rect? (I ask only so that we will know what to do later on when we evalua= te consensus). From dankney@network1.net Thu Aug 16 10:51:09 2012 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 724EB21F8644 for ; Thu, 16 Aug 2012 10:51:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nutQcCuZQ6Q9 for ; Thu, 16 Aug 2012 10:51:07 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC2F21F85DF for ; Thu, 16 Aug 2012 10:51:01 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id EAC75541104; Thu, 16 Aug 2012 13:51:00 -0400 (EDT) Date: Thu, 16 Aug 2012 13:51:00 -0400 (EDT) From: perl-list To: "A. Gregory Rabil" Message-ID: <10414435.125914.1345139460853.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_125913_576513157.1345139460852" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 17:51:09 -0000 ------=_Part_125913_576513157.1345139460852 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit One comment I would make regarding what you say below is that it isn't always possible to reverse engineer the EUI-64 link-local IPv6 address and obtain the Link Layer address. example: windows7 laptop I have beside me here... Link-local IPv6 Address...: fe80:fcf1:aac3:ab67:25a4%11 ( fe80::4cf1:aac3:ab67:25a4 as seen using show ipv6 neighbors on a juniper SRX) Pysical Address ..........: 00-15-C5-14-CE-B0 Some of your other comments got me to thinking, however... On DHCPv4, the client may start communicating directly with the DHCP server ignoring the relay agent for renews (no idea if it is supposed to do that, but some do). Is this the case in DHCPv6? Is it possible for the client to ignore the relay agent and communicate directly with the DHCPv6 server on rebind? If so, then this solution will only sort of work... ----- Original Message ----- > From: "A. Gregory Rabil" > To: "dhc WG" , "Ted Lemon" > Sent: Thursday, August 16, 2012 12:56:05 PM > Subject: Re: [dhcwg] WGLC: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > While I am generally in support of this draft, I have previously > expressed that I believe that there are some clear benefits to > having the client send its link layer address instead of the relay. > I completely understand that from a deployment standpoint, it is > much easier to upgrade relays and servers than to wait for clients > to implement a new option. > In any case, I believe this draft should clarify some items. For > example, > 1. As it stands, the draft talks only about networks where a relay > agent is used. The draft should specify the expected behavior for > networks without a relay. > 2. Since the option will only appear in RELAY_FORWARD messages, what > is the expected behavior for requests that are not forwarded by a > relay? Are there any implications to the fact that the information > will not be in every packet that the server receives from the > client? > 3. In section 4, how is the relay agent expected to obtain the > client's link-layer address? Is the relay agent code required to be > implemented at layer 2? Could it, for example, determine the LL > address by reverse-engineering the client's EUI-64 link-local IPv6 > address? > 4. If there is no relay, is the DHCPv6 server expected or required to > obtain this information itself? If so, the same questions regarding > the layer-2 implementation requirements are probably applicable. > Regards, > Greg > On Thu, Aug 16, 2012 at 10:09 AM, Ted Lemon < Ted.Lemon@nominum.com > > wrote: > > The authors of this document have requested a working group last > > call. There's already been some good review on the list, but more > > is > > always welcome. Please post comments if you have any, and also > > indicate whether you support advancing the draft as written, or > > oppose doing so. We will evaluate consensus on August 31. > > > I should point out that despite its title, this document is about > > the > > relay agent forwarding the client link layer address. There has > > been > > discussion on the mailing list about other use cases that involve > > the client sending its own link layer address; while these use > > cases > > may be of interest to the working group in a later draft, they are > > out of scope for this draft, so please indicate the status of your > > support for the draft as currently scoped. Once this work is done, > > if someone wants to take up work on a new draft with a wider scope, > > the working group will consider doing so. > > > _______________________________________________ > > > 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 ------=_Part_125913_576513157.1345139460852 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>
One comment I would make regarding what y= ou say below is that it isn't always possible to reverse engineer the = EUI-64 link-local IPv6 address and obtain the Link Layer address.

example: windows7 laptop = I have beside me here...

Link-local IPv6 Address...: fe80:fcf1:aac3= :ab67:25a4%11 (fe80::4cf1:aac3:ab67:25a4 as seen using show ipv6 = neighbors on a juniper SRX)
Pysical Address ..........: 00-15-C5-14-CE-B0

Some of your other comments= got me to thinking, however...  On DHCPv4, the client may start commu= nicating directly with the DHCP server ignoring the relay agent for renews = (no idea if it is supposed to do that, but some do).  Is this the case= in DHCPv6?  Is it possible for the client to ignore the relay agent a= nd communicate directly with the DHCPv6 server on rebind?  If so, then= this solution will only sort of work...

From: "A. Gregory Rabil" <greg.rabil@jagornet.com>
To: = "dhc WG" <dhcwg@ietf.org>, "Ted Lemon" <Ted.Lemon@nominum.com&= gt;
Sent: Thursday, August 16, 2012 12:56:05 PM
Subject: Re: [dhcwg] WGLC:        draft-ie= tf-dhc-dhcpv6-client-link-layer-addr-opt-01

While I am generally in = support of this draft, I have previously expressed that I believe that ther= e are some clear benefits to having the client send its link layer address = instead of the relay.  I completely understand that from a deployment = standpoint, it is much easier to upgrade relays and servers than to wait fo= r clients to implement a new option.

In any case, I believe this draft should clarify some items.=  For example,

1. As it stands, the draft tal= ks only about networks where a relay agent is used.  The draft should = specify the expected behavior for networks without a relay.
2. Since the option will only appear in RELAY_FORWARD messages, what i= s the expected behavior for requests that are not forwarded by a relay? Are= there any implications to the fact that the information will not be in eve= ry packet that the server receives from the client?
3. In section 4, how is the relay agent expected to obtain the client'= s link-layer address?  Is the relay agent code required to be implemen= ted at layer 2?  Could it, for example, determine the LL address by re= verse-engineering the client's EUI-64 link-local IPv6 address?
4. If there is no relay, is the DHCPv6 server expected or required to = obtain this information itself?  If so, the same questions regarding t= he layer-2 implementation requirements are probably applicable.
<= br>
Regards,
Greg

On Thu, Aug 16, 2012 at 10:09 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
The authors of this document have requested = a working group last call.   There's already been some good review on = the list, but more is always welcome.   Please post comments if you ha= ve any, and also indicate whether you support advancing the draft as writte= n, or oppose doing so.   We will evaluate consensus on August 31.

I should point out that despite its title, this document is about the relay= agent forwarding the client link layer address.   There has been disc= ussion on the mailing list about other use cases that involve the client se= nding its own link layer address; while these use cases may be of interest = to the working group in a later draft, they are out of scope for this draft= , so please indicate the status of your support for the draft as currently = scoped.   Once this work is done, if someone wants to take up work on = a new draft with a wider scope, the working group will consider doing so.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg


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

------=_Part_125913_576513157.1345139460852-- From Ted.Lemon@nominum.com Thu Aug 16 10:53:37 2012 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 9F39421F867A for ; Thu, 16 Aug 2012 10:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdKwlP6ny41y for ; Thu, 16 Aug 2012 10:53:35 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4304F21F8678 for ; Thu, 16 Aug 2012 10:53:31 -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 DSNKUC0zmtT/ZGkeH1VtXq4UgB9TaDiQL8by@postini.com; Thu, 16 Aug 2012 10:53: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 580891B8315 for ; Thu, 16 Aug 2012 10:53:30 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 4EF83190052; Thu, 16 Aug 2012 10:53: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.02.0247.003; Thu, 16 Aug 2012 10:53:30 -0700 From: Ted Lemon To: perl-list Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 Thread-Index: AQHNe9ezdoooCteIdEOk3xMKYKDUp5ddLbqA Date: Thu, 16 Aug 2012 17:53:29 +0000 Message-ID: <638607D0-D89C-4ED6-A3BF-FF2DECBF4D47@nominum.com> References: <10414435.125914.1345139460853.JavaMail.root@network1.net> In-Reply-To: <10414435.125914.1345139460853.JavaMail.root@network1.net> 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: multipart/alternative; boundary="_000_638607D0D89C4ED6A3BFFF2DECBF4D47nominumcom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 17:53:37 -0000 --_000_638607D0D89C4ED6A3BFFF2DECBF4D47nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 16, 2012, at 1:51 PM, perl-list wrote: Some of your other comments got me to thinking, however... On DHCPv4, the = client may start communicating directly with the DHCP server ignoring the r= elay agent for renews (no idea if it is supposed to do that, but some do). = Is this the case in DHCPv6? Is it possible for the client to ignore the r= elay agent and communicate directly with the DHCPv6 server on rebind? If s= o, then this solution will only sort of work... The client isn't allowed to do this unless it negotiates it with the server= , which presumably would say no in any environment where the client-link-la= yer-address option was used. This was a deliberate design decision in RFC= 3315, to deal with the exact problem you are talking about. --_000_638607D0D89C4ED6A3BFFF2DECBF4D47nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <85A0BBD35B9DCA4985CF13C77CB7E0C3@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 16, 2012, at 1:51 PM, perl-list wrote:
Some of your other comments got me to thinking, however...  On DHCPv4, the= client may start communicating directly with the DHCP server ignoring the = relay agent for renews (no idea if it is supposed to do that, but some do).=  Is this the case in DHCPv6?  Is it possible for the client to ignore the relay agent and communicate directly= with the DHCPv6 server on rebind?  If so, then this solution will onl= y sort of work...

The client isn't allowed to do this unless it negotiates it with the s= erver, which presumably would say no in any environment where the client-li= nk-layer-address option was used.   This was a deliberate design decis= ion in RFC3315, to deal with the exact problem you are talking about.

--_000_638607D0D89C4ED6A3BFFF2DECBF4D47nominumcom_-- From wbeebee@cisco.com Thu Aug 16 10:54:15 2012 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 66B5621F8678 for ; Thu, 16 Aug 2012 10:54:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBCfjTPBd5mZ for ; Thu, 16 Aug 2012 10:54:14 -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 ED08121F8694 for ; Thu, 16 Aug 2012 10:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=1261; q=dns/txt; s=iport; t=1345139654; x=1346349254; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=xrhW3QTfD9O5f8xwKFq7W10H8urWksxG9eNYFvr0V2I=; b=HYKcEWrxg+dMB3Z3yamVE/8wHVOzK2cBBnAKzKWSanEPDBqOYsgte/jA NyMDC7bmLoLq+Yy1CgJNbHUXHZwtYmcXBLRgkrPy9C4sd8I+FX0u3tKxb 8Ynvgmv4UatRNWaE8eVHGcsDXPpS/QWqBozh+LqYL+C8IfIZmrWbEafq3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPwyLVCtJV2Y/2dsb2JhbABABbotgQeCIgEEAQEBDwEnLQcdAQg2NwslAgQBEhsHh2sLmkCgOwSLMoYvA5VPjiyBZoJf X-IronPort-AV: E=Sophos;i="4.77,780,1336348800"; d="scan'208";a="112103343" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 16 Aug 2012 17:54:13 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7GHsD4h018043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Aug 2012 17:54:13 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.212]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 12:54:12 -0500 From: "Wes Beebee (wbeebee)" To: Ted Lemon , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpdc076A Date: Thu, 16 Aug 2012 17:54:12 +0000 Message-ID: In-Reply-To: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@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: [161.44.175.143] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19116.000 x-tm-as-result: No--34.207200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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: Thu, 16 Aug 2012 17:54:15 -0000 Why MUST the client ignore an Advertise message with no bindings? What if stateful and stateless options are carried in the same message? Does this mean the stateless options will be ignored just because the stateful=20 Options failed? In general, I think this draft addresses an important problem that needs to be=20 solved urgently. We need to think through carefully the consequences of the proposed=20 solutions, however. - Wes On 8/9/12 11:14 PM, "Ted Lemon" wrote: >The authors have requested a working group last call. The document >describes some problems that exist in the way DHCP clients handle >multiple stateful options, and proposes a solution that unifies the >client state machine to accommodate these issues. > >This document could use additional review, so please take the time to >read it over and comment on it if you have any comments. If you are in >favor of advancing the document, please say so. If you oppose advancing >it, please say so, and say why. We will evaluate the consensus based on >these responses on August 24. > >Thanks! > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg From cra@WPI.EDU Thu Aug 16 10:55:40 2012 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 724D721F854C for ; Thu, 16 Aug 2012 10:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92LaQ-GDzPHm for ; Thu, 16 Aug 2012 10:55:39 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3562521F84C4 for ; Thu, 16 Aug 2012 10:55:37 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GHtbUH016658; Thu, 16 Aug 2012 13:55:37 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q7GHtbUH016658 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1345139737; bh=tjTRKr71FTzPIlwK8Ev6Wg/3zbv/Lem3jnIgSDsxF38=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=FzApH3TqhUA8Zl0WAMCvqUpwsLkjI8oe7mdt/wSb1pvWPHCJJe0/0wPe/yB73aYxb Li4TPin/cFk1LeiBGrZ29PWY+RmFP7rMHjVC9jgwByEZG/E8gajCdSI7VymfjNH5H+ x6r6TKXC7bpDp7kG5XIZhSNfQ1TmeU99Pqvd3xlo= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GHtbfB016654; Thu, 16 Aug 2012 13:55:37 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GHtZaD030856; Thu, 16 Aug 2012 13:55:36 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GHtZvC027276; Thu, 16 Aug 2012 13:55:35 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id q7GHtZa9027275; Thu, 16 Aug 2012 13:55:35 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 16 Aug 2012 13:55:35 -0400 From: Chuck Anderson To: perl-list Message-ID: <20120816175534.GE4612@angus.ind.WPI.EDU> Mail-Followup-To: perl-list , "A. Gregory Rabil" , dhc WG References: <10414435.125914.1345139460853.JavaMail.root@network1.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10414435.125914.1345139460853.JavaMail.root@network1.net> User-Agent: Mutt/1.5.20 (2009-12-10) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 17:55:40 -0000 On Thu, Aug 16, 2012 at 01:51:00PM -0400, perl-list wrote: > Some of your other comments got me to thinking, however... On > DHCPv4, the client may start communicating directly with the DHCP > server ignoring the relay agent for renews (no idea if it is > supposed to do that, but some do). Is this the case in DHCPv6? Is it > possible for the client to ignore the relay agent and communicate > directly with the DHCPv6 server on rebind? If so, then this solution > will only sort of work... No, DHCPv6 messages are always multicast and picked up by Relays (or directly connected Servers). There is no such thing as unicast Renew in DHCPv6. From greg.rabil@jagornet.com Thu Aug 16 11:03:44 2012 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 E79BD21F8670 for ; Thu, 16 Aug 2012 11:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f6QeoDHmEQ7 for ; Thu, 16 Aug 2012 11:03:44 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E384121F8661 for ; Thu, 16 Aug 2012 11:03:43 -0700 (PDT) Received: by bkty7 with SMTP id y7so1222535bkt.31 for ; Thu, 16 Aug 2012 11:03:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=8bRcatBzlczwusNqe/DVeqIqXumWWnYVWLUHQAHQxI4=; b=hQ2CM9MM4cyx51oS5Xi61kfRMsRKc34XLKjbqZgBbSBZBGM9a/yvopw6n7E1TnAW+A AeaZeI+dUj+CGC10294ukZ/9St0PnlVHjS7EIIfxrtFrQ/GU778emavO/RCMrqGq6vQ5 W7NXlqh/Tj/szQrzV/ZQWJgby7E3xF2ZA2XfFIYmxHTqc046EswjqylNf0bbe4WledQD to8tEqYG5tn5WADcyGRyEVD1vkIfjGEYObNWNzJn5LDOzvcJXODcuNNr2BgD6btopVPY ubG1+R8y4p3eWlOD4gZ0ZytsZmLMM7VacRAsfrVuN/PuB6vwY+HsqoPQ+3sDHybtT0pD wbEw== MIME-Version: 1.0 Received: by 10.204.5.144 with SMTP id 16mr978184bkv.128.1345140222824; Thu, 16 Aug 2012 11:03:42 -0700 (PDT) Received: by 10.204.189.6 with HTTP; Thu, 16 Aug 2012 11:03:42 -0700 (PDT) In-Reply-To: <20120816175534.GE4612@angus.ind.WPI.EDU> References: <10414435.125914.1345139460853.JavaMail.root@network1.net> <20120816175534.GE4612@angus.ind.WPI.EDU> Date: Thu, 16 Aug 2012 14:03:42 -0400 Message-ID: From: "A. Gregory Rabil" To: perl-list , "A. Gregory Rabil" , dhc WG Content-Type: multipart/alternative; boundary=00151758af642791f204c765ddef X-Gm-Message-State: ALoCoQnzsWeRrBIt+YXTEvZcTsg94mcFNksWtXPhOBIICVy3Gk7o0BNGAc/qxxPZE3YgH4V4Hg6l Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 18:03:45 -0000 --00151758af642791f204c765ddef Content-Type: text/plain; charset=ISO-8859-1 Really? RFC 3315: 18.1.3. Creation and Transmission of Renew Messages To extend the valid and preferred lifetimes for the addresses associated with an IA, the client sends a Renew message to the server from which the client obtained the addresses in the IA containing an IA option for the IA. Greg On Thu, Aug 16, 2012 at 1:55 PM, Chuck Anderson wrote: > On Thu, Aug 16, 2012 at 01:51:00PM -0400, perl-list wrote: > > > Some of your other comments got me to thinking, however... On > > DHCPv4, the client may start communicating directly with the DHCP > > server ignoring the relay agent for renews (no idea if it is > > supposed to do that, but some do). Is this the case in DHCPv6? Is it > > possible for the client to ignore the relay agent and communicate > > directly with the DHCPv6 server on rebind? If so, then this solution > > will only sort of work... > > No, DHCPv6 messages are always multicast and picked up by Relays (or > directly connected Servers). There is no such thing as unicast Renew > in DHCPv6. > --00151758af642791f204c765ddef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Really?

RFC 3315:

18.1.3. Creation and Transmissi=
on of Renew Messages

   To extend the valid and preferred lifetimes for the addresses
   associated with an IA, the client sends a Renew message to the server
   from which the client obtained the addresses in the IA containing an
   IA option for the IA.  

Greg

On Thu, Aug 16, 2012 at 1:55= PM, Chuck Anderson <cra@wpi.edu> wrote:
On Thu, Aug 16, 2012 at 01= :51:00PM -0400, perl-list wrote:

> Some of your other comments got me to thinking, however... On
> DHCPv4, the client may start communicating directly with the DHCP
> server ignoring the relay agent for renews (no idea if it is
> supposed to do that, but some do). Is this the case in DHCPv6? Is it > possible for the client to ignore the relay agent and communicate
> directly with the DHCPv6 server on rebind? If so, then this solution > will only sort of work...

No, DHCPv6 messages are always multicast and picked up by Relays (or<= br> directly connected Servers). =A0There is no such thing as unicast Renew
in DHCPv6.

--00151758af642791f204c765ddef-- From dankney@network1.net Thu Aug 16 11:05:12 2012 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 874CD21F847F for ; Thu, 16 Aug 2012 11:05:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogrsXl2YHaJm for ; Thu, 16 Aug 2012 11:05:12 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id E3AF021F847D for ; Thu, 16 Aug 2012 11:05:06 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id DB5C4541104; Thu, 16 Aug 2012 14:05:05 -0400 (EDT) Date: Thu, 16 Aug 2012 14:05:05 -0400 (EDT) From: perl-list To: Ted Lemon Message-ID: <1810312575.126096.1345140305786.JavaMail.root@network1.net> In-Reply-To: <638607D0-D89C-4ED6-A3BF-FF2DECBF4D47@nominum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_126095_1285250243.1345140305785" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 18:05:12 -0000 ------=_Part_126095_1285250243.1345140305785 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Ted Lemon" > To: "perl-list" > Cc: "A. Gregory Rabil" , "dhc WG" > > Sent: Thursday, August 16, 2012 1:53:29 PM > Subject: Re: [dhcwg] WGLC: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > On Aug 16, 2012, at 1:51 PM, perl-list wrote: > > Some of your other comments got me to thinking, however... On > > DHCPv4, > > the client may start communicating directly with the DHCP server > > ignoring the relay agent for renews (no idea if it is supposed to > > do > > that, but some do). Is this the case in DHCPv6? Is it possible for > > the client to ignore the relay agent and communicate directly with > > the DHCPv6 server on rebind? If so, then this solution will only > > sort of work... > > The client isn't allowed to do this unless it negotiates it with the > server, which presumably would say no in any environment where the > client-link-layer-address option was used. This was a deliberate > design decision in RFC3315, to deal with the exact problem you are > talking about. Thank you, designers, for that!! Very irritating in the DHCPv4 space. ------=_Part_126095_1285250243.1345140305785 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


From: "Ted Lemon" <Ted.Lemon@nominum.com>
To: "perl-list" <perl-list@network1.net>
Cc: "A. Gregory Rabil" <greg.rabil@jagornet.com>, "dhc WG" <dhcwg@ietf.org>
Sent: Thursday, August 16, 2012 1:53:29 PM
Subject: Re: [dhcwg] WGLC:        draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

On Aug 16, 2012, at 1:51 PM, perl-list wrote:
Some of your other comments got me to thinking, however...  On DHCPv4, the client may start communicating directly with the DHCP server ignoring the relay agent for renews (no idea if it is supposed to do that, but some do).  Is this the case in DHCPv6?  Is it possible for the client to ignore the relay agent and communicate directly with the DHCPv6 server on rebind?  If so, then this solution will only sort of work...

The client isn't allowed to do this unless it negotiates it with the server, which presumably would say no in any environment where the client-link-layer-address option was used.   This was a deliberate design decision in RFC3315, to deal with the exact problem you are talking about.

Thank you, designers, for that!!  Very irritating in the DHCPv4 space.
------=_Part_126095_1285250243.1345140305785-- From greg.rabil@jagornet.com Thu Aug 16 11:07:31 2012 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 6825A21F849D for ; Thu, 16 Aug 2012 11:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnbYVJzp8uwa for ; Thu, 16 Aug 2012 11:07:30 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5D4521F847D for ; Thu, 16 Aug 2012 11:07:29 -0700 (PDT) Received: by bkty7 with SMTP id y7so1223861bkt.31 for ; Thu, 16 Aug 2012 11:07:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=WloG8YXUWuvr30nxxQujJFBHDycqGwe0VRQZlKtACVw=; b=MT802r6nbhdW9TOhoCwHJpvYHUWuZZrOUoObRViaJD0JCx07q4WNA5HIpAKTiZFO2m 3PlIIClcsV0e7UY7dmgBrgmOe3FyfXx1MGii+y5eMH0VvfGl18y1GPgB0zul1TErqzf7 8Qt2XqgaCKuiwJ8pOjwnpAFXMOD4Sty1wVnl/24ky98wotYgqzWtmF2p75H6zO2aBmiq Ve3LUwQoCAXMJ1TOEE/HtEJA3c4JhDn4MogbteDs3Osj9xgY03VEPH14av6Pko2p64sx bO570CFYPpKOL+Q1NbiEhiMomCCoPXMaKTKWyaj/4eBvClkz9L3Wu9sHCTmYKpge7IOy XD7Q== MIME-Version: 1.0 Received: by 10.205.134.139 with SMTP id ic11mr1041230bkc.40.1345140448856; Thu, 16 Aug 2012 11:07:28 -0700 (PDT) Received: by 10.204.189.6 with HTTP; Thu, 16 Aug 2012 11:07:28 -0700 (PDT) In-Reply-To: <20120816173740.GD4612@angus.ind.WPI.EDU> References: <20120816173740.GD4612@angus.ind.WPI.EDU> Date: Thu, 16 Aug 2012 14:07:28 -0400 Message-ID: From: "A. Gregory Rabil" To: "A. Gregory Rabil" , dhc WG , Ted Lemon Content-Type: multipart/alternative; boundary=000e0ce005fea08c3c04c765ea74 X-Gm-Message-State: ALoCoQmSfipWA3e1Dcp1i6+QJNI5N9fUnyvRdcw0G4X9Mmq8bv1KoQiPJQtGBa6QUR13E7C/1PS/ Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 18:07:31 -0000 --000e0ce005fea08c3c04c765ea74 Content-Type: text/plain; charset=ISO-8859-1 My point here is that if non-relayed environments are out of scope, that should be clearly specified in the draft. The abstract and problem description does not say anything about it applying only to relayed environments. As for the specification not defining the implementation, I agree. However, it seems that the nature of this option indeed _forces_ the implementation. Greg On Thu, Aug 16, 2012 at 1:37 PM, Chuck Anderson wrote: > On Thu, Aug 16, 2012 at 12:56:05PM -0400, A. Gregory Rabil wrote: > > While I am generally in support of this draft, I have previously > expressed > > that I believe that there are some clear benefits to having the client > send > > its link layer address instead of the relay. I completely understand > that > > from a deployment standpoint, it is much easier to upgrade relays and > > servers than to wait for clients to implement a new option. > > > > In any case, I believe this draft should clarify some items. For > example, > > > > 1. As it stands, the draft talks only about networks where a relay agent > is > > used. The draft should specify the expected behavior for networks > without > > a relay. > > I disagree. This draft is only about a relay option. There is no > change to servers or clients with this draft, except that a server may > use the additional information in the RELAY-FORW message. > > > 2. Since the option will only appear in RELAY_FORWARD messages, what is > the > > expected behavior for requests that are not forwarded by a relay? Are > there > > any implications to the fact that the information will not be in every > > packet that the server receives from the client? > > There is no required behavior change for clients or servers specified > in this draft, therefore what you ask is out of scope. This is no > different than Option82 in DHCPv4--if the information is missing or > the packet wasn't relayed, then the server can't use it to classify > clients. > > > 3. In section 4, how is the relay agent expected to obtain the client's > > link-layer address? Is the relay agent code required to be implemented > at > > layer 2? Could it, for example, determine the LL address by > > reverse-engineering the client's EUI-64 link-local IPv6 address? > > I could go along with additional text in Section 4 to specify that the > Relay Agent should insert the LL address of the IPv6 interface that is > being configured on the client. How an implementation does that is an > implementation detail and doesn't need to be specified here, but I > don't think EUI-64 can be relied upon to contain the proper client LL > address in all cases. > > > 4. If there is no relay, is the DHCPv6 server expected or required to > > obtain this information itself? If so, the same questions regarding the > > layer-2 implementation requirements are probably applicable. > > No, that functionality is out of scope for this draft. A server could > extract a LL address in the same way that a relay would, but that > behavior isn't specified. > > I don't think we should block this draft in order to extend it to > specify how the server may acquire a client's LL address other than > via a RELAY-FORW message. For the intended use cases as described in > Section 2, an operator can easily design their network to be sure that > all DHCPv6 traffic passes through a relay. For the non-relayed case, > it would be much easier to modify an open source DHCPv6 server to > implement whatever behavior is wanted without affecting other parts of > the network--hence there is less need to standardize that behavior > through the IETF. The Relay Agent option described in this draft does > benefit from standardization since an agreed format for passing the > information from the Relay to the Server will need to be implemented > by many switch/router vendors as well as server software vendors. > > If it is desired to specify additional client and/or server behavior > for other use cases such as non-relayed packets, I would prefer that > it be done in separate draft(s). > --000e0ce005fea08c3c04c765ea74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My point here is that if non-relayed environments are out of scope, that sh= ould be clearly specified in the draft. =A0The abstract and problem descrip= tion does not say anything about it applying only to relayed environments.<= div>
As for the specification not defining the implementation, I = agree. =A0However, it seems that the nature of this option indeed _forces_ = the implementation.

Greg

On Thu, Aug 16, 2012 at 1:37 PM, Chuck Anderson <cra@wpi.edu> wrot= e:
On Thu, Aug 16, 2012 at 12:56:05PM -0400, A. Gregory Rabi= l wrote:
> While I am generally in support of this draft, I have previously expre= ssed
> that I believe that there are some clear benefits to having the client= send
> its link layer address instead of the relay. =A0I completely understan= d that
> from a deployment standpoint, it is much easier to upgrade relays and<= br> > servers than to wait for clients to implement a new option.
>
> In any case, I believe this draft should clarify some items. =A0For ex= ample,
>
> 1. As it stands, the draft talks only about networks where a relay age= nt is
> used. =A0The draft should specify the expected behavior for networks w= ithout
> a relay.

I disagree. =A0This draft is only about a relay option. =A0There is n= o
change to servers or clients with this draft, except that a server may
use the additional information in the RELAY-FORW message.

> 2. Since the option will only appear in RELAY_FORWARD messages, what i= s the
> expected behavior for requests that are not forwarded by a relay? Are = there
> any implications to the fact that the information will not be in every=
> packet that the server receives from the client?

There is no required behavior change for clients or servers specified=
in this draft, therefore what you ask is out of scope. =A0This is no
different than Option82 in DHCPv4--if the information is missing or
the packet wasn't relayed, then the server can't use it to classify=
clients.

> 3. In section 4, how is the relay agent expected to obtain the client&= #39;s
> link-layer address? =A0Is the relay agent code required to be implemen= ted at
> layer 2? =A0Could it, for example, determine the LL address by
> reverse-engineering the client's EUI-64 link-local IPv6 address?
I could go along with additional text in Section 4 to specify that th= e
Relay Agent should insert the LL address of the IPv6 interface that is
being configured on the client. =A0How an implementation does that is an implementation detail and doesn't need to be specified here, but I
don't think EUI-64 can be relied upon to contain the proper client LL address in all cases.

> 4. If there is no relay, is the DHCPv6 server expected or required to<= br> > obtain this information itself? =A0If so, the same questions regarding= the
> layer-2 implementation requirements are probably applicable.

No, that functionality is out of scope for this draft. =A0A server co= uld
extract a LL address in the same way that a relay would, but that
behavior isn't specified.

I don't think we should block this draft in order to extend it to
specify how the server may acquire a client's LL address other than
via a RELAY-FORW message. =A0For the intended use cases as described in
Section 2, an operator can easily design their network to be sure that
all DHCPv6 traffic passes through a relay. =A0For the non-relayed case,
it would be much easier to modify an open source DHCPv6 server to
implement whatever behavior is wanted without affecting other parts of
the network--hence there is less need to standardize that behavior
through the IETF. =A0The Relay Agent option described in this draft does benefit from standardization since an agreed format for passing the
information from the Relay to the Server will need to be implemented
by many switch/router vendors as well as server software vendors.

If it is desired to specify additional client and/or server behavior
for other use cases such as non-relayed packets, I would prefer that
it be done in separate draft(s).

--000e0ce005fea08c3c04c765ea74-- From greg.rabil@jagornet.com Thu Aug 16 11:08:31 2012 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 2601A21F8487 for ; Thu, 16 Aug 2012 11:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E1sniaVIDwv for ; Thu, 16 Aug 2012 11:08:30 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2D221F847D for ; Thu, 16 Aug 2012 11:08:30 -0700 (PDT) Received: by bkty7 with SMTP id y7so1224203bkt.31 for ; Thu, 16 Aug 2012 11:08:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=336fbbsGf91n1fYBFNPMOekZuo6lhe7obi4mujAGtLQ=; b=fLGK5yAVyNUtPqGMv5lP/Rr+uHHif5+Q+0HflZCthIiX2jzUafDFSEhODPj3cN5TW1 2sFu7mZbdHv2KDhL1M0boK/rCCLEFkXhEQS2TdfdlbbxRBhAhRyXWKuVetxvsCLMJs/I 1lVOp30mlatJhJZf3cdP6aPffRoWz16bWBpWumGZmwSFrnGWEcBPkPb4iuP6ZXsAYP6a XHt7ddjHjPfj4NFbieIzc1aZygOsJzu6KWfoVSyMuHxKQo973nkVXm91rQ0sEDtPg1/Z 7v3qHseCJrv1Y/5UT7/nIgzn9fb+3LpDhDGmG4iiHEvOQ7ZsUV3AwChLsoIq+GDQj44j PJPQ== MIME-Version: 1.0 Received: by 10.204.148.78 with SMTP id o14mr1006685bkv.38.1345140509219; Thu, 16 Aug 2012 11:08:29 -0700 (PDT) Received: by 10.204.189.6 with HTTP; Thu, 16 Aug 2012 11:08:29 -0700 (PDT) In-Reply-To: <638607D0-D89C-4ED6-A3BF-FF2DECBF4D47@nominum.com> References: <10414435.125914.1345139460853.JavaMail.root@network1.net> <638607D0-D89C-4ED6-A3BF-FF2DECBF4D47@nominum.com> Date: Thu, 16 Aug 2012 14:08:29 -0400 Message-ID: From: "A. Gregory Rabil" To: Ted Lemon Content-Type: multipart/alternative; boundary=0015175cac2e3999fc04c765ee61 X-Gm-Message-State: ALoCoQk59iWKQCdTmsV38pUJcveN+vNaOL+97bV7dJU8VatXPkClpUi6WPuZHeKzS92/VaDzGQ/K Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 18:08:31 -0000 --0015175cac2e3999fc04c765ee61 Content-Type: text/plain; charset=ISO-8859-1 Good point, Ted. Maybe some text should be added to the draft to explain that this is the expected configuration? Greg On Thu, Aug 16, 2012 at 1:53 PM, Ted Lemon wrote: > On Aug 16, 2012, at 1:51 PM, perl-list wrote: > > Some of your other comments got me to thinking, however... On DHCPv4, the > client may start communicating directly with the DHCP server ignoring the > relay agent for renews (no idea if it is supposed to do that, but some do). > Is this the case in DHCPv6? Is it possible for the client to ignore the > relay agent and communicate directly with the DHCPv6 server on rebind? If > so, then this solution will only sort of work... > > > The client isn't allowed to do this unless it negotiates it with the > server, which presumably would say no in any environment where the > client-link-layer-address option was used. This was a deliberate design > decision in RFC3315, to deal with the exact problem you are talking about. > > --0015175cac2e3999fc04c765ee61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good point, Ted. =A0Maybe some text should be added to the draft to explain= that this is the expected configuration?

Greg

On Thu, Aug 16, 2012 at 1:53 PM, Ted Lemon <T= ed.Lemon@nominum.com> wrote:
On Aug 16, 2012, at 1:51 PM, perl-list wrote:
= Some of your other comments got me to thinking, however... =A0On DHCPv4, the cl= ient may start communicating directly with the DHCP server ignoring the rel= ay agent for renews (no idea if it is supposed to do that, but some do). = =A0Is this the case in DHCPv6? =A0Is it possible for the client to ignore the relay agent and communicate directly= with the DHCPv6 server on rebind? =A0If so, then this solution will only s= ort of work...

The client isn't allowed to do this unless it negotiates it = with the server, which presumably would say no in any environment where the= client-link-layer-address option was used. =A0 This was a deliberate desig= n decision in RFC3315, to deal with the exact problem you are talking about.


--0015175cac2e3999fc04c765ee61-- From dankney@network1.net Thu Aug 16 11:12:56 2012 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 EB97121F85C9 for ; Thu, 16 Aug 2012 11:12:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBROxx4ohSBR for ; Thu, 16 Aug 2012 11:12:55 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA6821F854B for ; Thu, 16 Aug 2012 11:12:54 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id BB1D7541104; Thu, 16 Aug 2012 14:12:49 -0400 (EDT) Date: Thu, 16 Aug 2012 14:12:49 -0400 (EDT) From: perl-list To: "A. Gregory Rabil" Message-ID: <285839446.126135.1345140769684.JavaMail.root@network1.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_126134_935061056.1345140769683" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 18:12:56 -0000 ------=_Part_126134_935061056.1345140769683 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Does not section 2 paragraph 4 scope the draft to relay forward messages? " Providing an option in DHCPv6 relay forward messages to carry client link-layer address explicitly will help above mentioned scenarios. " ----- Original Message ----- > From: "A. Gregory Rabil" > To: "Ted Lemon" > Cc: "perl-list" , "dhc WG" > Sent: Thursday, August 16, 2012 2:08:29 PM > Subject: Re: [dhcwg] WGLC: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > Good point, Ted. Maybe some text should be added to the draft to > explain that this is the expected configuration? > Greg > On Thu, Aug 16, 2012 at 1:53 PM, Ted Lemon < Ted.Lemon@nominum.com > > wrote: > > On Aug 16, 2012, at 1:51 PM, perl-list wrote: > > > > Some of your other comments got me to thinking, however... On > > > DHCPv4, > > > the client may start communicating directly with the DHCP server > > > ignoring the relay agent for renews (no idea if it is supposed to > > > do > > > that, but some do). Is this the case in DHCPv6? Is it possible > > > for > > > the client to ignore the relay agent and communicate directly > > > with > > > the DHCPv6 server on rebind? If so, then this solution will only > > > sort of work... > > > > > The client isn't allowed to do this unless it negotiates it with > > the > > server, which presumably would say no in any environment where the > > client-link-layer-address option was used. This was a deliberate > > design decision in RFC3315, to deal with the exact problem you are > > talking about. > ------=_Part_126134_935061056.1345140769683 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>
Does n=
ot section 2 paragraph 4 scope the draft to relay forward messages?<=
/pre>

"Providing an option in DHCPv6=
 relay forward messages to carry client
   link-layer address explicitly will help above mentioned scenarios."

From: "A. G= regory Rabil" <greg.rabil@jagornet.com>
To: "Ted Lemon" <= ;Ted.Lemon@nominum.com>
Cc: "perl-list" <perl-list@network1= .net>, "dhc WG" <dhcwg@ietf.org>
Sent: Thursday, August = 16, 2012 2:08:29 PM
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhc= pv6-client-link-layer-addr-opt-01

Good point, Ted.  Maybe some = text should be added to the draft to explain that this is the expected conf= iguration?

Greg

On Thu= , Aug 16, 2012 at 1:53 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Aug 16, 2012, at 1:51 PM, perl-list wrote:
Some of your other comments got me to thinking, however...  On DHCPv4, the= client may start communicating directly with the DHCP server ignoring the = relay agent for renews (no idea if it is supposed to do that, but some do).=  Is this the case in DHCPv6?  Is it possible for the client to ignore the relay agent and communicate directly= with the DHCPv6 server on rebind?  If so, then this solution will onl= y sort of work...

The client isn't allowed to do this unless it negotiates it with= the server, which presumably would say no in any environment where the cli= ent-link-layer-address option was used.   This was a deliberate design= decision in RFC3315, to deal with the exact problem you are talking about.



------=_Part_126134_935061056.1345140769683-- From cra@WPI.EDU Thu Aug 16 11:21:34 2012 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 8B14E21F854D for ; Thu, 16 Aug 2012 11:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zEKE2ja8TYG for ; Thu, 16 Aug 2012 11:21:33 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id B81FE21F85DF for ; Thu, 16 Aug 2012 11:21:33 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GILXve004101; Thu, 16 Aug 2012 14:21:33 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q7GILXve004101 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1345141293; bh=PosNaOWfEQ3eGMUTT9psKJr/aqKggwh82GciY862LaA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=s9NMXiaQUlhSOlV287kEdQUXN5TejGVQPVEy9rYbpDFYWU18Apd92niDL+IMA152H SWI9Rb329u41k/8zTKaPH02Dk5Rt+Icy6YvkeseuVDOcjeSddyh+qQNBDpejGUGLC/ 9FbZPoj7dQoWr2r6mo4piPUUt/JK9Iqdkjoxmd88= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GILXXD004098; Thu, 16 Aug 2012 14:21:33 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GILVod003106; Thu, 16 Aug 2012 14:21:32 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GILV3O028004; Thu, 16 Aug 2012 14:21:31 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id q7GILVS1028003; Thu, 16 Aug 2012 14:21:31 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 16 Aug 2012 14:21:30 -0400 From: Chuck Anderson To: Ted Lemon Message-ID: <20120816182130.GF4612@angus.ind.WPI.EDU> Mail-Followup-To: Ted Lemon , "A. Gregory Rabil" , dhc WG References: <20120816173740.GD4612@angus.ind.WPI.EDU> <0016C6A9-CD91-4A4C-8303-8A53A45C8AF4@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0016C6A9-CD91-4A4C-8303-8A53A45C8AF4@nominum.com> User-Agent: Mutt/1.5.20 (2009-12-10) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 18:21:34 -0000 On Thu, Aug 16, 2012 at 05:43:12PM +0000, Ted Lemon wrote: > Chuck, I think I can read your response as saying that you are happy with the draft as it is, and while you would not oppose having the draft say how the DHCP server might acquire the link local address for a packet that arrived without being relayed, you don't think it's necessary or desirable, correct? (I ask only so that we will know what to do later on when we evaluate consensus). I don't think it is necessary to update this draft to specify how a DHCP server might acquire the link layer address from a non-relayed packet, and I'm somewhat opposed to updating this particular draft for that behavior now only because it would add more delay. However, I do recognize that there may be benefit to updating section 4 to clarify what LL address is to be put into the RELAY-FORW option, but I'm open to others' opinions on this. Do others think this text is clear enough, or do we need to clarify what goes into the "client link-layer address option"? Right now it just doesn't say what goes in there: "4. DHCPv6 Relay Agent Behavior DHCPv6 Relay agents which are directly connected to clients/hosts MAY include client link-layer address option in relayed DHCPv6 (RELAY- FORW) message. The DHCPv6 Relay agent behaviour can depend on configuration that decides whether Client Link-layer Address option needs to be processed and included. In Relay chaining scenarios, any other relay agent other than first hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221] MUST not add this option." From dankney@network1.net Thu Aug 16 11:28:36 2012 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 5C28321F85D2 for ; Thu, 16 Aug 2012 11:28:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLg6smJHI67c for ; Thu, 16 Aug 2012 11:28:35 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD7E21F85D0 for ; Thu, 16 Aug 2012 11:28:35 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id C5E90541104; Thu, 16 Aug 2012 14:28:34 -0400 (EDT) Date: Thu, 16 Aug 2012 14:28:34 -0400 (EDT) From: perl-list To: Chuck Anderson Message-ID: <980012921.126182.1345141714682.JavaMail.root@network1.net> In-Reply-To: <20120816182130.GF4612@angus.ind.WPI.EDU> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_126181_597653420.1345141714681" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 18:28:36 -0000 ------=_Part_126181_597653420.1345141714681 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Is there something else that the link-layer address could be mis-construed as to referring to? Even after they read the section about how it is to be attached describing hardware type as specified in RFC? 3. DHCPv6 Client Link-layer Address Option The format of the DHCPv6 Client Link-layer Address option is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_CLIENT_LINKLAYER_ADDR | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hardware type (16 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | link-layer address (variable length) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_CLIENT_LINKLAYER_ADDR (TBD) option-length: 2 + length of link-layer address hardware type: Client Link-layer address type. The hardware type MUST be a valid hardware type assigned by the IANA, as described in [RFC0826] link-layer address: Client Link-layer address. ----- Original Message ----- > From: "Chuck Anderson" > To: "Ted Lemon" > Cc: "dhc WG" > Sent: Thursday, August 16, 2012 2:21:30 PM > Subject: Re: [dhcwg] WGLC: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > On Thu, Aug 16, 2012 at 05:43:12PM +0000, Ted Lemon wrote: > > Chuck, I think I can read your response as saying that you are > > happy with the draft as it is, and while you would not oppose > > having the draft say how the DHCP server might acquire the link > > local address for a packet that arrived without being relayed, you > > don't think it's necessary or desirable, correct? (I ask only so > > that we will know what to do later on when we evaluate consensus). > I don't think it is necessary to update this draft to specify how a > DHCP server might acquire the link layer address from a non-relayed > packet, and I'm somewhat opposed to updating this particular draft > for > that behavior now only because it would add more delay. > However, I do recognize that there may be benefit to updating section > 4 to clarify what LL address is to be put into the RELAY-FORW option, > but I'm open to others' opinions on this. Do others think this text > is clear enough, or do we need to clarify what goes into the "client > link-layer address option"? Right now it just doesn't say what goes > in there: > "4. DHCPv6 Relay Agent Behavior > DHCPv6 Relay agents which are directly connected to clients/hosts MAY > include client link-layer address option in relayed DHCPv6 (RELAY- > FORW) message. The DHCPv6 Relay agent behaviour can depend on > configuration that decides whether Client Link-layer Address option > needs to be processed and included. > In Relay chaining scenarios, any other relay agent other than first > hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221] MUST not add this > option." > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_126181_597653420.1345141714681 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>

3.  DHCPv6 Client Link= -layer Address Option

   The format of the DHCPv6 Client Link-layer Address option= is shown
&= nbsp;  below.
    0               &n= bsp;   1                  = ; 2                   3=
    0 1= 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OPTION_CLIENT_L= INKLAYER_ADDR  |           option-length &nbs= p;     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
   |    hardware type (16 bits)    |   =                      = ;       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     =                      = ;     |
   |               link= -layer address (variable length)            |=
  &nb= sp;|                     =                      = ;                     |
   = ;|                     &n= bsp;                     =                     |
   += -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   option-code:   =      OPTION_CLIENT_LINKLAYER_ADDR (TBD)
   option-length: &n= bsp;    2 + length of link-layer address
   hardware type:   =    Client Link-layer address type. The hardware type MUST be a
   =                    valid= hardware type assigned by the IANA, as described in [RFC0826]
=
   link-layer= address: Client Link-layer address.

=
From: "Chuck A= nderson" <cra@WPI.EDU>
To: "Ted Lemon" <Ted.Lemon@nominu= m.com>
Cc: "dhc WG" <dhcwg@ietf.org>
Sent: Thu= rsday, August 16, 2012 2:21:30 PM
Subject: Re: [dhcwg] WGLC: = ;       draft-ietf-dhc-dhcpv6-client-lin= k-layer-addr-opt-01

On Thu, Aug 16, 2012 at 05:43:12PM +0000, Ted Le= mon wrote:
> Chuck, I think I can read your response as saying that y= ou are happy with the draft as it is, and while you would not oppose having= the draft say how the DHCP server might acquire the link local address for= a packet that arrived without being relayed, you don't think it's necessar= y or desirable, correct?   (I ask only so that we will know what to do= later on when we evaluate consensus).

I don't think it is necessary= to update this draft to specify how a
DHCP server might acquire the lin= k layer address from a non-relayed
packet, and I'm somewhat opposed to u= pdating this particular draft for
that behavior now only because it woul= d add more delay.

However, I do recognize that there may be benefit = to updating section
4 to clarify what LL address is to be put into the R= ELAY-FORW option,
but I'm open to others' opinions on this.  Do oth= ers think this text
is clear enough, or do we need to clarify what goes = into the "client
link-layer address option"?  Right now it just doe= sn't say what goes
in there:

"4.  DHCPv6 Relay Agent Behavio= r

   DHCPv6 Relay agents which are directly connected to c= lients/hosts MAY
   include client link-layer address option i= n relayed DHCPv6 (RELAY-
   FORW) message.  The DHCPv6 Re= lay agent behaviour can depend on
   configuration that decide= s whether Client Link-layer Address option
   needs to be proc= essed and included.

   In Relay chaining scenarios, any ot= her relay agent other than first
   hop DHCPv6 Relay agent or = DHCPv6 LDRA [RFC6221] MUST not add this
   option."
_______= ________________________________________
dhcwg mailing list
dhcwg@iet= f.org
https://www.ietf.org/mailman/listinfo/dhcwg

------=_Part_126181_597653420.1345141714681-- From tomasz.mrugalski@gmail.com Thu Aug 16 11:36:05 2012 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 72C9521F853F for ; Thu, 16 Aug 2012 11:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIGdeI+TNybN for ; Thu, 16 Aug 2012 11:36:05 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9FC421F8532 for ; Thu, 16 Aug 2012 11:36:04 -0700 (PDT) Received: by eaai11 with SMTP id i11so903382eaa.31 for ; Thu, 16 Aug 2012 11:36:04 -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:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=kveQUt02D7FJxh8Ysr57Vxs9R5jrVhK586hRc4BUIUI=; b=aCP2vXqUSNH7I6o1wj1tdrXEcFtiX/ZpiyVPYFIculkwNePLHLz/w+kSfScqpjcWeq 0ifkZa7Kupg/JqCmHNR1IKt8Zt5cRWHp0Q54MMuMeYePPvYy/oHdC0Yza0sWH86f3pOh qwMw5EL/MWrEjFzb89PhuuHaFScUx4DcocrQhh+fRBRecxMGPB0t/swu13/g6u2DQlyT CNw2Qm5DDGQB4ty+Eqqaz2uc0DKIbk0Zqis3I7rrrnAbqYcbpRkRnG57FuMRKjEfD5br XTUKDikxyJWDg5g93L9pUCikkGeWVFsebSFoqABuIa97tRYKxo1O6lnVuckfheIPF9kB gLUg== Received: by 10.14.224.193 with SMTP id x41mr2871214eep.46.1345142163921; Thu, 16 Aug 2012 11:36:03 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:48db:4a00:b37:8b34? ([2001:470:6061:1:48db:4a00:b37:8b34]) by mx.google.com with ESMTPS id z3sm11772808eel.15.2012.08.16.11.36.02 (version=SSLv3 cipher=OTHER); Thu, 16 Aug 2012 11:36:03 -0700 (PDT) Message-ID: <502D3D90.5070907@gmail.com> Date: Thu, 16 Aug 2012 20:36:00 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <10414435.125914.1345139460853.JavaMail.root@network1.net> <20120816175534.GE4612@angus.ind.WPI.EDU> In-Reply-To: <20120816175534.GE4612@angus.ind.WPI.EDU> X-TagToolbar-Keys: D20120816203600277 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 18:36:05 -0000 On 16.08.2012 19:55, Chuck Anderson wrote: > No, DHCPv6 messages are always multicast and picked up by Relays (or > directly connected Servers). There is no such thing as unicast Renew > in DHCPv6. See section 22.12 of RFC3315. It will spoil the surprise a bit, but here's relevant quote: 22.12. Server Unicast Option The server sends this option to a client to indicate to the client that it is allowed to unicast messages to the server. There are clients and servers that take advantage of that option. In a properly implemented client, only RENEWs and RELEASEs (and possibly INFORMATION-REQUEST) are sent using unicast. Tomek From cra@WPI.EDU Thu Aug 16 12:09:50 2012 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 9234D21F86A3 for ; Thu, 16 Aug 2012 12:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydYsA3EBZQzx for ; Thu, 16 Aug 2012 12:09:50 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id CADBE21F8574 for ; Thu, 16 Aug 2012 12:09:49 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GJ9nDo031424 for ; Thu, 16 Aug 2012 15:09:49 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q7GJ9nDo031424 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1345144189; bh=7dxkOa/DVLz+knze6ckD9q2CV73QxU7/Rnm54jcwM9Y=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=bqFCpCIbeJJ2667zWDrLgdAu/2bMxltuuGKDL7gGQYvQC1qP474stTeQBMi9pMc3B fH5/6fOwqiM9BgnD9/FW+bdj4qQ/IE8KGbjBn8FYFR+yO96IGHF/DxdruLHJvlB9QK qn5lIssJJVeU7NtWqyy2Z95+8NsG5+hvrVmVswMg= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GJ9mpH031417 for ; Thu, 16 Aug 2012 15:09:49 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GJ8Zk5010922 for ; Thu, 16 Aug 2012 15:08:36 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GJ8ZF1029177 for ; Thu, 16 Aug 2012 15:08:35 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id q7GJ8ZiB029176 for dhcwg@ietf.org; Thu, 16 Aug 2012 15:08:35 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 16 Aug 2012 15:08:35 -0400 From: Chuck Anderson To: dhcwg@ietf.org Message-ID: <20120816190834.GH4612@angus.ind.WPI.EDU> Mail-Followup-To: dhcwg@ietf.org References: <10414435.125914.1345139460853.JavaMail.root@network1.net> <20120816175534.GE4612@angus.ind.WPI.EDU> <502D3D90.5070907@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <502D3D90.5070907@gmail.com> User-Agent: Mutt/1.5.20 (2009-12-10) Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 19:09:50 -0000 On Thu, Aug 16, 2012 at 08:36:00PM +0200, Tomek Mrugalski wrote: > On 16.08.2012 19:55, Chuck Anderson wrote: > > No, DHCPv6 messages are always multicast and picked up by Relays (or > > directly connected Servers). There is no such thing as unicast Renew > > in DHCPv6. > See section 22.12 of RFC3315. It will spoil the surprise a bit, but > here's relevant quote: > > 22.12. Server Unicast Option > The server sends this option to a client to indicate to the client > that it is allowed to unicast messages to the server. > > There are clients and servers that take advantage of that option. In a > properly implemented client, only RENEWs and RELEASEs (and possibly > INFORMATION-REQUEST) are sent using unicast. Thanks, I stand corrected. The default behavior in the absence of the Server Unicast Option is as I stated, and as Ted pointed out you can just be sure to not set this option to be sure that multicast/relay is always used. From dankney@network1.net Thu Aug 16 12:18:00 2012 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 8D3D421F85D0 for ; Thu, 16 Aug 2012 12:18:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33utJUcewaVJ for ; Thu, 16 Aug 2012 12:18:00 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id D8DAC21F85CD for ; Thu, 16 Aug 2012 12:17:59 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id F0BF6541109; Thu, 16 Aug 2012 15:17:58 -0400 (EDT) Date: Thu, 16 Aug 2012 15:17:58 -0400 (EDT) From: perl-list To: Chuck Anderson Message-ID: <197756214.126364.1345144678879.JavaMail.root@network1.net> In-Reply-To: <20120816190834.GH4612@angus.ind.WPI.EDU> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_126363_1265860549.1345144678878" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 19:18:00 -0000 ------=_Part_126363_1265860549.1345144678878 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Here is to hoping that ISC DHCP implements such a keyword to not allow unicast. ----- Original Message ----- > From: "Chuck Anderson" > To: dhcwg@ietf.org > Sent: Thursday, August 16, 2012 3:08:35 PM > Subject: Re: [dhcwg] WGLC: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > On Thu, Aug 16, 2012 at 08:36:00PM +0200, Tomek Mrugalski wrote: > > On 16.08.2012 19:55, Chuck Anderson wrote: > > > No, DHCPv6 messages are always multicast and picked up by Relays > > > (or > > > directly connected Servers). There is no such thing as unicast > > > Renew > > > in DHCPv6. > > See section 22.12 of RFC3315. It will spoil the surprise a bit, but > > here's relevant quote: > > > > 22.12. Server Unicast Option > > The server sends this option to a client to indicate to the client > > that it is allowed to unicast messages to the server. > > > > There are clients and servers that take advantage of that option. > > In a > > properly implemented client, only RENEWs and RELEASEs (and possibly > > INFORMATION-REQUEST) are sent using unicast. > Thanks, I stand corrected. The default behavior in the absence of the > Server Unicast Option is as I stated, and as Ted pointed out you can > just be sure to not set this option to be sure that multicast/relay > is > always used. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_126363_1265860549.1345144678878 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>
Here is to hop= ing that ISC DHCP implements such a keyword to not allow unicast.

=
From: "Chuck Anderson" <cra@WPI.EDU>
To: d= hcwg@ietf.org
Sent: Thursday, August 16, 2012 3:08:35 PM
Su= bject: Re: [dhcwg]        WGLC:=         draft-ietf-dhc-dhcpv6-clien= t-link-layer-addr-opt-01

On Thu, Aug 16, 2012 at 08:36:00PM +0200, T= omek Mrugalski wrote:
> On 16.08.2012 19:55, Chuck Anderson wrote:> > No, DHCPv6 messages are always multicast and picked up by Relays= (or
> > directly connected Servers).  There is no such thing= as unicast Renew
> > in DHCPv6.
> See section 22.12 of RFC3= 315. It will spoil the surprise a bit, but
> here's relevant quote:>
> 22.12. Server Unicast Option
>    The serve= r sends this option to a client to indicate to the client
>   &n= bsp;that it is allowed to unicast messages to the server.
>
> = There are clients and servers that take advantage of that option. In a
&= gt; properly implemented client, only RENEWs and RELEASEs (and possibly
= > INFORMATION-REQUEST) are sent using unicast.

Thanks, I stand co= rrected.  The default behavior in the absence of the
Server Unicast= Option is as I stated, and as Ted pointed out you can
just be sure to n= ot set this option to be sure that multicast/relay is
always used.
__= _____________________________________________
dhcwg mailing list
dhcw= g@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


------=_Part_126363_1265860549.1345144678878-- From cra@WPI.EDU Thu Aug 16 12:38:48 2012 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 2727A21F869F for ; Thu, 16 Aug 2012 12:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXVOdc4VKbqv for ; Thu, 16 Aug 2012 12:38:47 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 51C3A21F8620 for ; Thu, 16 Aug 2012 12:38:47 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GJckOU023210; Thu, 16 Aug 2012 15:38:46 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q7GJckOU023210 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1345145926; bh=7o31UXX3GyN4xvfujxthejBTjCkjxa367CNQXUnIrW4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=n9NrpNqbdQFwB4RXQg8SE0baFSMf1MYKf6zVDPlZMI6qpOBSo5sEfXX+LwCWj/ADZ hRDzK9nrpLkRD6Xb+/zYOvSLEi9mIYWviDt0wbn+v0Y65wb61+aLNkfec7u9vUw0hE YWvkU2cjUVISoH7VQJj1rVw/Dz+KMuHrF6LWBFiY= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7GJckcg023207; Thu, 16 Aug 2012 15:38:46 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GJcitB017820; Thu, 16 Aug 2012 15:38:45 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7GJcitG029833; Thu, 16 Aug 2012 15:38:44 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id q7GJcic0029832; Thu, 16 Aug 2012 15:38:44 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 16 Aug 2012 15:38:44 -0400 From: Chuck Anderson To: perl-list Message-ID: <20120816193843.GI4612@angus.ind.WPI.EDU> Mail-Followup-To: perl-list , dhcwg@ietf.org References: <20120816190834.GH4612@angus.ind.WPI.EDU> <197756214.126364.1345144678879.JavaMail.root@network1.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <197756214.126364.1345144678879.JavaMail.root@network1.net> User-Agent: Mutt/1.5.20 (2009-12-10) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 19:38:48 -0000 There is no need. The default is to disallow unicast. You only need a server to implement the Server Unicast Option if you WANT to receive unicast renews. ISC already provides such an option: >From dhcp-options(5): "option dhcp6.unicast ip6-address; The unicast option is provided by DHCPv6 servers which are willing (or prefer) to receive Renew packets from their clients by exchanging UDP unicasts with them. Normally, DHCPv6 clients will multicast their Renew messages. This may be configured on the server, and should be configured as an address the server is ready to reply to." >From RFC3315 Section 22.12: "A DHCP server rejects any messages sent inappropriately using unicast to ensure that messages are relayed by Relay Agents when Relay Agent options are in use. Details about when the client may send messages to the server using unicast are in section 18." Section 18.1: "If the client has a source address of sufficient scope that can be used by the server as a return address, and the client has received a Server Unicast option (section 22.12) from the server, the client SHOULD unicast any Request, Renew, Release and Decline messages to the server. DISCUSSION: Use of unicast may avoid delays due to the relaying of messages by relay agents, as well as avoid overhead and duplicate responses by servers due to the delivery of client messages to multiple servers. Requiring the client to relay all DHCP messages through a relay agent enables the inclusion of relay agent options in all messages sent by the client. The server should enable the use of unicast only when relay agent options will not be used." "18.2.1. Receipt of Request Messages When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options." "18.2.3. Receipt of Renew Messages When the server receives a Renew message via unicast from a client to which the server has not sent a unicast option, the server discards the Renew message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options." "18.2.6. Receipt of Release Messages When the server receives a Release message via unicast from a client to which the server has not sent a unicast option, the server discards the Release message and responds with a Reply message containing a Status Code option with value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options." "18.2.7. Receipt of Decline Messages When the server receives a Decline message via unicast from a client to which the server has not sent a unicast option, the server discards the Decline message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options." On Thu, Aug 16, 2012 at 03:17:58PM -0400, perl-list wrote: > Here is to hoping that ISC DHCP implements such a keyword to not allow unicast. > ----- Original Message ----- > > > From: "Chuck Anderson" > > To: dhcwg@ietf.org > > Sent: Thursday, August 16, 2012 3:08:35 PM > > Subject: Re: [dhcwg] WGLC: > > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > > > On Thu, Aug 16, 2012 at 08:36:00PM +0200, Tomek Mrugalski wrote: > > > On 16.08.2012 19:55, Chuck Anderson wrote: > > > > No, DHCPv6 messages are always multicast and picked up by Relays > > > > (or > > > > directly connected Servers). There is no such thing as unicast > > > > Renew > > > > in DHCPv6. > > > See section 22.12 of RFC3315. It will spoil the surprise a bit, but > > > here's relevant quote: > > > > > > 22.12. Server Unicast Option > > > The server sends this option to a client to indicate to the client > > > that it is allowed to unicast messages to the server. > > > > > > There are clients and servers that take advantage of that option. > > > In a > > > properly implemented client, only RENEWs and RELEASEs (and possibly > > > INFORMATION-REQUEST) are sent using unicast. > > > Thanks, I stand corrected. The default behavior in the absence of the > > Server Unicast Option is as I stated, and as Ted pointed out you can > > just be sure to not set this option to be sure that multicast/relay > > is > > always used. From Ted.Lemon@nominum.com Thu Aug 16 12:38:50 2012 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 3133021F86A1 for ; Thu, 16 Aug 2012 12:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeDsjzDzn9Tm for ; Thu, 16 Aug 2012 12:38:49 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 48D7021F8620 for ; Thu, 16 Aug 2012 12:38:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUC1MSEpqcOz+9A8euZ9OLBq4GMe+RD8u@postini.com; Thu, 16 Aug 2012 12:38: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 7672B1B8313 for ; Thu, 16 Aug 2012 12:38:48 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 6BBA1190052; Thu, 16 Aug 2012 12:38:48 -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.02.0247.003; Thu, 16 Aug 2012 12:38:48 -0700 From: Ted Lemon To: Chuck Anderson Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 Thread-Index: AQHNe7jBKYqvqlvJTk2cfeufL7tTPJddHfOAgAALoQCAAAGIgIAACrQAgAAVlwA= Date: Thu, 16 Aug 2012 19:38:48 +0000 Message-ID: References: <20120816173740.GD4612@angus.ind.WPI.EDU> <0016C6A9-CD91-4A4C-8303-8A53A45C8AF4@nominum.com> <20120816182130.GF4612@angus.ind.WPI.EDU> In-Reply-To: <20120816182130.GF4612@angus.ind.WPI.EDU> 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: multipart/alternative; boundary="_000_EB1C78CCB39E49CFBD91E9B141EFA041nominumcom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 16 Aug 2012 19:38:50 -0000 --_000_EB1C78CCB39E49CFBD91E9B141EFA041nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 16, 2012, at 2:21 PM, Chuck Anderson wrote: "4. DHCPv6 Relay Agent Behavior DHCPv6 Relay agents which are directly connected to clients/hosts MAY include client link-layer address option in relayed DHCPv6 (RELAY- FORW) message. The DHCPv6 Relay agent behaviour can depend on configuration that decides whether Client Link-layer Address option needs to be processed and included. In Relay chaining scenarios, any other relay agent other than first hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221] MUST not add this option." Could say: DHCPv6 Relay agents which receive messages originating from clients (for ex= ample Solicit and Request, but not, for example, Relay Forward or Advertise= ) MAY include the link-layer source address of the received message in rela= yed DHCPv6 Relay Forward messages. The DHCPv6 Relay agent behavior can dep= end on configuration that decides whether Client Link-layer Address option = needs to be processed and included. This makes it clear where the link layer address is coming from. As an ad= ded bonus, there's no need to mention LDRAs or intermediary relays, since R= elay Forward messages are specifically excluded. --_000_EB1C78CCB39E49CFBD91E9B141EFA041nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 16, 2012, at 2:21 PM, Chuck Anderson wrote:
"4.  DHCPv6 Relay Agent Behavior

  DHCPv6 Relay agents which are directly connected to clients/hos= ts MAY
  include client link-layer address option in relayed DHCPv6 (REL= AY-
  FORW) message.  The DHCPv6 Relay agent behaviour can depen= d on
  configuration that decides whether Client Link-layer Address op= tion
  needs to be processed and included.

  In Relay chaining scenarios, any other relay agent other than f= irst
  hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221] MUST not add th= is
  option."

Could say:

DHCPv6 Relay agents which receive messages originating from clients (f= or example Solicit and Request, but not, for example, Relay Forward or Adve= rtise) MAY include the link-layer source address of the received messa= ge in relayed DHCPv6 Relay Forward messages.  The DHCPv6 Relay agent behavior can depend on configuration tha= t decides whether Client Link-layer Address option needs to be process= ed and included.

This makes it clear where the link layer address is coming from.  = ; As an added bonus, there's no need to mention LDRAs or intermediary relay= s, since Relay Forward messages are specifically excluded.

--_000_EB1C78CCB39E49CFBD91E9B141EFA041nominumcom_-- From d3e3e3@gmail.com Thu Aug 16 20:12:47 2012 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 D420421F84B5 for ; Thu, 16 Aug 2012 20:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmFaLcdewpq6 for ; Thu, 16 Aug 2012 20:12:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C854921F84B2 for ; Thu, 16 Aug 2012 20:12:46 -0700 (PDT) Received: by yenm5 with SMTP id m5so3970509yen.31 for ; Thu, 16 Aug 2012 20:12: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=OmSP61TRdIxZ+Uxf6THTdKT6viMxGmIPke8C8/mg/ro=; b=EshcOQbpd+dOjTUYe9oqhGi/b6/y165LF58avjwLnOnm+d3QKmQjaP5XLKV0ZlSkDw +/IbTOv/0b/1F9YXDF8ErXQWxXsmKmb96dAjLdDtTf0938OOwJCu+SSyVKtMPE2S0nHv mt0QiPGeDu7m08HZiqseuhePu+veyRKnni/1XyH0BuOuFX++P/SBIgchRZ6UX0McAzU/ +kO8t3Q8yjgnNqKPggTJ1l6cLgAB6e7RFMBbMFAvPW0fLnNx9B/hXIDc0WgmNGXt3xLM VhNe4moE973oZb+cmwXGz04I6Ut8lPMAaXySFeSVQ+XYrV7WAcov8h/ENBQo+0Exxcra +IZw== Received: by 10.50.180.169 with SMTP id dp9mr390491igc.8.1345173165711; Thu, 16 Aug 2012 20:12:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.15.6 with HTTP; Thu, 16 Aug 2012 20:12:25 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F067D3@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F066A2@szxeml545-mbx.china.huawei.com> <0E81DDB0-29DA-4B8F-A336-FDE9FDA663D2@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F067D3@szxeml545-mbx.china.huawei.com> From: Donald Eastlake Date: Thu, 16 Aug 2012 23:12:25 -0400 Message-ID: To: Sheng Jiang Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dhc WG , Ted Lemon , "Bernie Volz \(volz\)" , Andre Kostur Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 17 Aug 2012 03:12:47 -0000 I support the concept behind this draft and think that the requirements and text can be clarified to answer most objections. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Aug 15, 2012 at 11:48 PM, Sheng Jiang wrote= : > Hi, Bernie and Andre > > Thanks for your comments. Actually, we are quite open to discuss. The onl= y reason we request WGLC is there is no any discussion for this draft for l= ast 12 months and we have addressed all comments we received. > > Since you have raised new discussion, we are happy to delay the process t= ill all open issues get addressed. This is good for our work to be real mat= ure. :) > > See my reply in lines. > > Sheng > >>What about the other things RAs provide? Such as the routers and on-link >>notification ... Are RAs active in these networks or not? > > This work does NOT replace neighbor discovery. RA is active in our target= network. ND is mainly for reachability/routing purpose. > > This work is to make the address configuration all by DHCPv6, rather than= part by RA, part by DHCPv6. With the assumption that DHCPv6 takes over all= address configuration, assigning 128-bit address is insufficient. Some hos= t want to use self-generated address, CGA is only one example, others inclu= ding EUI64 and privacy address. > > This work is a generic prefix assignment/announcement mechanism. It is al= ternative of RA prefix assignment/announcement. > > > draft-ietf-dhc-secure-dhcpv6 is nothing to do with address configuration.= It is AFTER CGA addresses generated, using them to protect DHCPv6 message = exchanging. > > draft-ietf-dhc-cga-config-dhcpv6 is specific CGA configuration. Since we = separated prefix assignment to be this generic mechanism, that draft is onl= y focusing on CGA approve process. However, if the discussion think prefix = assignment is only meaningful for CGA, we have no problem to combine this b= ack to CGA configuration draft. > > Let's first discuss the requirement/problem first. We can come back to te= chnical details later. > > Regards, > > Sheng > >>Also how is the client's assignment of addresses considered >>DHCPv6-managed? >> >>How is this any different from stateless? >> >>The only difference with this over normal stateless is that you could giv= e each >>client its own prefix, whereas RAs are sent to all devices on the link. B= ut I >>don't recall the document mentioning such a network (and in some cases >>where this might occur, usually there are tunnels involved and protocols = such >>as ppp). And you would have to describe such a network and explain why RS= s >>and RAs are insufficent or not usuable/pratical. >> >>When the working group adopts a document to work on, that does not mean >>it will necessarily advance. Sometimes not all of the issues are well >>understood early in the process. There are other cases where it can take = many >>years to work out the details and address the concerns before the documen= t >>is ready. The process can be frustrating and demotivating. But the result= is >>usually for the best. >> >>Also, as CGAs are mentioned as one possible usage model, I think it would >>again be important to understand why the other works in this area >>(draft-ietf-dhc-cga-config-dhcpv6 and draft-ietf-dhc-secure-dhcpv6) are n= ot >>appropriate or do not cover all of the requirements - and it might be wor= th >>considering working with those authors? Note also that in normal DHCPv6, >>clients may request explicit addresses and so using CGA addresses via DHC= Pv6 >>isn't impossible (some servers do require a range of addresses to be >>configured just like for v4, but I consider that approach to limit what v= 6 has to >>offer -- the server I work on does not have this restriction). >> >>I can agree with you that the world isn't as simple as we would like - th= ere are >>plenty of devices that only support stateless and this makes running a "f= ully" >>DHCPv6 managed network where you don't have total control of the devices >>that may connect impossible. But building more complexity and choices int= o >>DHCPv6 hardly seems like the a good approach to solving this since it wil= l be >>even longer before all of the devices support these new configuration mod= els >>- or some may chose not to implement DHCPv6 at all. >> >>Anyway, if I haven't said it before or it isn't yet clear, I have serious= objections >>to advancing this work in its current form and given its current motivati= on. If >>the rational for needing these capabilities and how they are used between >>clients, relays, and servers and the network are explained, I will be hap= py to >>remove my objections. >> >>- Bernie >> >>On Aug 15, 2012, at 9:08 PM, "Andre Kostur" >>wrote: >> >>> Leaving aside the issue of whether this "prefix announcement" should >>> be carried over DHCPv6, I wonder if trying to fit this into an >>> Identity Association isn't quite right since there is no identity to >>> be managed? Perhaps a cleaner solution would be for the device to >>> ask for an IAPREFIX in an ORO in an Information-Request, and the >>> server can reply with an IAPREFIX (that isn't in any IA_* option). >>> >>> Having said that, I'm with Ted in that I don't quite grasp why we're >>> trying to do this. It the network is "fully DHCPv6-managed", wouldn't >>> that mean that the administrators would want to control the address >>> generation instead of leaving it up to the client to do with it as it >>> will? >>> >>> On Wed, Aug 15, 2012 at 5:49 PM, Sheng Jiang >>wrote: >>>> >>>> Hi, Bernie, >>>> >>>> >>>> >>>> Thanks for your comments. See my reply in lines. >>>> >>>> >>>> >>>> Sheng >>>> >>>> >>>> >>>> I=92d also suggest the following be clarified (section 4, bullet 2): >>>> >>>> >>>> >>>> If there is not a proper prefix available, a status- >>>> >>>> code is returned to the host and the procedure is terminated. >>>> >>>> >>>> >>>> What status code and where is this status code returned. Let=92s hope = it >>>> follows the IA_PD conventions (especially if we keep the IAID in the I= A_PA). >>>> There is no new status code requested, do apparently it is one of the >>>> existing codes (RFC 3315/3633)? >>>> >>>> >>>> >>>> It is the existing NoPrefixAvail status code, defined in RFC 3= 633. >>>> I have just added an explicit explanation for this. >>>> >>>> >>>> >>>> >>>> >>>> This work also seems to be to replacing Router Solicitation/Router >>>> Advertisement messages to advertise the prefixes (for stateless >>>> autoconfiguration). Do we really want this. And, might not this be >>something >>>> to discuss in a slightly wider IETF audience. Perhaps it has already b= een (I >>>> haven=92t followed this work that closely). >>>> >>>> >>>> >>>> It is the assumption we take. I believe we had the WG consensu= s, >>>> by adopting as WG document. Because this only happens in a fully >>>> DHCPv6-managed network, does not impact any other network that use >>RA for >>>> SLACC, so I think discussion in DHC is enough. >>> >>> -- >>> Andre Kostur >>> _______________________________________________ >>> 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 From sthaug@nethelp.no Fri Aug 17 00:25:52 2012 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 4BEE811E809C for ; Fri, 17 Aug 2012 00:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR2ylab+FiVS for ; Fri, 17 Aug 2012 00:25:51 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 4F8B821F8493 for ; Fri, 17 Aug 2012 00:25:50 -0700 (PDT) Received: (qmail 40942 invoked from network); 17 Aug 2012 07:25:48 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 Aug 2012 07:25:48 -0000 Date: Fri, 17 Aug 2012 09:25:48 +0200 (CEST) Message-Id: <20120817.092548.74713566.sthaug@nethelp.no> To: Ted.Lemon@nominum.com From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 17 Aug 2012 07:25:52 -0000 > The authors of this document have requested a working group last call. There's already been some good review on the list, but more is always welcome. Please post comments if you have any, and also indicate whether you support advancing the draft as written, or oppose doing so. We will evaluate consensus on August 31. I support this document going forward as is. It adds an important tool to the DHCPv6 toolbox. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From shemant@cisco.com Fri Aug 17 08:46:57 2012 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 CC5BA21F8510 for ; Fri, 17 Aug 2012 08:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68LkmsIKuGvE for ; Fri, 17 Aug 2012 08:46:57 -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 F3CB721F84CD for ; Fri, 17 Aug 2012 08:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2581; q=dns/txt; s=iport; t=1345218417; x=1346428017; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RcpjVL8xCxhZVZkGx527ulg7YV3Yh1aX7U6xSgS/wEw=; b=gIdEIfz6flaA7AC4ii/OD8FlcBQ7Az/OpRLPQFlDCp/BZVWXyDB0CINx PR1Td/wMvkrxmzsaLhgyY5qTEqGoBbVVmqoJ40Q+Lqx2Fj73kWKppUleX 5mNby3ELpg76nBYxS+nROQQ//RS+ghlTXuzg7G/rOwEJKMILQf+jKnXid c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANVmLlCtJV2b/2dsb2JhbABABbo9gQeCIAEBAQQBAQEPASc0BBMEAgEIEQQBAQsUCQcnCxQJCAIEARIIEweFb4F8C5lvoEYEiwsohXNgA6N7gWaCYIFaBxw X-IronPort-AV: E=Sophos;i="4.77,785,1336348800"; d="scan'208";a="112470519" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 17 Aug 2012 15:46:56 +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 q7HFkuVY007920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Aug 2012 15:46:56 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Fri, 17 Aug 2012 10:46:56 -0500 From: "Hemant Singh (shemant)" To: Ted Lemon , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpddHmiAgAAVWYCAAPpygA== Date: Fri, 17 Aug 2012 15:46:55 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89071546@xmb-rcd-x06.cisco.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> <5AAE3B81-ABDE-49AF-BD14-C5307EC7CA7E@nominum.com> In-Reply-To: <5AAE3B81-ABDE-49AF-BD14-C5307EC7CA7E@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.175.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19120.005 x-tm-as-result: No--30.002000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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: Fri, 17 Aug 2012 15:46:57 -0000 +1 to Wes' comment that this document is addressing a very important proble= m space and the solutions are needed urgently. However, more thought is re= quired for the solutions. In regards to section 4.4, if the server only checks the network configurat= ion to reply to a Confirm message, how is it possible for most network conf= igurations that the server determines an IA_PD is on-link? I suspect that= is why RFC 3633 prohibited use of the Confirm for the IA_PD. In any case = this document should explain why did RFC 3633 have a restriction on using t= he Confirm for the IA_PD. Or does network configuration include looking up= the prefix pool configured on the server for allocation? In contrast, to = make an on-link determination for an IA_NA IA_Address, all the server has t= o do is match (longest-prefix match) all IPv6 addresses configured on the m= achine that the server is running on. These addresses are clearly network = configuration.=20 Section 4.1: =20 # In relation to the first paragraph the document is addressing the fact th= at one server replies with, say, an IA_NA, while another server replies bac= k with only the IA_PD. Then why in section 4.7 the case of section 4.1 is= deemed out of scope? I also do not understand what does "equal" in secti= on 4.7 mean. Does it mean each server replies with all IAs that the deploy= ment needs? # In relation to the text in the last paragraph of section 4.1, if the clie= nt does not restart the Solicit retransmissions timers, what does the clien= t do? # Other comment: Shouldn't the header of the document have an Updates tag = to signify this document updates RFC 3315? Thanks, Hemant -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Thursday, August 16, 2012 1:38 PM To: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 One other question about this draft: it proposes extending the Confirm mess= age to stateful options other than IA_NA. Presumably, the option we're mo= st interested in is IA_PD, but how would a DHCP server without access to th= e client binding state know that a PD was valid? Are we talking about a s= cenario like Leaf Yeh's prefix pool option, whether the server simply valid= ates that the proposed prefixes are within the pool that is assigned to the= specific PE router? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From sunqi.thu@gmail.com Sat Aug 18 19:38:33 2012 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 8CD8521F8472 for ; Sat, 18 Aug 2012 19:38:33 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac+GFI+ip82k for ; Sat, 18 Aug 2012 19:38:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1501E21F846F for ; Sat, 18 Aug 2012 19:38:33 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5499372pbb.31 for ; Sat, 18 Aug 2012 19:38:32 -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:x-mailer; bh=w/2esSbRJw+QC93IH4GWFQNKP9Gxw+jkuaWPh1aY32I=; b=hgO0XBCfnEfdGrhZltKW1YArmpQIbBYu4PwCPO8twR84uviV3ifT8sEGbf/bVWO+0+ yG2R7H1LAk6NsMq49zlXknHfRUXtpLKIUvHJTzcBIQil04Jcm35oPfyBaeVvWHx9Yc3C XzrKg43Nb2nMH7ufE6ZlU5y8MlvXFELDz51b9vRhZxL6TL9Z/hqr4MT6v44mUVwPobW5 E4ngRKYfxxhOdgUMCmFLDroq7pLthmO4RGmnm0wVbdmoccn3yn37bQUS07S97bcipLNE MAyLLd9p/7GSpCs2TBw6MhnwVnrh5w/J6hWpT449nEAWHWTNtZbJeTqo1Who5tVNpc94 SN4g== Received: by 10.68.242.231 with SMTP id wt7mr18480299pbc.99.1345343912578; Sat, 18 Aug 2012 19:38:32 -0700 (PDT) Received: from [192.168.0.100] ([123.130.137.73]) by mx.google.com with ESMTPS id vh7sm8126381pbc.22.2012.08.18.19.38.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 18 Aug 2012 19:38:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: sunqi In-Reply-To: <4D779082-B182-4728-9534-39456573682E@nominum.com> Date: Sun, 19 Aug 2012 10:38:21 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D779082-B182-4728-9534-39456573682E@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-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: Sun, 19 Aug 2012 02:38:33 -0000 I support the draft moving forward. Best Regards! Qi Sun On 2012-8-10, at 8:42, Ted Lemon wrote: > The authors of this draft have requested a working group last call. = The draft explains how DHCP clients operate in an environment where the = interface being configured doesn't support multicast (e.g., 6RD). If = this is a matter of interest to you, please review the draft and send = comments to the list. >=20 > If you are in favor of advancing the draft, please say so on the list; = if nobody supports it, it won't advance. If you oppose advancing it, = please also say so. We will determine consensus on August 24. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From cra@WPI.EDU Sat Aug 18 20:35:18 2012 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 62D1121F8468 for ; Sat, 18 Aug 2012 20:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRkc+xAiZ2MY for ; Sat, 18 Aug 2012 20:35:17 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 334B821F845C for ; Sat, 18 Aug 2012 20:35:17 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7J3ZGYm032387; Sat, 18 Aug 2012 23:35:16 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q7J3ZGYm032387 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1345347316; bh=Uno4pOri7aT01foHnCGqFC5IW8iUOM7wHpWSknP4L2o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=bbqunJOpa1MagEJqFo97I1w/g7tApzJiK09/SROldtpIXEl9zwn7WA1PrHx8A2mOY YtGN69bB/8jU0Sc10q/XcIANw1G5PfBlvxMtVs2TBdm1bDZNKmWR6VAIgvqyI40xR9 qP2D7Qa+4VSX1/IWjubQ1IYMnSEY/QPBrLLXA5ic= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q7J3ZGkA032384; Sat, 18 Aug 2012 23:35:16 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7J3ZESa007411; Sat, 18 Aug 2012 23:35:15 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id q7J3ZEsn005294; Sat, 18 Aug 2012 23:35:14 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id q7J3ZDa8005293; Sat, 18 Aug 2012 23:35:13 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Sat, 18 Aug 2012 23:35:13 -0400 From: Chuck Anderson To: Ted Lemon Message-ID: <20120819033513.GA21200@angus.ind.WPI.EDU> Mail-Followup-To: Ted Lemon , "A. Gregory Rabil" , dhc WG References: <20120816173740.GD4612@angus.ind.WPI.EDU> <0016C6A9-CD91-4A4C-8303-8A53A45C8AF4@nominum.com> <20120816182130.GF4612@angus.ind.WPI.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 19 Aug 2012 03:35:18 -0000 On Thu, Aug 16, 2012 at 07:38:48PM +0000, Ted Lemon wrote: > On Aug 16, 2012, at 2:21 PM, Chuck Anderson wrote: > "4. DHCPv6 Relay Agent Behavior > > DHCPv6 Relay agents which are directly connected to clients/hosts MAY > include client link-layer address option in relayed DHCPv6 (RELAY- > FORW) message. The DHCPv6 Relay agent behaviour can depend on > configuration that decides whether Client Link-layer Address option > needs to be processed and included. > > In Relay chaining scenarios, any other relay agent other than first > hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221] MUST not add this > option." > > Could say: > > DHCPv6 Relay agents which receive messages originating from clients > (for example Solicit and Request, but not, for example, Relay > Forward or Advertise) MAY include the link-layer source address of > the received message in relayed DHCPv6 Relay Forward messages. > The DHCPv6 Relay agent behavior can depend on configuration that > decides whether Client Link-layer Address option needs to be > processed and included. I agree that this text would be good to replace the existing text in section 4. > > This makes it clear where the link layer address is coming from. As an added bonus, there's no need to mention LDRAs or intermediary relays, since Relay Forward messages are specifically excluded. Agreed. From ichiroumakino@gmail.com Mon Aug 20 02:02:06 2012 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 9AB2C21F86C5 for ; Mon, 20 Aug 2012 02:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFBoPvini1OC for ; Mon, 20 Aug 2012 02:02:05 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 633B721F869E for ; Mon, 20 Aug 2012 02:02:05 -0700 (PDT) Received: by eaai11 with SMTP id i11so1766862eaa.31 for ; Mon, 20 Aug 2012 02:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=4DEFVqgHGS4d/V99seWyMuB+XckYP/J7zNGIuaV40k0=; b=Kw+yH4f2TeeGXUrYCDIy+IcJm/frLO731lHhvl7wH2+k9xsxzDfw9xGE7YrtcHu1vN sJ+Iq3g1eWlM0hf8VEfn+6ygQyTlA3d523aR5opothTeAPQCQg0K5ETu8bnpdNGHGMR7 Q/xGdbHILlujVI8YJLglpsPeOkOSYyrY5Xj1it27YnNre3+rmHIuO+3qoX1CEI2Ki1nz KfP20pdnfAnqYjaCS105JxetJnJP8vzjbNR/A2X8/EvzTN8Y9m4L8YOfUp0RcoPtules auxvtMCj78CwPOgHxmSidh8z30FRwNLJoQYUzZZvBYxgXh3LML82+7IK+rMhQvazKX6K aGSg== Received: by 10.14.175.7 with SMTP id y7mr7757439eel.29.1345453323581; Mon, 20 Aug 2012 02:02:03 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-132.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id z6sm40007860eeo.6.2012.08.20.02.02.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 02:02:02 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_31E2CFE2-1DBE-46CC-B6D6-EAF376E88FB7"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> Date: Mon, 20 Aug 2012 11:02:01 +0200 Message-Id: <74DBBDC4-9827-4141-AB37-AE9256ACFF15@employees.org> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1278) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 20 Aug 2012 09:02:06 -0000 --Apple-Mail=_31E2CFE2-1DBE-46CC-B6D6-EAF376E88FB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ted, > Not wearing my chair hat, I support what this draft is trying to do. = However, the draft makes a decision to unify the state machines of the = IA_NA and IA_PD maintenance process. We've had some discussions about = this with customers, and one question that came up was whether it might = make sense to have different DHCP servers answering IA_NA and IA_PD = requests. Obviously this is not possible if the transaction can't be = split. >=20 > Have the authors considered this issue? Any opinions on the topic? >=20 > The reason for the potential separation is that in some cases the = business logic involved in delegating prefixes may be different than the = logic used to allocate addresses. Keeping the two functions separate = enables significant additional flexibility when provisioning CPE = devices. This draft, if it were to progress in its current state, = would rule out any such flexibility. This is not an absolute deal = breaker for me, but I wanted to raise the issue and see if anybody else = has thought about this. yes, we have talked about this issue. this draft clarifies correct = protocol behaviour when multiple stateful options are present. I suppose = it implicitly recommends one single DHCP session for multiple stateful = options, but I don't think the text prohibits using multiple sessions = either. that would be a choice the client could make, given the set of = ADVERTISE messages received. could we go forward with this draft that clarifies how multiple stateful = options work in a single session, and with the general assumption that a = client will choose one DHCP server and that server is authoritative? then have separate specifications for how clients should behave in a = multi-domain / separate session scenario if there is interest for that? cheers, Ole --Apple-Mail=_31E2CFE2-1DBE-46CC-B6D6-EAF376E88FB7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODIwMDkwMjAyWjAjBgkqhkiG9w0BCQQxFgQUGBbVyQf7lPO/Aioz CbYJyNqHOeowggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAMmihNskCUFhYl8MllY7x GKpEQoUY1pXtsjXlDen0D7sfrkIYswELlnWgWmCE0mrMoThIjpg7ZTSRH2VfiZNtRws7wjeaPiQg JBpAQqvy/mwaUlUG48jfPe731WYKsEBDeis/7dVFodNNp84Td1wR+j04gKsbEu8SaDIZoOy+sTDb Ejbcc8JH65o7WVcF+6DV2nc+GGqsviL6AwGXEcuwRUBrbR5LSDH/YRit3n1NiCc0bw3mqr+D7b/9 uT/BHJDNZkH3S7QrX7lFPFnxVSepj/UiFsF9XmuppVsf1nzusxglWSQ4VH16B0HC3nfQryehU7td 1lJn4fM52nuBWnGZEAAAAAAAAA== --Apple-Mail=_31E2CFE2-1DBE-46CC-B6D6-EAF376E88FB7-- From ichiroumakino@gmail.com Mon Aug 20 02:04:25 2012 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 EE94821F84F8 for ; Mon, 20 Aug 2012 02:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02LiJnPeiEcY for ; Mon, 20 Aug 2012 02:04:25 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0431521F86B3 for ; Mon, 20 Aug 2012 02:04:24 -0700 (PDT) Received: by eekb45 with SMTP id b45so1528655eek.31 for ; Mon, 20 Aug 2012 02:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=crvofexx5z/cg37UU6yOW8E9F4i9i+pm51IlhYqZZBk=; b=dtNbvVyswYlfVq5TdFxtasmnX48puk3U8Ezkq1NNecsIJrM3/MbVeveAeSinNF3EvY +v4cnebpN9nvWGntqqzd4ZsNSV9tR2O6cjflmtvFyzzmYPqw1pa1D7mbIm/JvGt3QIgn 4zs+rID1R67juls6Z9lOQ0pGpgcPiD4vKEJT/md/GN6d/fpAcUu/YTvDLUH1MTk8nOHG h2JqCLPNldWfiCAxFlwgriUUVUNa9E9raSv9KnZse4Zp9Lpc9iTPEwSgky3jef3dFJLa o9+seIFG/1jINQRfUyQ3MARxM68snhqIpqLkD1xnBbLpqp4dXBlWXLhzdUKQy1EkMZ8o j7Vw== Received: by 10.14.172.193 with SMTP id t41mr7848748eel.25.1345453464163; Mon, 20 Aug 2012 02:04:24 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-132.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id h42sm40029961eem.5.2012.08.20.02.04.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 02:04:22 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_63FB123D-6769-404D-B09E-436CBA793696"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <5AAE3B81-ABDE-49AF-BD14-C5307EC7CA7E@nominum.com> Date: Mon, 20 Aug 2012 11:04:22 +0200 Message-Id: References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> <5AAE3B81-ABDE-49AF-BD14-C5307EC7CA7E@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1278) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 20 Aug 2012 09:04:26 -0000 --Apple-Mail=_63FB123D-6769-404D-B09E-436CBA793696 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ted, > One other question about this draft: it proposes extending the Confirm = message to stateful options other than IA_NA. Presumably, the option = we're most interested in is IA_PD, but how would a DHCP server without = access to the client binding state know that a PD was valid? Are we = talking about a scenario like Leaf Yeh's prefix pool option, whether the = server simply validates that the proposed prefixes are within the pool = that is assigned to the specific PE router? the server may have enough information, be it configured or having the = binding. if so there is no harm in using confirm, and it has a lower = overhead than Renew. I wasn't thinking of this in the context of the = prefix pool option. cheers, Ole --Apple-Mail=_63FB123D-6769-404D-B09E-436CBA793696 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODIwMDkwNDIzWjAjBgkqhkiG9w0BCQQxFgQUT5b8XEVBdKOnI+xF ijG1iWlrs5cwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAGL4pEImL9nJcitPp96kw VOu9R7hezkkpV9TD5kWhWXj5Bf0ynrSl5tK0LI0IIKQDpsOn7V0UzqFqg2J/QDNvE1iRrtahrdND PmRpHt9V+18z30PWUgy+GJFOT70B5zzLInp6GKY/PPuwpyao+FDpRcFbm3z6MKBxwUyPz8ELhxly 0sR8s5kiEPUdQ/lMNlEEhSGbcKmMH6V0l1rPNh5efEYP53pXRBJB59d4L+eGEnjerGrPWkGk7bRP F4Pjq2G/NjrHkdh1KGYakwoRjfd0+XZh8CTUGHOeX/uqCWCBhAgKmm7dzxnoeiqfSM+kaabK53i+ LKyxEpCB7r1dQkGKqAAAAAAAAA== --Apple-Mail=_63FB123D-6769-404D-B09E-436CBA793696-- From ichiroumakino@gmail.com Mon Aug 20 02:06:33 2012 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 15B5821F86C9 for ; Mon, 20 Aug 2012 02:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA1uW8h9kTUh for ; Mon, 20 Aug 2012 02:06:20 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0196721F86CE for ; Mon, 20 Aug 2012 02:06:19 -0700 (PDT) Received: by eaai11 with SMTP id i11so1768551eaa.31 for ; Mon, 20 Aug 2012 02:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=TgrUlhRnzygwRWwCcff6SEYTlm926h2o1UF9GOkwi98=; b=SFPif7ttOhQDsJ/fihNOnw49bX7LFuvrt8lBKtd4fj2q5h3umMJNEdq5JJHKiG6tLv eIwfbyetiXP8c16a/Z91OwSVY3p4b+So/otV/RNFzL//A7YDAvauSoM6o5j5M8kARLKQ VIgOsDMoM2zeQNvHHZlFUSkJuy6HNrTswU+eJnPXCX77gLOCTNWc1m9zoXmgzjRZxbCi 5MS2AAWtElUSzMSG9SwF66Xxg6Miln5alx0V4LfA6n2Sl8tXGJ0yV02D5itS0FhudP/v FkVdXcO6rDL/gEzlH5zqaRfyt/HLnfPt1qVF9O3HzF+40+GS4mLqux7CGboROvilscef AcYg== Received: by 10.14.224.4 with SMTP id w4mr7900902eep.21.1345453578982; Mon, 20 Aug 2012 02:06:18 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-132.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id u47sm40020688eeo.9.2012.08.20.02.06.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 02:06:17 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_BA35FC1E-8127-420A-B5A3-6A6AB972CBB3"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 20 Aug 2012 11:06:17 +0200 Message-Id: <2C36D999-17A8-4EC0-ACDD-5599C8B86C95@employees.org> References: To: Wes Beebee (wbeebee) X-Mailer: Apple Mail (2.1278) Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 20 Aug 2012 09:06:33 -0000 --Apple-Mail=_BA35FC1E-8127-420A-B5A3-6A6AB972CBB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Wes, > Why MUST the client ignore an Advertise message with no bindings? > What if stateful and stateless options are carried in the same = message? > Does this mean the stateless options will be ignored just because the > stateful=20 > Options failed? >=20 > In general, I think this draft addresses an important problem that = needs > to be=20 > solved urgently. We need to think through carefully the consequences = of > the proposed=20 > solutions, however. how much do you want the protocol to change? that's how a client behaves = today. a client could fall-back to "stateless" DHCP, if it couldn't find any = servers that would reply to its request for an address. is that a change = we want to make? cheers, Ole= --Apple-Mail=_BA35FC1E-8127-420A-B5A3-6A6AB972CBB3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODIwMDkwNjE3WjAjBgkqhkiG9w0BCQQxFgQUNLbSb6xQkjGiCJk+ xX7MUr87jiQwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAabkdUdkKIdH/CiSvgQPR 1uK+Eu/l3qfceKZTaNcjpoEbC0fyNQnmj/ozpkbdRXI8e7eQ1Y6/seiasXi+qgxaRYzkykqnHea7 jFpp2h6N2yEe9z9cB2bvvVU81xq1yOYE+qkOmYup5FYGPvgnpRh68sVJMtKQvQTeWZAiZx71b76o qG4Enq+w93Jb4O6sW0mQf321asIuodmAggzH5P9k1J2kWMQ5oKWGz0/7Kr2aGI8rAwiZG020X2zG 46gHNZAECWo1M5ROX9xmup1cgo/MMJOnvMo0HLlvcCt1vpIB+JjDgWThCw7Jpgk6AqU6ZEiC2NTy GIAJK2J68C13BQKzugAAAAAAAA== --Apple-Mail=_BA35FC1E-8127-420A-B5A3-6A6AB972CBB3-- From ichiroumakino@gmail.com Mon Aug 20 02:13:18 2012 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 D360C21F8682 for ; Mon, 20 Aug 2012 02:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.093 X-Spam-Level: X-Spam-Status: No, score=-3.093 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9T1WvGgEJ2H for ; Mon, 20 Aug 2012 02:13:18 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C81B421F8543 for ; Mon, 20 Aug 2012 02:13:17 -0700 (PDT) Received: by eekb45 with SMTP id b45so1532162eek.31 for ; Mon, 20 Aug 2012 02:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=10ah5Zsbs6wkX5HMPCOfxvo4zvS45nokJplVObfGTXc=; b=l/HtOTbS6M1qnRf8d18WW1wrJkZdMrAQWyIYjQWCzEawCjcVPbPEuWO8Ji6vcpzv29 R9qRvRQ/eZmm0UPWk63MtFKTrAy0N51UOi8HgzJiLA1fvg+E2OZtbm8dfriIOSxwZ2ZP EYHyWdGcgZU0y7iX2AigRcJ0+VmuSNnsK4N5Yz+E1iW0UyvWYJIY+hXRq3zYsjampK9G 0x0Il+51Y47yYN7zMr5AEbSkhqNYyZ/GsKHInLHuHSlY6maCFo0ce0GTAyGdFWV5P1Fr oOSg6HmSWgBefsDs033FspwcRqMm50SJEqxcYej5STVr8LGBbvIaepkeYBE4g4xtBfLR GEeA== Received: by 10.14.206.200 with SMTP id l48mr7899624eeo.41.1345453997039; Mon, 20 Aug 2012 02:13:17 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-132.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id z6sm40091299eeo.6.2012.08.20.02.13.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 02:13:15 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_E3E2458F-2BEF-4ADE-B46E-D1BAE1C85A4E"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89071546@xmb-rcd-x06.cisco.com> Date: Mon, 20 Aug 2012 11:13:15 +0200 Message-Id: <805BB5B0-7046-4C98-9368-2CEC2BDC360D@employees.org> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> <5AAE3B81-ABDE-49AF-BD14-C5307EC7CA7E@nominum.com> <75B6FA9F576969419E42BECB86CB1B89071546@xmb-rcd-x06.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1278) Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 20 Aug 2012 09:13:19 -0000 --Apple-Mail=_E3E2458F-2BEF-4ADE-B46E-D1BAE1C85A4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hemant, > +1 to Wes' comment that this document is addressing a very important = problem space and the solutions are needed urgently. However, more = thought is required for the solutions. >=20 > In regards to section 4.4, if the server only checks the network = configuration to reply to a Confirm message, how is it possible for most = network configurations that the server determines an IA_PD is on-link? = I suspect that is why RFC 3633 prohibited use of the Confirm for the = IA_PD. In any case this document should explain why did RFC 3633 have a = restriction on using the Confirm for the IA_PD. Or does network = configuration include looking up the prefix pool configured on the = server for allocation? In contrast, to make an on-link determination = for an IA_NA IA_Address, all the server has to do is match = (longest-prefix match) all IPv6 addresses configured on the machine that = the server is running on. These addresses are clearly network = configuration.=20 right, either the server has the binding, or the server has = configuration that it can look up in, to verify if the client has moved = or not. if it has no information it MUST not reply. > Section 4.1: =20 >=20 > # In relation to the first paragraph the document is addressing the = fact that one server replies with, say, an IA_NA, while another server = replies back with only the IA_PD. Then why in section 4.7 the case of = section 4.1 is deemed out of scope? I also do not understand what does = "equal" in section 4.7 mean. Does it mean each server replies with all = IAs that the deployment needs? the assumption in 3315/3633 is that a client is connected to a single = administrative dhc domain on an interface. scenarios where a client finds two DHCP servers, that are administered = by two different entities, are outside of the scope of 3315/3633 and = therefore also outside the scope of this update. there is as far as I = know separate work in progress on this. > # In relation to the text in the last paragraph of section 4.1, if the = client does not restart the Solicit retransmissions timers, what does = the client do? continues with the timers it has. otherwise as the text says, a received advertise with a consequent = restart of solicit timers would result in a solicit storm. >=20 > # Other comment: Shouldn't the header of the document have an Updates = tag to signify this document updates RFC 3315? good point. both 3315 and 3633. cheers, Ole --Apple-Mail=_E3E2458F-2BEF-4ADE-B46E-D1BAE1C85A4E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODIwMDkxMzE1WjAjBgkqhkiG9w0BCQQxFgQUYzAVd/vYJmlJxqE0 VTTEfZ/wLQswggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAa3awxIHJF8qalnC9Oo45 Se6DUUQXPN1WbgWsVvpOnZrNn3rhtDY/zQRj2bgo7qmFE0A17k/PHO2Vp+o0vUrjPPe9FY+Dj5N9 T0plkjtgzgxES+y462XtE2jGDjB+0rZebHtuzh3BBO7OpQxVfkWKd24RmfRPLlTBlPDvTzla0v8L YHadltDHqsXVKlZqMXfvxKffbfQ2hGV3jEqVfZKMJ8JOuIFgTMP4gE3hiGFQZDYSQ/qtmFnbKFIp iqotzs15JGMg51+SM08zc58LAaZ4smRX0A6ZDBevDrF0UpIx20S2Vc8PB6IjIS6cTFsw5/2DjURV UPa456COL8VUhqU0cAAAAAAAAA== --Apple-Mail=_E3E2458F-2BEF-4ADE-B46E-D1BAE1C85A4E-- From Ted.Lemon@nominum.com Mon Aug 20 05:39:19 2012 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 ED0B321F8618 for ; Mon, 20 Aug 2012 05:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.411 X-Spam-Level: X-Spam-Status: No, score=-106.411 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLWgOtETkX6l for ; Mon, 20 Aug 2012 05:39:18 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4540321F8634 for ; Mon, 20 Aug 2012 05:39:18 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUDIv9aFmeK3Yw6YAaJSGYZ/iTatFRxds@postini.com; Mon, 20 Aug 2012 05:39:18 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 592EA1B82CD for ; Mon, 20 Aug 2012 05:39:17 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 4BEAE190043; Mon, 20 Aug 2012 05:39:17 -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.02.0247.003; Mon, 20 Aug 2012 05:39:11 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpddHmiAgAXOj4CAADyqAA== Date: Mon, 20 Aug 2012 12:39:10 +0000 Message-ID: <01634C66-161A-4C56-BD24-2F2180581D98@nominum.com> References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> <74DBBDC4-9827-4141-AB37-AE9256ACFF15@employees.org> In-Reply-To: <74DBBDC4-9827-4141-AB37-AE9256ACFF15@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: multipart/alternative; boundary="_000_01634C66161A4C56BD242F2180581D98nominumcom_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 20 Aug 2012 12:39:19 -0000 --_000_01634C66161A4C56BD242F2180581D98nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Aug 20, 2012, at 11:02 AM, Ole Tr=F8an > wrote: could we go forward with this draft that clarifies how multiple stateful op= tions work in a single session, and with the general assumption that a clie= nt will choose one DHCP server and that server is authoritative? My concern is that if you do so, it will essentially result in clients stan= dardizing on whatever behavior you specify, and so whether we write another= standard or not, it will not be available in practice. --_000_01634C66161A4C56BD242F2180581D98nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <35ECEFB5F25D724688FB0DB15966A99B@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 20, 2012, at 11:02 AM, Ole Tr=F8an <otroan@employees.org> wrote:
could we go forward with this draft that clarifies how multiple stateful options= work in a single session, and with the general assumption that a client wi= ll choose one DHCP server and that server is authoritative?

My concern is that if you do so, it will essentially result in clients= standardizing on whatever behavior you specify, and so whether we write an= other standard or not, it will not be available in practice.

--_000_01634C66161A4C56BD242F2180581D98nominumcom_-- From ichiroumakino@gmail.com Mon Aug 20 05:44:40 2012 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 3A68921F862A for ; Mon, 20 Aug 2012 05:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFX9YdbA3ISP for ; Mon, 20 Aug 2012 05:44:39 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57A6321F8618 for ; Mon, 20 Aug 2012 05:44:39 -0700 (PDT) Received: by eaai11 with SMTP id i11so1848764eaa.31 for ; Mon, 20 Aug 2012 05:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=xVwDePD2xnFgV04AbqXRk0vHgJ4voxdQqlzmV8c+N0o=; b=BG1D3m5YUeymGA83GZNxeu0aVe/ikkcl+Lf34oJxztAu93iPV4hZjvUgIQ7WcCu/yA kdqxSjwYlNJNblI+YlarWvNEsXDQ5D4Fy/FHC3ic+JVPaoQ69eWrPYTtfqA5THZu39Uq JZdxH5x7G15kA8J1Zz+b8V4m1X91qMaX8IAaHRZ7GxE36fy7ttY/TWNQTd9XOO3Fxo9H iw7TM39N+GSQUWrN8olMd8FphCj9LFbIptOzv+WqbPGXXr3QX83FmBWWG6awxVENED8P hL3uctZA9yLHG9Sp70NLURO0c6DZCznri4cBgNiwaykbMdWb+7268vKGP3DT9xTEQTc1 fATw== Received: by 10.14.202.66 with SMTP id c42mr8672583eeo.35.1345466678244; Mon, 20 Aug 2012 05:44:38 -0700 (PDT) Received: from ?IPv6:2001:420:44ff:fd17:745e:d5e9:8e39:416b? ([2001:420:44ff:fd17:745e:d5e9:8e39:416b]) by mx.google.com with ESMTPS id v3sm15709122eep.10.2012.08.20.05.44.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 05:44:37 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0BBA1E40-E7EA-4AF3-9333-59D82D48495A"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <01634C66-161A-4C56-BD24-2F2180581D98@nominum.com> Date: Mon, 20 Aug 2012 14:44:31 +0200 Message-Id: References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> <74DBBDC4-9827-4141-AB37-AE9256ACFF15@employees.org> <01634C66-161A-4C56-BD24-2F2180581D98@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1278) Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 20 Aug 2012 12:44:40 -0000 --Apple-Mail=_0BBA1E40-E7EA-4AF3-9333-59D82D48495A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ted, >> could we go forward with this draft that clarifies how multiple = stateful options work in a single session, and with the general = assumption that a client will choose one DHCP server and that server is = authoritative? >=20 > My concern is that if you do so, it will essentially result in clients = standardizing on whatever behavior you specify, and so whether we write = another standard or not, it will not be available in practice. to turn the question around. is there anyone who thinks that we should _not_ make multiple stateful = options work in a single DHCP session? cheers, Ole --Apple-Mail=_0BBA1E40-E7EA-4AF3-9333-59D82D48495A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwODIwMTI0NDMyWjAjBgkqhkiG9w0BCQQxFgQUNy4p4hhat1OFUcuq ZXYTgdGAgG4wggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEApOAFdd2la1xO2kz3UXRG fMyyXJqKgPFVVgSjJWgzfrkSPhXZhWqe6KGFNyKlJl0govOH46HJP7f6if1dUZvKJ4vfEJeCvCx/ a2+i6UCyecp+9L73N9rhRYHqBw80AsPQ3ltUwa/ZJ3YpF91qSNh7ayG4NsE2sYlN6nS5AXOFBzl4 gFNplsW4oD3OZ6l04/Tqe7r7aAmkCYJZv5VKLEtbKKLbxYZgCwcT5ckznlWx9lpaQILQZjzjtmnI 0VFeJ/Q6/gC35rtb8GNHf1ZHLKSzls2ba63KxE5E/tM7RVBWgtqf0hmn+tNTdtriSKV9GRankutA 742bavGfzyjQcbxOxAAAAAAAAA== --Apple-Mail=_0BBA1E40-E7EA-4AF3-9333-59D82D48495A-- From dankney@network1.net Mon Aug 20 06:07:44 2012 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 ABAAA21F84F8 for ; Mon, 20 Aug 2012 06:07:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twHRHAShlW2x for ; Mon, 20 Aug 2012 06:07:44 -0700 (PDT) Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) by ietfa.amsl.com (Postfix) with ESMTP id E38DA21F84EC for ; Mon, 20 Aug 2012 06:07:43 -0700 (PDT) Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id CDBC4541102; Mon, 20 Aug 2012 09:07:42 -0400 (EDT) Date: Mon, 20 Aug 2012 09:07:42 -0400 (EDT) From: perl-list To: Chuck Anderson Message-ID: <214048976.131904.1345468062774.JavaMail.root@network1.net> In-Reply-To: <20120819033513.GA21200@angus.ind.WPI.EDU> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_131903_490917250.1345468062773" X-Originating-IP: [74.115.182.5] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC21 (Mac)/7.2.0_GA_2669) Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 20 Aug 2012 13:07:44 -0000 ------=_Part_131903_490917250.1345468062773 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I also support this text change... ----- Original Message ----- > From: "Chuck Anderson" > To: "Ted Lemon" > Cc: "dhc WG" > Sent: Saturday, August 18, 2012 11:35:13 PM > Subject: Re: [dhcwg] WGLC: > draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 > On Thu, Aug 16, 2012 at 07:38:48PM +0000, Ted Lemon wrote: > > On Aug 16, 2012, at 2:21 PM, Chuck Anderson wrote: > > "4. DHCPv6 Relay Agent Behavior > > > > DHCPv6 Relay agents which are directly connected to clients/hosts > > MAY > > include client link-layer address option in relayed DHCPv6 (RELAY- > > FORW) message. The DHCPv6 Relay agent behaviour can depend on > > configuration that decides whether Client Link-layer Address option > > needs to be processed and included. > > > > In Relay chaining scenarios, any other relay agent other than first > > hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221] MUST not add this > > option." > > > > Could say: > > > > DHCPv6 Relay agents which receive messages originating from clients > > (for example Solicit and Request, but not, for example, Relay > > Forward or Advertise) MAY include the link-layer source address of > > the received message in relayed DHCPv6 Relay Forward messages. > > The DHCPv6 Relay agent behavior can depend on configuration that > > decides whether Client Link-layer Address option needs to be > > processed and included. > I agree that this text would be good to replace the existing text in > section 4. > > > > This makes it clear where the link layer address is coming from. As > > an added bonus, there's no need to mention LDRAs or intermediary > > relays, since Relay Forward messages are specifically excluded. > Agreed. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_Part_131903_490917250.1345468062773 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: arial,helvetica,sans-serif; font-size: 10pt; colo= r: #000000'>I also support this text change...

From: <= /b>"Chuck Anderson" <cra@WPI.EDU>
To: "Ted Lemon" <Ted.L= emon@nominum.com>
Cc: "dhc WG" <dhcwg@ietf.org>
Se= nt: Saturday, August 18, 2012 11:35:13 PM
Subject: Re: [dhcwg= ] WGLC:        draft-ietf-dhc-dhcpv= 6-client-link-layer-addr-opt-01

On Thu, Aug 16, 2012 at 07:38:48PM += 0000, Ted Lemon wrote:
> On Aug 16, 2012, at 2:21 PM, Chuck Anderson = wrote:
> "4.  DHCPv6 Relay Agent Behavior
>
>  = ; DHCPv6 Relay agents which are directly connected to clients/hosts MAY
= >   include client link-layer address option in relayed DHCPv6 (REL= AY-
>   FORW) message.  The DHCPv6 Relay agent behaviour ca= n depend on
>   configuration that decides whether Client Link-l= ayer Address option
>   needs to be processed and included.
&= gt;
>   In Relay chaining scenarios, any other relay agent othe= r than first
>   hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221]= MUST not add this
>   option."
>
> Could say:
&= gt;
>   DHCPv6 Relay agents which receive messages originating = from clients
>   (for example Solicit and Request, but not, for = example, Relay
>   Forward or Advertise) MAY include the link-la= yer source address of
>   the received message in relayed DHCPv6= Relay Forward messages.
>   The DHCPv6 Relay agent behavior can= depend on configuration that
>   decides whether Client Link-la= yer Address option needs to be
>   processed and included.
I agree that this text would be good to replace the existing text in
s= ection 4.

>
> This makes it clear where the link layer add= ress is coming from.   As an added bonus, there's no need to mention L= DRAs or intermediary relays, since Relay Forward messages are specifically = excluded.

Agreed.
_______________________________________________=
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/li= stinfo/dhcwg


------=_Part_131903_490917250.1345468062773-- From ghalwasi@cisco.com Mon Aug 20 06:42:56 2012 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 1025021F85B1 for ; Mon, 20 Aug 2012 06:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKe1zF3+Hv7V for ; Mon, 20 Aug 2012 06:42:55 -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 E06F521F8513 for ; Mon, 20 Aug 2012 06:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=13906; q=dns/txt; s=iport; t=1345470175; x=1346679775; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uqMwYIgPZH+PdqhH1qEyoIvtuCckO07uuha9lSs5nNU=; b=lTlAJWQWyU6+fXdelTcVspHByfmIfjteb6/6HBMQKyGBp5GS5URwiJsb ZOR4t2OZaXwldjTe67a1VZ0RC7ZlrScX09DGnSFXyYNvU7MGmhMkoQ+MV HNuMpTpclTksnNjahkEnglEYu8a14pCNtQDExZSKgDlQSwsUfV8AaytKN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEM+MlCtJV2Z/2dsb2JhbABFDoI8gzezW22BB4IgAQEBAwEBAQEPARAKQQsQAgEIEQQBAQEKHQMCAgIlCxQJCAIEAQ0FCBqHZQYLmGiNGJJIBIsLhgAyYAOjfIFmgic6 X-IronPort-AV: E=Sophos;i="4.77,797,1336348800"; d="scan'208,217";a="113334816" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 20 Aug 2012 13:42:54 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7KDgsw4025190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Aug 2012 13:42:54 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Mon, 20 Aug 2012 08:42:53 -0500 From: "Gaurav Halwasia (ghalwasi)" To: perl-list , Chuck Anderson Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 Thread-Index: AQHNftTMeDbiM6OCKE6kv7Q/GdzHBZditUzg Date: Mon, 20 Aug 2012 13:42:53 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0DC0CE@xmb-aln-x06.cisco.com> References: <20120819033513.GA21200@angus.ind.WPI.EDU> <214048976.131904.1345468062774.JavaMail.root@network1.net> In-Reply-To: <214048976.131904.1345468062774.JavaMail.root@network1.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.86.179] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19126.006 x-tm-as-result: No--43.525500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB0DC0CExmbalnx06ciscocom_" MIME-Version: 1.0 Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 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, 20 Aug 2012 13:42:56 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB0DC0CExmbalnx06ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGEgbG90IGZvciBzdXBwb3J0aW5nIHRoaXMgZG9jdW1lbnQsIHJldmlld2luZyBhbmQg cHJvdmlkaW5nIGZlZWRiYWNrIHNvIGZhci4gV2Ugd2lsbCBpbmNsdWRlIHRoaXMgdGV4dCBpbiB0 aGUgZHJhZnQuDQoNClRoYW5rcywNCkdhdXJhdg0KDQpGcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHBlcmwtbGlz dA0KU2VudDogTW9uZGF5LCBBdWd1c3QgMjAsIDIwMTIgNjozOCBQTQ0KVG86IENodWNrIEFuZGVy c29uDQpDYzogZGhjIFdHOyBUZWQgTGVtb24NClN1YmplY3Q6IFJlOiBbZGhjd2ddIFdHTEM6IGRy YWZ0LWlldGYtZGhjLWRoY3B2Ni1jbGllbnQtbGluay1sYXllci1hZGRyLW9wdC0wMQ0KDQpJIGFs c28gc3VwcG9ydCB0aGlzIHRleHQgY2hhbmdlLi4uDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tOiAiQ2h1Y2sgQW5kZXJzb24iIDxjcmFAV1BJLkVEVTxtYWlsdG86Y3Jh QFdQSS5FRFU+Pg0KVG86ICJUZWQgTGVtb24iIDxUZWQuTGVtb25Abm9taW51bS5jb208bWFpbHRv OlRlZC5MZW1vbkBub21pbnVtLmNvbT4+DQpDYzogImRoYyBXRyIgPGRoY3dnQGlldGYub3JnPG1h aWx0bzpkaGN3Z0BpZXRmLm9yZz4+DQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDE4LCAyMDEyIDEx OjM1OjEzIFBNDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBXR0xDOiAgICAgICAgZHJhZnQtaWV0Zi1k aGMtZGhjcHY2LWNsaWVudC1saW5rLWxheWVyLWFkZHItb3B0LTAxDQoNCk9uIFRodSwgQXVnIDE2 LCAyMDEyIGF0IDA3OjM4OjQ4UE0gKzAwMDAsIFRlZCBMZW1vbiB3cm90ZToNCj4gT24gQXVnIDE2 LCAyMDEyLCBhdCAyOjIxIFBNLCBDaHVjayBBbmRlcnNvbiB3cm90ZToNCj4gIjQuICBESENQdjYg UmVsYXkgQWdlbnQgQmVoYXZpb3INCj4NCj4gICBESENQdjYgUmVsYXkgYWdlbnRzIHdoaWNoIGFy ZSBkaXJlY3RseSBjb25uZWN0ZWQgdG8gY2xpZW50cy9ob3N0cyBNQVkNCj4gICBpbmNsdWRlIGNs aWVudCBsaW5rLWxheWVyIGFkZHJlc3Mgb3B0aW9uIGluIHJlbGF5ZWQgREhDUHY2IChSRUxBWS0N Cj4gICBGT1JXKSBtZXNzYWdlLiAgVGhlIERIQ1B2NiBSZWxheSBhZ2VudCBiZWhhdmlvdXIgY2Fu IGRlcGVuZCBvbg0KPiAgIGNvbmZpZ3VyYXRpb24gdGhhdCBkZWNpZGVzIHdoZXRoZXIgQ2xpZW50 IExpbmstbGF5ZXIgQWRkcmVzcyBvcHRpb24NCj4gICBuZWVkcyB0byBiZSBwcm9jZXNzZWQgYW5k IGluY2x1ZGVkLg0KPg0KPiAgIEluIFJlbGF5IGNoYWluaW5nIHNjZW5hcmlvcywgYW55IG90aGVy IHJlbGF5IGFnZW50IG90aGVyIHRoYW4gZmlyc3QNCj4gICBob3AgREhDUHY2IFJlbGF5IGFnZW50 IG9yIERIQ1B2NiBMRFJBIFtSRkM2MjIxXSBNVVNUIG5vdCBhZGQgdGhpcw0KPiAgIG9wdGlvbi4i DQo+DQo+IENvdWxkIHNheToNCj4NCj4gICBESENQdjYgUmVsYXkgYWdlbnRzIHdoaWNoIHJlY2Vp dmUgbWVzc2FnZXMgb3JpZ2luYXRpbmcgZnJvbSBjbGllbnRzDQo+ICAgKGZvciBleGFtcGxlIFNv bGljaXQgYW5kIFJlcXVlc3QsIGJ1dCBub3QsIGZvciBleGFtcGxlLCBSZWxheQ0KPiAgIEZvcndh cmQgb3IgQWR2ZXJ0aXNlKSBNQVkgaW5jbHVkZSB0aGUgbGluay1sYXllciBzb3VyY2UgYWRkcmVz cyBvZg0KPiAgIHRoZSByZWNlaXZlZCBtZXNzYWdlIGluIHJlbGF5ZWQgREhDUHY2IFJlbGF5IEZv cndhcmQgbWVzc2FnZXMuDQo+ICAgVGhlIERIQ1B2NiBSZWxheSBhZ2VudCBiZWhhdmlvciBjYW4g ZGVwZW5kIG9uIGNvbmZpZ3VyYXRpb24gdGhhdA0KPiAgIGRlY2lkZXMgd2hldGhlciBDbGllbnQg TGluay1sYXllciBBZGRyZXNzIG9wdGlvbiBuZWVkcyB0byBiZQ0KPiAgIHByb2Nlc3NlZCBhbmQg aW5jbHVkZWQuDQoNCkkgYWdyZWUgdGhhdCB0aGlzIHRleHQgd291bGQgYmUgZ29vZCB0byByZXBs YWNlIHRoZSBleGlzdGluZyB0ZXh0IGluDQpzZWN0aW9uIDQuDQoNCj4NCj4gVGhpcyBtYWtlcyBp dCBjbGVhciB3aGVyZSB0aGUgbGluayBsYXllciBhZGRyZXNzIGlzIGNvbWluZyBmcm9tLiAgIEFz IGFuIGFkZGVkIGJvbnVzLCB0aGVyZSdzIG5vIG5lZWQgdG8gbWVudGlvbiBMRFJBcyBvciBpbnRl cm1lZGlhcnkgcmVsYXlzLCBzaW5jZSBSZWxheSBGb3J3YXJkIG1lc3NhZ2VzIGFyZSBzcGVjaWZp Y2FsbHkgZXhjbHVkZWQuDQoNCkFncmVlZC4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpkaGN3ZyBtYWlsaW5nIGxpc3QNCmRoY3dnQGlldGYub3JnPG1h aWx0bzpkaGN3Z0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGhjd2cNCg0K --_000_90903C21C73202418A48BFBE80AEE5EB0DC0CExmbalnx06ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDEx IDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBh IGxvdCBmb3Igc3VwcG9ydGluZyB0aGlzIGRvY3VtZW50LCByZXZpZXdpbmcgYW5kIHByb3ZpZGlu ZyBmZWVkYmFjayBzbyBmYXIuIFdlIHdpbGwgaW5jbHVkZSB0aGlzIHRleHQgaW4gdGhlIGRyYWZ0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HYXVyYXY8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ct Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+cGVybC1saXN0PGJyPg0KPGI+ U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDIwLCAyMDEyIDY6MzggUE08YnI+DQo8Yj5Ubzo8L2I+ IENodWNrIEFuZGVyc29uPGJyPg0KPGI+Q2M6PC9iPiBkaGMgV0c7IFRlZCBMZW1vbjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW2RoY3dnXSBXR0xDOiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtY2xp ZW50LWxpbmstbGF5ZXItYWRkci1vcHQtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+SSBhbHNvIHN1cHBvcnQgdGhpcyB0ZXh0IGNoYW5nZS4uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9 IjEwMCUiIGFsaWduPSJjZW50ZXIiIGlkPSJ6d2NociI+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBGRiAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+JnF1b3Q7Q2h1Y2sgQW5kZXJzb24m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjcmFAV1BJLkVEVSI+Y3JhQFdQSS5FRFU8L2E+Jmd0 Ozxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7VGVkIExlbW9uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86VGVkLkxlbW9uQG5vbWludW0uY29tIj5UZWQuTGVtb25Abm9taW51bS5jb208L2E+Jmd0Ozxi cj4NCjxiPkNjOiA8L2I+JnF1b3Q7ZGhjIFdHJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGhj d2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TZW50OiA8L2I+U2F0 dXJkYXksIEF1Z3VzdCAxOCwgMjAxMiAxMTozNToxMyBQTTxicj4NCjxiPlN1YmplY3Q6IDwvYj5S ZTogW2RoY3dnXSBXR0xDOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO2RyYWZ0LWlldGYtZGhjLWRoY3B2Ni1jbGllbnQtbGluay1sYXllci1hZGRyLW9wdC0w MTxicj4NCjxicj4NCk9uIFRodSwgQXVnIDE2LCAyMDEyIGF0IDA3OjM4OjQ4UE0gJiM0MzswMDAw LCBUZWQgTGVtb24gd3JvdGU6PGJyPg0KJmd0OyBPbiBBdWcgMTYsIDIwMTIsIGF0IDI6MjEgUE0s IENodWNrIEFuZGVyc29uIHdyb3RlOjxicj4NCiZndDsgJnF1b3Q7NC4gJm5ic3A7REhDUHY2IFJl bGF5IEFnZW50IEJlaGF2aW9yPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyBESENQdjYgUmVs YXkgYWdlbnRzIHdoaWNoIGFyZSBkaXJlY3RseSBjb25uZWN0ZWQgdG8gY2xpZW50cy9ob3N0cyBN QVk8YnI+DQomZ3Q7ICZuYnNwOyBpbmNsdWRlIGNsaWVudCBsaW5rLWxheWVyIGFkZHJlc3Mgb3B0 aW9uIGluIHJlbGF5ZWQgREhDUHY2IChSRUxBWS08YnI+DQomZ3Q7ICZuYnNwOyBGT1JXKSBtZXNz YWdlLiAmbmJzcDtUaGUgREhDUHY2IFJlbGF5IGFnZW50IGJlaGF2aW91ciBjYW4gZGVwZW5kIG9u PGJyPg0KJmd0OyAmbmJzcDsgY29uZmlndXJhdGlvbiB0aGF0IGRlY2lkZXMgd2hldGhlciBDbGll bnQgTGluay1sYXllciBBZGRyZXNzIG9wdGlvbjxicj4NCiZndDsgJm5ic3A7IG5lZWRzIHRvIGJl IHByb2Nlc3NlZCBhbmQgaW5jbHVkZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyBJbiBS ZWxheSBjaGFpbmluZyBzY2VuYXJpb3MsIGFueSBvdGhlciByZWxheSBhZ2VudCBvdGhlciB0aGFu IGZpcnN0PGJyPg0KJmd0OyAmbmJzcDsgaG9wIERIQ1B2NiBSZWxheSBhZ2VudCBvciBESENQdjYg TERSQSBbUkZDNjIyMV0gTVVTVCBub3QgYWRkIHRoaXM8YnI+DQomZ3Q7ICZuYnNwOyBvcHRpb24u JnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENvdWxkIHNheTo8YnI+DQomZ3Q7IDxicj4NCiZn dDsgJm5ic3A7IERIQ1B2NiBSZWxheSBhZ2VudHMgd2hpY2ggcmVjZWl2ZSBtZXNzYWdlcyBvcmln aW5hdGluZyBmcm9tIGNsaWVudHM8YnI+DQomZ3Q7ICZuYnNwOyAoZm9yIGV4YW1wbGUgU29saWNp dCBhbmQgUmVxdWVzdCwgYnV0IG5vdCwgZm9yIGV4YW1wbGUsIFJlbGF5PGJyPg0KJmd0OyAmbmJz cDsgRm9yd2FyZCBvciBBZHZlcnRpc2UpIE1BWSBpbmNsdWRlIHRoZSBsaW5rLWxheWVyIHNvdXJj ZSBhZGRyZXNzIG9mPGJyPg0KJmd0OyAmbmJzcDsgdGhlIHJlY2VpdmVkIG1lc3NhZ2UgaW4gcmVs YXllZCBESENQdjYgUmVsYXkgRm9yd2FyZCBtZXNzYWdlcy48YnI+DQomZ3Q7ICZuYnNwOyBUaGUg REhDUHY2IFJlbGF5IGFnZW50IGJlaGF2aW9yIGNhbiBkZXBlbmQgb24gY29uZmlndXJhdGlvbiB0 aGF0PGJyPg0KJmd0OyAmbmJzcDsgZGVjaWRlcyB3aGV0aGVyIENsaWVudCBMaW5rLWxheWVyIEFk ZHJlc3Mgb3B0aW9uIG5lZWRzIHRvIGJlPGJyPg0KJmd0OyAmbmJzcDsgcHJvY2Vzc2VkIGFuZCBp bmNsdWRlZC48YnI+DQo8YnI+DQpJIGFncmVlIHRoYXQgdGhpcyB0ZXh0IHdvdWxkIGJlIGdvb2Qg dG8gcmVwbGFjZSB0aGUgZXhpc3RpbmcgdGV4dCBpbjxicj4NCnNlY3Rpb24gNC48YnI+DQo8YnI+ DQomZ3Q7IDxicj4NCiZndDsgVGhpcyBtYWtlcyBpdCBjbGVhciB3aGVyZSB0aGUgbGluayBsYXll ciBhZGRyZXNzIGlzIGNvbWluZyBmcm9tLiAmbmJzcDsgQXMgYW4gYWRkZWQgYm9udXMsIHRoZXJl J3Mgbm8gbmVlZCB0byBtZW50aW9uIExEUkFzIG9yIGludGVybWVkaWFyeSByZWxheXMsIHNpbmNl IFJlbGF5IEZvcndhcmQgbWVzc2FnZXMgYXJlIHNwZWNpZmljYWxseSBleGNsdWRlZC48YnI+DQo8 YnI+DQpBZ3JlZWQuPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpkaGN3ZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGhj d2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2ciPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_90903C21C73202418A48BFBE80AEE5EB0DC0CExmbalnx06ciscocom_-- From volz@cisco.com Mon Aug 20 06:49:45 2012 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 2544721F8681 for ; Mon, 20 Aug 2012 06:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.421 X-Spam-Level: X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHMvmlPnindR for ; Mon, 20 Aug 2012 06:49:43 -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 B270C21F869A for ; Mon, 20 Aug 2012 06:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=7348; q=dns/txt; s=iport; t=1345470582; x=1346680182; h=from:to:cc:subject:date:message-id:mime-version; bh=OpTyfjUFVnMlB+P63PzzXkeaCYjYimpxVhkddeD4rHg=; b=CC3ZMpTf98r+BrJpqWUm7h8pPSVFbHUfc86w6FSxPNBwGmmj21AaV+Pe 1uYIG79b7J2yailaDCvbigGRdJTFdJ2DwCsK+oEuresLL1mwK/fC/l052 WKWrY+udNIUC2K3GeUqPbJk3Z0MopLu/PfxY6TQwaVC3/FfcAXk89DF9A 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIE/MlCtJXG9/2dsb2JhbABFgkq3f4EHgiABAQEDARIBGkwFBwYBCBEEAQELHTkUCQkBBAENBQgah2UGmHGfZIsLhjJgA4gam2KBZoJh X-IronPort-AV: E=Sophos;i="4.77,797,1336348800"; d="scan'208,217";a="113386029" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 20 Aug 2012 13:49:41 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7KDnfvj030978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Aug 2012 13:49:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Mon, 20 Aug 2012 08:49:40 -0500 From: "Bernie Volz (volz)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Ted Lemon Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains Thread-Index: Ac1+2qSXxInmBkiATQCmRLl22d35Bg== Date: Mon, 20 Aug 2012 13:49:39 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4EE2F8@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.113] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19126.004 x-tm-as-result: No--26.135600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E0F4EE2F8xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains 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, 20 Aug 2012 13:49:45 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E0F4EE2F8xmbrcdx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the slides I presented at IETF-83 (Paris) and IETF-84 (Vancouver) about = this work, the last slide had: Multiple Administrative Domains * Still planning to write new Internet-Draft on multiple administrati= ve domains * Basic proposal will be for Advertise to include "Administrative Dom= ain" option which contains an "administrative domain string" * Clients treat Advertises with the same administrative domain string= as 'equal' * Clients may select one or several administrative domains; If multip= le, each is a separate state machine The basic idea here is that if a client sends a Solicit with IA_NA and IA_P= D, one server (or set of servers) may respond with IA_NA information and ad= ministrative domain string A and another server (or set of servers) may res= pond with IA_PD and administrative domain string B. This would trigger the = client to initiate two separate state machines. Of course, there is also the possibility that other server(s) may respond w= ith both the IA_NA and IA_PD and administrative domain string C. In which c= ase the client now has to determine whether to use one state machine (and a= dministrative domain C) or two state machines and administrative domain A (= IA_NA) & B (IA_PD). While fairly simple in concept (and for servers [include administrative dom= ain option] and relays [no impact]), it does greatly complicate clients. One idea would be for clients to implement something similar to what they d= o for WiFi and SSIDs - a user would be required to select which administrat= ive domains are valid. One interesting twist here is that just like with Wi= FI, we could also secure this -- add an encryption option which would provi= de a way to secure the DHCP server(s) with which you are willing to communi= cate. I haven't started work on this draft as it wasn't clear how much interest t= here is and if there are real world requirements for something like this. I= f there is sufficient interest, I would be happy to start work on it. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of O= le Tr=F8an Sent: Monday, August 20, 2012 8:45 AM To: Ted Lemon Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Ted, >> could we go forward with this draft that clarifies how multiple stateful= options work in a single session, and with the general assumption that a c= lient will choose one DHCP server and that server is authoritative? > > My concern is that if you do so, it will essentially result in clients st= andardizing on whatever behavior you specify, and so whether we write anoth= er standard or not, it will not be available in practice. to turn the question around. is there anyone who thinks that we should _not_ make multiple stateful opti= ons work in a single DHCP session? cheers, Ole --_000_489D13FBFA9B3E41812EA89F188F018E0F4EE2F8xmbrcdx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In the slides I presented at IETF-83 (Paris) and IETF-84 (Vancouver) a= bout this work, the last slide had:
 
Multiple Administrative Domains
  • Still planning to write new Internet-Draft on multiple administrative d= omains
  • Basic proposal will be for Advertise to include “Admin= istrative Domain” option which contains an “administrative doma= in string”
  • Clients treat Advertises with the same administrat= ive domain string as ‘equal’
  • Clients may select one or = several administrative domains; If multiple, each is a separate state machi= ne
 
The basic idea here is that if a client sends a Solicit with IA_NA and= IA_PD, one server (or set of servers) may respond with IA_NA information a= nd administrative domain string A and another server (or set of servers) ma= y respond with IA_PD and administrative domain string B. This would trigger the client to initiate two separate sta= te machines.
 
Of course, there is also the possibility that other server(s) may resp= ond with both the IA_NA and IA_PD and administrative domain string C. In wh= ich case the client now has to determine whether to use one state machine (= and administrative domain C) or two state machines and administrative domain A (IA_NA) & B (IA_PD).
 
While fairly simple in concept (and for servers [include administrativ= e domain option] and relays [no impact]), it does greatly complicate client= s.
 
One idea would be for clients to implement something similar to what t= hey do for WiFi and SSIDs - a user would be required to select which admini= strative domains are valid. One interesting twist here is that just like wi= th WiFI, we could also secure this -- add an encryption option which would provide a way to secure the DHCP se= rver(s) with which you are willing to communicate.
 
 
I haven't started work on this draft as it wasn't clear how much inter= est there is and if there are real world requirements for something like th= is. If there is sufficient interest, I would be happy to start work on it.<= /div>
 
- Bernie
 
-----Original Message-----
From: dhcwg-bounces@ietf.org [mai= lto:dhcwg-bounces@ietf.org] On Behalf Of Ole Tr=F8an
Sent: Monday, August 20, 2012 8:45 AM
To: Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00
 
Ted,
 
>> could we go forward with this draft that clarifies how multip= le stateful options work in a single session, and with the general assumpti= on that a client will choose one DHCP server and that server is authoritati= ve?
>
> My concern is that if you do so, it will essentially result in cl= ients standardizing on whatever behavior you specify, and so whether we wri= te another standard or not, it will not be available in practice.
 
to turn the question around.
is there anyone who thinks that we should _not_ make multiple stateful= options work in a single DHCP session?
 
cheers,
Ole
 
 
 --_000_489D13FBFA9B3E41812EA89F188F018E0F4EE2F8xmbrcdx04ciscoc_-- From Ted.Lemon@nominum.com Mon Aug 20 10:15:28 2012 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 6B1B321F85A5 for ; Mon, 20 Aug 2012 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.409 X-Spam-Level: X-Spam-Status: No, score=-106.409 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuwwSs85q4pk for ; Mon, 20 Aug 2012 10:15:28 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id D0C3E21F85A0 for ; Mon, 20 Aug 2012 10:15:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUDJwr4IWSEK2h90szFMdcufI4OAGDwsE@postini.com; Mon, 20 Aug 2012 10:15:27 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 C7A561B8322 for ; Mon, 20 Aug 2012 10:15:26 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 BCEB4190043; Mon, 20 Aug 2012 10:15:26 -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.02.0247.003; Mon, 20 Aug 2012 10:15:27 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpddHmiAgAXOj4CAADyqAIAAAYGA///WWJE= Date: Mon, 20 Aug 2012 17:15:25 +0000 Message-ID: References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> <74DBBDC4-9827-4141-AB37-AE9256ACFF15@employees.org> <01634C66-161A-4C56-BD24-2F2180581D98@nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-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, 20 Aug 2012 17:15:28 -0000 On Aug 20, 2012, at 2:44 PM, "Ole Tr=F8an" wrote: > is there anyone who thinks that we should _not_ make multiple stateful op= tions work in a single DHCP session? That's certainly not what I am getting at! :)= From Ted.Lemon@nominum.com Mon Aug 20 10:18:28 2012 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 D3AFF21F8604 for ; Mon, 20 Aug 2012 10:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWH37axpEyS8 for ; Mon, 20 Aug 2012 10:18:28 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 42E3021F8602 for ; Mon, 20 Aug 2012 10:18:28 -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 DSNKUDJxY+JcDdSGpQdWEXAJrlS0lrw1bU8f@postini.com; Mon, 20 Aug 2012 10:18: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 40C791B8322 for ; Mon, 20 Aug 2012 10:18:27 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 38797190043; Mon, 20 Aug 2012 10:18:27 -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.02.0247.003; Mon, 20 Aug 2012 10:18:27 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains Thread-Index: Ac1+2qSXxInmBkiATQCmRLl22d35BgAHSr7V Date: Mon, 20 Aug 2012 17:18:27 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E0F4EE2F8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4EE2F8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains 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, 20 Aug 2012 17:18:28 -0000 On Aug 20, 2012, at 3:49 PM, "Bernie Volz (volz)" wrote: > I haven't started work on this draft as it wasn't clear how much interest= there is and if there are real world requirements for something like this.= If there is sufficient interest, I would be happy to start work on it. I would like to see it. The phrase to use is "provisioning domain" rather = than administrative domain. = From internet-drafts@ietf.org Tue Aug 21 00:11:58 2012 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 399F911E80F3; Tue, 21 Aug 2012 00:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y4XDLS+mgHc; Tue, 21 Aug 2012 00:11:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEDC11E80E9; Tue, 21 Aug 2012 00:11:56 -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.33 Message-ID: <20120821071155.22895.5717.idtracker@ietfa.amsl.com> Date: Tue, 21 Aug 2012 00:11:55 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-host-gen-id-03.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, 21 Aug 2012 07:11:58 -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 : Prefix Assignment in DHCPv6 Author(s) : Sheng Jiang Frank Xia Behcet Sarikaya Filename : draft-ietf-dhc-host-gen-id-03.txt Pages : 11 Date : 2012-08-21 Abstract: This document introduces a generic prefix announcement mechanism using DHCPv6. In this new address configuration procedure, the prefix is propagated from a DHCPv6 server to hosts through DHCPv6 message exchanging while the interface identifiers are independently generated by the hosts. It enables both integral address assignment and self-generated addresses in one single mechanism, DHCPv6. It also enables stateless address configuration without RA attendance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-host-gen-id There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-host-gen-id-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-host-gen-id-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jiangsheng@huawei.com Tue Aug 21 00:51:51 2012 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 9567F21F856C for ; Tue, 21 Aug 2012 00:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUWw3Eo3Kdiq for ; Tue, 21 Aug 2012 00:51:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F201D21F855F for ; Tue, 21 Aug 2012 00:51:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJR02561; Mon, 20 Aug 2012 23:51:50 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Aug 2012 00:29:43 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Aug 2012 00:29:42 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.47]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Tue, 21 Aug 2012 15:29:39 +0800 From: Sheng Jiang To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-host-gen-id-03.txt Thread-Index: AQHNf2xG9hp+DKO3UUeSWirbeBFOOZdj3HAA Date: Tue, 21 Aug 2012 07:29:38 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F21DE9@szxeml545-mbx.china.huawei.com> References: <20120821071155.22895.5717.idtracker@ietfa.amsl.com> In-Reply-To: <20120821071155.22895.5717.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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-host-gen-id-03.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, 21 Aug 2012 07:51:51 -0000 VGhlIGF1dGhvcnMgaGF2ZSB1cGRhdGVkIHRoaXMgZHJhZnQgYWNjb3JkaW5nIHRvIHRoZSBsYXRl c3QgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbCBsaXN0Lg0KDQpBbW9uZyB3aXRoIG1pbm9yIG1vZGlm aWNhdGlvbnMsIHRoZSBhdXRob3JzIGhhdmUgbGFyZ2VseSByZXdyaXR0ZW4gdGhlIGludHJvZHVj dGlvbi9tb3RpdmF0aW9uIHNlY3Rpb24sIGhvcGluZyB0aGlzIHdvdWxkIGNsYXJpZnkgdGhlIHRh cmdldCBzY2VuYXJpb3MuDQoNCkRpc2N1c3Npb24vcmV2aWV3L2NvbW1lbnRzIGFyZSB3ZWxjb21l Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYNCj5PZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj5TZW50OiBU dWVzZGF5LCBBdWd1c3QgMjEsIDIwMTIgMzoxMiBQTQ0KPlRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmcNCj5DYzogZGhjd2dAaWV0Zi5vcmcNCj5TdWJqZWN0OiBbZGhjd2ddIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtZGhjLWhvc3QtZ2VuLWlkLTAzLnR4dA0KPg0KPg0KPkEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRHluYW1pYyBIb3N0IENv bmZpZ3VyYXRpb24gV29ya2luZyBHcm91cA0KPm9mIHRoZSBJRVRGLg0KPg0KPglUaXRsZSAgICAg ICAgICAgOiBQcmVmaXggQXNzaWdubWVudCBpbiBESENQdjYNCj4JQXV0aG9yKHMpICAgICAgIDog U2hlbmcgSmlhbmcNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEZyYW5rIFhpYQ0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgQmVoY2V0IFNhcmlrYXlhDQo+CUZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtZGhjLWhvc3QtZ2VuLWlkLTAzLnR4dA0KPglQYWdlcyAgICAgICAgICAgOiAx MQ0KPglEYXRlICAgICAgICAgICAgOiAyMDEyLTA4LTIxDQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhp cyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgZ2VuZXJpYyBwcmVmaXggYW5ub3VuY2VtZW50IG1lY2hh bmlzbQ0KPiAgIHVzaW5nIERIQ1B2Ni4gIEluIHRoaXMgbmV3IGFkZHJlc3MgY29uZmlndXJhdGlv biBwcm9jZWR1cmUsIHRoZQ0KPiAgIHByZWZpeCBpcyBwcm9wYWdhdGVkIGZyb20gYSBESENQdjYg c2VydmVyIHRvIGhvc3RzIHRocm91Z2ggREhDUHY2DQo+ICAgbWVzc2FnZSBleGNoYW5naW5nIHdo aWxlIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmllcnMgYXJlIGluZGVwZW5kZW50bHkNCj4gICBnZW5l cmF0ZWQgYnkgdGhlIGhvc3RzLiAgSXQgZW5hYmxlcyBib3RoIGludGVncmFsIGFkZHJlc3MgYXNz aWdubWVudA0KPiAgIGFuZCBzZWxmLWdlbmVyYXRlZCBhZGRyZXNzZXMgaW4gb25lIHNpbmdsZSBt ZWNoYW5pc20sIERIQ1B2Ni4gIEl0DQo+ICAgYWxzbyBlbmFibGVzIHN0YXRlbGVzcyBhZGRyZXNz IGNvbmZpZ3VyYXRpb24gd2l0aG91dCBSQSBhdHRlbmRhbmNlLg0KPg0KPg0KPlRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGhjLWhvc3QtZ2VuLWlkDQo+DQo+VGhlcmUn cyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtaG9zdC1nZW4taWQtMDMNCj4NCj5BIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cDovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kaGMtaG9zdC1nZW4taWQtMDMNCj4NCj4NCj5J bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmRoY3dnIG1haWxpbmcgbGlzdA0KPmRo Y3dnQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3 Zw0K From jiangsheng@huawei.com Tue Aug 21 19:11:41 2012 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 33DCA11E80F4 for ; Tue, 21 Aug 2012 19:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx2yWGFAXPdl for ; Tue, 21 Aug 2012 19:11:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C5B5811E8091 for ; Tue, 21 Aug 2012 19:11:39 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJJ05243; Tue, 21 Aug 2012 18:11:38 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Aug 2012 19:05:26 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Aug 2012 19:05:29 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.47]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Wed, 22 Aug 2012 10:05:22 +0800 From: Sheng Jiang To: "Bernie Volz (volz)" , Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+Bcg//+14QCAAI85gIAADPCAgAE0l2D//4WvgIAAHvOAgACIrLCACVarMA== Date: Wed, 22 Aug 2012 02:05:21 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F2241F@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-mbx.china.huawei.com> <388CD216-17F9-463E-8CDB-F084C9D43C54@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EBE06@xmb-rcd-x04.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F066A2@szxeml545-mbx.china.huawei.com>, <0E81DDB0-29DA-4B8F-A336-FDE9FDA663D2@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F067D3@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239F067D3@szxeml545-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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 22 Aug 2012 02:11:41 -0000 VGhlIGF1dGhvcnMgaGF2ZSBzdWJtaXR0ZWQgYW4gdXBkYXRlZCAwMyB2ZXJzaW9uIG9mIHRoaXMg ZHJhZnQgYWNjb3JkaW5nIHRvIHRoZSBsYXRlc3QgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbCBsaXN0 Lg0KDQpBbW9uZyB3aXRoIG1pbm9yIG1vZGlmaWNhdGlvbnMsIHRoZSBhdXRob3JzIGhhdmUgbGFy Z2VseSByZXdyaXR0ZW4gdGhlIGludHJvZHVjdGlvbi9tb3RpdmF0aW9uIHNlY3Rpb24sIGhvcGlu ZyB0aGlzIHdvdWxkIGNsYXJpZnkgdGhlIHRhcmdldCBzY2VuYXJpb3MuDQoNCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLWhvc3QtZ2VuLWlkLTAzDQoNCkRpc2N1c3Np b24vcmV2aWV3L2NvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5n DQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGRoY3dnLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBTaGVu ZyBKaWFuZw0KPlNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIwMTIgMTE6NDggQU0NCj5Ubzog QmVybmllIFZvbHogKHZvbHopOyBBbmRyZSBLb3N0dXINCj5DYzogZGhjIFdHOyBUZWQgTGVtb24N Cj5TdWJqZWN0OiBSZTogW2RoY3dnXSBXR0xDOiBkcmFmdC1pZXRmLWRoYy1ob3N0LWdlbi1pZC0w Mg0KPg0KPkhpLCBCZXJuaWUgYW5kIEFuZHJlDQo+DQo+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRz LiBBY3R1YWxseSwgd2UgYXJlIHF1aXRlIG9wZW4gdG8gZGlzY3Vzcy4gVGhlIG9ubHkNCj5yZWFz b24gd2UgcmVxdWVzdCBXR0xDIGlzIHRoZXJlIGlzIG5vIGFueSBkaXNjdXNzaW9uIGZvciB0aGlz IGRyYWZ0IGZvciBsYXN0IDEyDQo+bW9udGhzIGFuZCB3ZSBoYXZlIGFkZHJlc3NlZCBhbGwgY29t bWVudHMgd2UgcmVjZWl2ZWQuDQo+DQo+U2luY2UgeW91IGhhdmUgcmFpc2VkIG5ldyBkaXNjdXNz aW9uLCB3ZSBhcmUgaGFwcHkgdG8gZGVsYXkgdGhlIHByb2Nlc3MgdGlsbA0KPmFsbCBvcGVuIGlz c3VlcyBnZXQgYWRkcmVzc2VkLiBUaGlzIGlzIGdvb2QgZm9yIG91ciB3b3JrIHRvIGJlIHJlYWwg bWF0dXJlLiA6KQ0KPg0KPlNlZSBteSByZXBseSBpbiBsaW5lcy4NCj4NCj5TaGVuZw0KPg0KPj5X aGF0IGFib3V0IHRoZSBvdGhlciB0aGluZ3MgUkFzIHByb3ZpZGU/IFN1Y2ggYXMgdGhlIHJvdXRl cnMgYW5kIG9uLWxpbmsNCj4+bm90aWZpY2F0aW9uIC4uLiBBcmUgUkFzIGFjdGl2ZSBpbiB0aGVz ZSBuZXR3b3JrcyBvciBub3Q/DQo+DQo+VGhpcyB3b3JrIGRvZXMgTk9UIHJlcGxhY2UgbmVpZ2hi b3IgZGlzY292ZXJ5LiBSQSBpcyBhY3RpdmUgaW4gb3VyIHRhcmdldA0KPm5ldHdvcmsuIE5EIGlz IG1haW5seSBmb3IgcmVhY2hhYmlsaXR5L3JvdXRpbmcgcHVycG9zZS4NCj4NCj5UaGlzIHdvcmsg aXMgdG8gbWFrZSB0aGUgYWRkcmVzcyBjb25maWd1cmF0aW9uIGFsbCBieSBESENQdjYsIHJhdGhl ciB0aGFuIHBhcnQNCj5ieSBSQSwgcGFydCBieSBESENQdjYuIFdpdGggdGhlIGFzc3VtcHRpb24g dGhhdCBESENQdjYgdGFrZXMgb3ZlciBhbGwNCj5hZGRyZXNzIGNvbmZpZ3VyYXRpb24sIGFzc2ln bmluZyAxMjgtYml0IGFkZHJlc3MgaXMgaW5zdWZmaWNpZW50LiBTb21lIGhvc3QNCj53YW50IHRv IHVzZSBzZWxmLWdlbmVyYXRlZCBhZGRyZXNzLCBDR0EgaXMgb25seSBvbmUgZXhhbXBsZSwgb3Ro ZXJzDQo+aW5jbHVkaW5nIEVVSTY0IGFuZCBwcml2YWN5IGFkZHJlc3MuDQo+DQo+VGhpcyB3b3Jr IGlzIGEgZ2VuZXJpYyBwcmVmaXggYXNzaWdubWVudC9hbm5vdW5jZW1lbnQgbWVjaGFuaXNtLiBJ dCBpcw0KPmFsdGVybmF0aXZlIG9mIFJBIHByZWZpeCBhc3NpZ25tZW50L2Fubm91bmNlbWVudC4N Cj4NCj4NCj5kcmFmdC1pZXRmLWRoYy1zZWN1cmUtZGhjcHY2IGlzIG5vdGhpbmcgdG8gZG8gd2l0 aCBhZGRyZXNzIGNvbmZpZ3VyYXRpb24uIEl0IGlzDQo+QUZURVIgQ0dBIGFkZHJlc3NlcyBnZW5l cmF0ZWQsIHVzaW5nIHRoZW0gdG8gcHJvdGVjdCBESENQdjYgbWVzc2FnZQ0KPmV4Y2hhbmdpbmcu DQo+DQo+ZHJhZnQtaWV0Zi1kaGMtY2dhLWNvbmZpZy1kaGNwdjYgaXMgc3BlY2lmaWMgQ0dBIGNv bmZpZ3VyYXRpb24uIFNpbmNlIHdlDQo+c2VwYXJhdGVkIHByZWZpeCBhc3NpZ25tZW50IHRvIGJl IHRoaXMgZ2VuZXJpYyBtZWNoYW5pc20sIHRoYXQgZHJhZnQgaXMgb25seQ0KPmZvY3VzaW5nIG9u IENHQSBhcHByb3ZlIHByb2Nlc3MuIEhvd2V2ZXIsIGlmIHRoZSBkaXNjdXNzaW9uIHRoaW5rIHBy ZWZpeA0KPmFzc2lnbm1lbnQgaXMgb25seSBtZWFuaW5nZnVsIGZvciBDR0EsIHdlIGhhdmUgbm8g cHJvYmxlbSB0byBjb21iaW5lIHRoaXMNCj5iYWNrIHRvIENHQSBjb25maWd1cmF0aW9uIGRyYWZ0 Lg0KPg0KPkxldCdzIGZpcnN0IGRpc2N1c3MgdGhlIHJlcXVpcmVtZW50L3Byb2JsZW0gZmlyc3Qu IFdlIGNhbiBjb21lIGJhY2sgdG8NCj50ZWNobmljYWwgZGV0YWlscyBsYXRlci4NCj4NCj5SZWdh cmRzLA0KPg0KPlNoZW5nDQo+DQo+PkFsc28gaG93IGlzIHRoZSBjbGllbnQncyBhc3NpZ25tZW50 IG9mIGFkZHJlc3NlcyBjb25zaWRlcmVkDQo+PkRIQ1B2Ni1tYW5hZ2VkPw0KPj4NCj4+SG93IGlz IHRoaXMgYW55IGRpZmZlcmVudCBmcm9tIHN0YXRlbGVzcz8NCj4+DQo+PlRoZSBvbmx5IGRpZmZl cmVuY2Ugd2l0aCB0aGlzIG92ZXIgbm9ybWFsIHN0YXRlbGVzcyBpcyB0aGF0IHlvdSBjb3VsZCBn aXZlDQo+ZWFjaA0KPj5jbGllbnQgaXRzIG93biBwcmVmaXgsIHdoZXJlYXMgUkFzIGFyZSBzZW50 IHRvIGFsbCBkZXZpY2VzIG9uIHRoZSBsaW5rLiBCdXQgSQ0KPj5kb24ndCByZWNhbGwgdGhlIGRv Y3VtZW50IG1lbnRpb25pbmcgc3VjaCBhIG5ldHdvcmsgKGFuZCBpbiBzb21lIGNhc2VzDQo+Pndo ZXJlIHRoaXMgbWlnaHQgb2NjdXIsIHVzdWFsbHkgdGhlcmUgYXJlIHR1bm5lbHMgaW52b2x2ZWQg YW5kIHByb3RvY29scyBzdWNoDQo+PmFzIHBwcCkuIEFuZCB5b3Ugd291bGQgaGF2ZSB0byBkZXNj cmliZSBzdWNoIGEgbmV0d29yayBhbmQgZXhwbGFpbiB3aHkgUlNzDQo+PmFuZCBSQXMgYXJlIGlu c3VmZmljZW50IG9yIG5vdCB1c3VhYmxlL3ByYXRpY2FsLg0KPj4NCj4+V2hlbiB0aGUgd29ya2lu ZyBncm91cCBhZG9wdHMgYSBkb2N1bWVudCB0byB3b3JrIG9uLCB0aGF0IGRvZXMgbm90DQo+bWVh bg0KPj5pdCB3aWxsIG5lY2Vzc2FyaWx5IGFkdmFuY2UuIFNvbWV0aW1lcyBub3QgYWxsIG9mIHRo ZSBpc3N1ZXMgYXJlIHdlbGwNCj4+dW5kZXJzdG9vZCBlYXJseSBpbiB0aGUgcHJvY2Vzcy4gVGhl cmUgYXJlIG90aGVyIGNhc2VzIHdoZXJlIGl0IGNhbiB0YWtlDQo+bWFueQ0KPj55ZWFycyB0byB3 b3JrIG91dCB0aGUgZGV0YWlscyBhbmQgYWRkcmVzcyB0aGUgY29uY2VybnMgYmVmb3JlIHRoZSBk b2N1bWVudA0KPj5pcyByZWFkeS4gVGhlIHByb2Nlc3MgY2FuIGJlIGZydXN0cmF0aW5nIGFuZCBk ZW1vdGl2YXRpbmcuIEJ1dCB0aGUgcmVzdWx0IGlzDQo+PnVzdWFsbHkgZm9yIHRoZSBiZXN0Lg0K Pj4NCj4+QWxzbywgYXMgQ0dBcyBhcmUgbWVudGlvbmVkIGFzIG9uZSBwb3NzaWJsZSB1c2FnZSBt b2RlbCwgSSB0aGluayBpdCB3b3VsZA0KPj5hZ2FpbiBiZSBpbXBvcnRhbnQgdG8gdW5kZXJzdGFu ZCB3aHkgdGhlIG90aGVyIHdvcmtzIGluIHRoaXMgYXJlYQ0KPj4oZHJhZnQtaWV0Zi1kaGMtY2dh LWNvbmZpZy1kaGNwdjYgYW5kIGRyYWZ0LWlldGYtZGhjLXNlY3VyZS1kaGNwdjYpIGFyZSBub3QN Cj4+YXBwcm9wcmlhdGUgb3IgZG8gbm90IGNvdmVyIGFsbCBvZiB0aGUgcmVxdWlyZW1lbnRzIC0g YW5kIGl0IG1pZ2h0IGJlIHdvcnRoDQo+PmNvbnNpZGVyaW5nIHdvcmtpbmcgd2l0aCB0aG9zZSBh dXRob3JzPyBOb3RlIGFsc28gdGhhdCBpbiBub3JtYWwgREhDUHY2LA0KPj5jbGllbnRzIG1heSBy ZXF1ZXN0IGV4cGxpY2l0IGFkZHJlc3NlcyBhbmQgc28gdXNpbmcgQ0dBIGFkZHJlc3NlcyB2aWEN Cj5ESENQdjYNCj4+aXNuJ3QgaW1wb3NzaWJsZSAoc29tZSBzZXJ2ZXJzIGRvIHJlcXVpcmUgYSBy YW5nZSBvZiBhZGRyZXNzZXMgdG8gYmUNCj4+Y29uZmlndXJlZCBqdXN0IGxpa2UgZm9yIHY0LCBi dXQgSSBjb25zaWRlciB0aGF0IGFwcHJvYWNoIHRvIGxpbWl0IHdoYXQgdjYgaGFzDQo+dG8NCj4+ b2ZmZXIgLS0gdGhlIHNlcnZlciBJIHdvcmsgb24gZG9lcyBub3QgaGF2ZSB0aGlzIHJlc3RyaWN0 aW9uKS4NCj4+DQo+PkkgY2FuIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIHdvcmxkIGlzbid0IGFz IHNpbXBsZSBhcyB3ZSB3b3VsZCBsaWtlIC0gdGhlcmUNCj5hcmUNCj4+cGxlbnR5IG9mIGRldmlj ZXMgdGhhdCBvbmx5IHN1cHBvcnQgc3RhdGVsZXNzIGFuZCB0aGlzIG1ha2VzIHJ1bm5pbmcgYSAi ZnVsbHkiDQo+PkRIQ1B2NiBtYW5hZ2VkIG5ldHdvcmsgd2hlcmUgeW91IGRvbid0IGhhdmUgdG90 YWwgY29udHJvbCBvZiB0aGUgZGV2aWNlcw0KPj50aGF0IG1heSBjb25uZWN0IGltcG9zc2libGUu IEJ1dCBidWlsZGluZyBtb3JlIGNvbXBsZXhpdHkgYW5kIGNob2ljZXMgaW50bw0KPj5ESENQdjYg aGFyZGx5IHNlZW1zIGxpa2UgdGhlIGEgZ29vZCBhcHByb2FjaCB0byBzb2x2aW5nIHRoaXMgc2lu Y2UgaXQgd2lsbCBiZQ0KPj5ldmVuIGxvbmdlciBiZWZvcmUgYWxsIG9mIHRoZSBkZXZpY2VzIHN1 cHBvcnQgdGhlc2UgbmV3IGNvbmZpZ3VyYXRpb24NCj5tb2RlbHMNCj4+LSBvciBzb21lIG1heSBj aG9zZSBub3QgdG8gaW1wbGVtZW50IERIQ1B2NiBhdCBhbGwuDQo+Pg0KPj5Bbnl3YXksIGlmIEkg aGF2ZW4ndCBzYWlkIGl0IGJlZm9yZSBvciBpdCBpc24ndCB5ZXQgY2xlYXIsIEkgaGF2ZSBzZXJp b3VzDQo+b2JqZWN0aW9ucw0KPj50byBhZHZhbmNpbmcgdGhpcyB3b3JrIGluIGl0cyBjdXJyZW50 IGZvcm0gYW5kIGdpdmVuIGl0cyBjdXJyZW50IG1vdGl2YXRpb24uIElmDQo+PnRoZSByYXRpb25h bCBmb3IgbmVlZGluZyB0aGVzZSBjYXBhYmlsaXRpZXMgYW5kIGhvdyB0aGV5IGFyZSB1c2VkIGJl dHdlZW4NCj4+Y2xpZW50cywgcmVsYXlzLCBhbmQgc2VydmVycyBhbmQgdGhlIG5ldHdvcmsgYXJl IGV4cGxhaW5lZCwgSSB3aWxsIGJlIGhhcHB5IHRvDQo+PnJlbW92ZSBteSBvYmplY3Rpb25zLg0K Pj4NCj4+LSBCZXJuaWUNCj4+DQo+Pk9uIEF1ZyAxNSwgMjAxMiwgYXQgOTowOCBQTSwgIkFuZHJl IEtvc3R1ciIgPGFrb3N0dXJAaW5jb2duaXRvLmNvbT4NCj4+d3JvdGU6DQo+Pg0KPj4+IExlYXZp bmcgYXNpZGUgdGhlIGlzc3VlIG9mIHdoZXRoZXIgdGhpcyAicHJlZml4IGFubm91bmNlbWVudCIg c2hvdWxkDQo+Pj4gYmUgY2FycmllZCBvdmVyIERIQ1B2NiwgSSB3b25kZXIgaWYgdHJ5aW5nIHRv IGZpdCB0aGlzIGludG8gYW4NCj4+PiBJZGVudGl0eSBBc3NvY2lhdGlvbiBpc24ndCBxdWl0ZSBy aWdodCBzaW5jZSB0aGVyZSBpcyBubyBpZGVudGl0eSB0bw0KPj4+IGJlIG1hbmFnZWQ/ICAgUGVy aGFwcyBhIGNsZWFuZXIgc29sdXRpb24gd291bGQgYmUgZm9yIHRoZSBkZXZpY2UgdG8NCj4+PiBh c2sgZm9yIGFuIElBUFJFRklYIGluIGFuIE9STyBpbiBhbiBJbmZvcm1hdGlvbi1SZXF1ZXN0LCBh bmQgdGhlDQo+Pj4gc2VydmVyIGNhbiByZXBseSB3aXRoIGFuIElBUFJFRklYICh0aGF0IGlzbid0 IGluIGFueSBJQV8qIG9wdGlvbikuDQo+Pj4NCj4+PiBIYXZpbmcgc2FpZCB0aGF0LCBJJ20gd2l0 aCBUZWQgaW4gdGhhdCBJIGRvbid0IHF1aXRlIGdyYXNwIHdoeSB3ZSdyZQ0KPj4+IHRyeWluZyB0 byBkbyB0aGlzLiAgSXQgdGhlIG5ldHdvcmsgaXMgImZ1bGx5IERIQ1B2Ni1tYW5hZ2VkIiwgd291 bGRuJ3QNCj4+PiB0aGF0IG1lYW4gdGhhdCB0aGUgYWRtaW5pc3RyYXRvcnMgd291bGQgd2FudCB0 byBjb250cm9sIHRoZSBhZGRyZXNzDQo+Pj4gZ2VuZXJhdGlvbiBpbnN0ZWFkIG9mIGxlYXZpbmcg aXQgdXAgdG8gdGhlIGNsaWVudCB0byBkbyB3aXRoIGl0IGFzIGl0DQo+Pj4gd2lsbD8NCj4+Pg0K Pj4+IE9uIFdlZCwgQXVnIDE1LCAyMDEyIGF0IDU6NDkgUE0sIFNoZW5nIEppYW5nIDxqaWFuZ3No ZW5nQGh1YXdlaS5jb20+DQo+Pndyb3RlOg0KPj4+Pg0KPj4+PiBIaSwgQmVybmllLA0KPj4+Pg0K Pj4+Pg0KPj4+Pg0KPj4+PiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFNlZSBteSByZXBseSBp biBsaW5lcy4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gU2hlbmcNCj4+Pj4NCj4+Pj4NCj4+Pj4N Cj4+Pj4gSeKAmWQgYWxzbyBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgYmUgY2xhcmlmaWVkIChzZWN0 aW9uIDQsIGJ1bGxldCAyKToNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gICAgICBJZiB0aGVyZSBp cyBub3QgYSBwcm9wZXIgcHJlZml4IGF2YWlsYWJsZSwgYSBzdGF0dXMtDQo+Pj4+DQo+Pj4+ICAg ICAgY29kZSBpcyByZXR1cm5lZCB0byB0aGUgaG9zdCBhbmQgdGhlIHByb2NlZHVyZSBpcyB0ZXJt aW5hdGVkLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBXaGF0IHN0YXR1cyBjb2RlIGFuZCB3aGVy ZSBpcyB0aGlzIHN0YXR1cyBjb2RlIHJldHVybmVkLiBMZXTigJlzIGhvcGUgaXQNCj4+Pj4gZm9s bG93cyB0aGUgSUFfUEQgY29udmVudGlvbnMgKGVzcGVjaWFsbHkgaWYgd2Uga2VlcCB0aGUgSUFJ RCBpbiB0aGUNCj5JQV9QQSkuDQo+Pj4+IFRoZXJlIGlzIG5vIG5ldyBzdGF0dXMgY29kZSByZXF1 ZXN0ZWQsIGRvIGFwcGFyZW50bHkgaXQgaXMgb25lIG9mIHRoZQ0KPj4+PiBleGlzdGluZyBjb2Rl cyAoUkZDIDMzMTUvMzYzMyk/DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IDxTaGVuZz4gSXQgaXMg dGhlIGV4aXN0aW5nIE5vUHJlZml4QXZhaWwgc3RhdHVzIGNvZGUsIGRlZmluZWQgaW4gUkZDIDM2 MzMuDQo+Pj4+IEkgaGF2ZSBqdXN0IGFkZGVkIGFuIGV4cGxpY2l0IGV4cGxhbmF0aW9uIGZvciB0 aGlzLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGlzIHdvcmsgYWxzbyBz ZWVtcyB0byBiZSB0byByZXBsYWNpbmcgUm91dGVyIFNvbGljaXRhdGlvbi9Sb3V0ZXINCj4+Pj4g QWR2ZXJ0aXNlbWVudCBtZXNzYWdlcyB0byBhZHZlcnRpc2UgdGhlIHByZWZpeGVzIChmb3Igc3Rh dGVsZXNzDQo+Pj4+IGF1dG9jb25maWd1cmF0aW9uKS4gRG8gd2UgcmVhbGx5IHdhbnQgdGhpcy4g QW5kLCBtaWdodCBub3QgdGhpcyBiZQ0KPj5zb21ldGhpbmcNCj4+Pj4gdG8gZGlzY3VzcyBpbiBh IHNsaWdodGx5IHdpZGVyIElFVEYgYXVkaWVuY2UuIFBlcmhhcHMgaXQgaGFzIGFscmVhZHkgYmVl biAoSQ0KPj4+PiBoYXZlbuKAmXQgZm9sbG93ZWQgdGhpcyB3b3JrIHRoYXQgY2xvc2VseSkuDQo+ Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IDxTaGVuZz4gSXQgaXMgdGhlIGFzc3VtcHRpb24gd2UgdGFr ZS4gSSBiZWxpZXZlIHdlIGhhZCB0aGUgV0cNCj5jb25zZW5zdXMsDQo+Pj4+IGJ5IGFkb3B0aW5n IGFzIFdHIGRvY3VtZW50LiBCZWNhdXNlIHRoaXMgb25seSBoYXBwZW5zIGluIGEgZnVsbHkNCj4+ Pj4gREhDUHY2LW1hbmFnZWQgbmV0d29yaywgZG9lcyBub3QgaW1wYWN0IGFueSBvdGhlciBuZXR3 b3JrIHRoYXQgdXNlDQo+PlJBIGZvcg0KPj4+PiBTTEFDQywgc28gSSB0aGluayBkaXNjdXNzaW9u IGluIERIQyBpcyBlbm91Z2guDQo+Pj4NCj4+PiAtLQ0KPj4+IEFuZHJlIEtvc3R1cg0KPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gZGhjd2cg bWFpbGluZyBsaXN0DQo+Pj4gZGhjd2dAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5kaGN3ZyBtYWlsaW5nIGxpc3QNCj5kaGN3Z0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg== From volz@cisco.com Tue Aug 21 20:38:32 2012 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 E88E911E8097 for ; Tue, 21 Aug 2012 20:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEUx1BrUd-f2 for ; Tue, 21 Aug 2012 20:38:31 -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 836AB11E8091 for ; Tue, 21 Aug 2012 20:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14370; q=dns/txt; s=iport; t=1345606711; x=1346816311; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=fHER3tJRbaxFvi3dpMlEdBzCzf89P+l7o4AJFVzKGbE=; b=UnG5RmXHsrepfjpn6L9g6H7aup8OzN8A25GR6yj9UppB+LTjAkRXQ/KM oy5iZFcFO+zcxHdKmPzwMyRtMFG/JbjjpMA9ouGix0ow1Hm75J658wyXT CMQD64Jztki+lORdibiteIVai5cOmyVVFBTovLqISs8QAz+T2yCXK7INh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAA5TNFCtJXG8/2dsb2JhbAA8CYYBs25xgQeCIAEBAQQBAQEPARARMwcLDAYBCBEEAQEDAgYdAwIEJQsUAQgJAQQBDQUIEweHawuZIo0Ykx6BIYlnEQQFhXAyYAOWZo0ZgWaCYYFZCA X-IronPort-AV: E=Sophos;i="4.77,807,1336348800"; d="scan'208";a="110997442" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 22 Aug 2012 03:38:30 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7M3cUw0025658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Aug 2012 03:38:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Tue, 21 Aug 2012 22:38:29 -0500 From: "Bernie Volz (volz)" To: Sheng Jiang , Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-03 Thread-Index: Ac2AFqKIr/l0UPxTSEe//xSbfC8VdA== Date: Wed, 22 Aug 2012 03:38:29 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4EF172@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.89.10.112] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19130.001 x-tm-as-result: No--37.568200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-03 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, 22 Aug 2012 03:38:33 -0000 QSBmZXcgY29tbWVudHMgZnJvbSBhIHF1aWNrIGxvb2sgYXQgdGhlIDAzIGRvY3VtZW50Og0KDQot IEFuIEFkdmVydGlzZSBzaG91bGQgTkVWRVIgYXNzaWduIGFueXRoaW5nLiBBIFJlcGx5IGlzIHRo ZSBvbmx5IHRoaW5nIHRoYXQgY2FuIGRvIHRoYXQuIA0KDQogICAgICAgVGhlIERIQ1B2NiBzZXJ2 ZXIgYXNzaWducyBvbmUgb3IgbW9yZSBwcmVmaXhlcyB0byB0aGUgaG9zdCBpbg0KICAgICAgIEFk dmVydGlzZSBtZXNzYWdlcyBvciBpbiB0aGUgUmVwbHkgbWVzc2FnZXMgcmVzcG9uZGluZyB0byB0 aGUNCiAgICAgICBwcmVmaXggcmVxdWVzdHMgZnJvbSB0aGUgaG9zdHMuDQoNClRoZSBhc3NpZ25t ZW50IGRvZXNuJ3Qgb2NjdXIgdW50aWwgdGhlIFJlcGx5IChub3RlIGFsc28gdGhlICJvciIpLiBU aGlzIGlzIHZlcnkgYmFkIGFuZCB3ZSBzaG91bGQgbm90IGJlIG1pc2xlYWRpbmcgcGVvcGxlIHRo YXQgYWxsIHRoZXkgbmVlZCBpcyBTb2xpY2l0L0FkdmVydGlzZS4NCg0KLSBUaGlzIGRvY3VtZW50 IHN0aWxsIGZhaWxzIHRvIGNsYXJpZnkgdGhlIG9uLWxpbmsgc3RhdHVzIG9mIHRoZSBQQSBwcmVm aXggKEkgd291bGQgYXNzdW1lIGl0IGlzIE5PVCBvbi1saW5rIHVubGVzcyBzbyBhZHZlcnRpc2Vk IGluIGFuIFJBKS4gSSBoYXZlbid0IGxvb2tlZCBiYWNrIGF0IHRoZSBzdGF0ZWxlc3MgYXV0b2Nv bmZpZ3VyYXRpb24gZG9jdW1lbnQgdG8gc2VlIGlmIHRoZXJlIGlzIGFueXRoaW5nIGVsc2UgdGhh dCBhIFJBIFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb24gY29tbXVuaWNhdGVzIHRoYXQgbWlnaHQg YWxzbyBiZSBtaXNzaW5nIC0gb2J2aW91c2x5IHRoZSBBIChzdGF0ZWxlc3MpIGlzbid0IG5lZWQg c2luY2UgaXQgaXMgaW1wbGljaXQgaW4gdGhlIElBX1BBLg0KDQotIEkgd291bGQgdGhpbmsgaXQg d291bGQgaW1wcm92ZSB0aGluZ3MgdG8gbW92ZSB0aGUgNi4gQXBwbGljYWJpbGl0eSBzZWN0aW9u IHRvIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50IChmb3IgZXhhbXBsZSwgYWZ0ZXIgc2VjdGlvbiAx KS4NCg0KLSBJIHRoaW5rIHRoaXMgZG9jdW1lbnQgbmVlZHMgdG8gY2xhcmlmeSB3aGF0IGEgaG9z dCBkb2VzIGlmIHRoZSBzYW1lIHByZWZpeCBpcyBjb21tdW5pY2F0ZWQgKGZvciBlc3NlbnRpYWxs eSBzdGF0ZWxlc3MgdXNhZ2UpIHZpYSBib3RoIFJBcyBhbmQgREhDUHY2LiBGb3IgZXhhbXBsZSwg bXVzdCBpdCBjb250aW51ZSB0byByZW5ldyBpdCB3aXRoIHRoZSBESENQIHNlcnZlci4NCg0KLSBU aGVyZSBwcm9iYWJseSBuZWVkcyB0byBiZSBzb21lIHRleHQgcmVnYXJkaW5nIHNvbWUgY29uc2lk ZXJhdGlvbnMgZm9yIERIQ1Agc2VydmVycyBhbmQgY2xpZW50cy4gRm9yIGV4YW1wbGUsIGlmIGEg SUFfUEEgY2FwYWJsZSBjbGllbnQgY29ubmVjdHMgdG8gYSBuZXR3b3JrLCBhbmQgdGhlIERIQ1Ag c2VydmVyIGlzIG5vdCBJQV9QQSBjYXBhYmxlLCB0aGUgU29saWNpdCB3aWxsIHJlc3VsdCBpbiBu byBvciBBZHZlcnRpc2VzIHdpdGhvdXQgSUFfUEFzLiBBIGNsaWVudCBjb3VsZCBub3cgY29udGlu dWUgU29saWNpdGluZyAod2l0aCBhcHByb3ByaWF0ZSByZXRyYW5zbWlzc2lvbnMpIG9yIGl0IGNv dWxkICdmYWlsb3ZlcicgdG8gZG9pbmcgSUFfTkEvSUFfVEEgcmVxdWVzdHM/IE9yIHBlcmhhcHMg anVzdCB3YWl0IGZvciBzdGF0ZWxlc3MgKFJTL1JBKSB0byBlaXRoZXIgcHJvdmlkZSBpdCBzdGF0 ZWxlc3MgYXV0b2NvbmZpZ3VyYXRpb24gb3IgaW5kaWNhdGUgdGhhdCBpdCBzaG91bGQgZG8gREhD UCAod2l0aCBJQV9OQS9JQV9UQSk/IFBlcmhhcHMgYXJlIHJlYXNvbnMgZm9yIGVhY2ggb2YgdGhl c2UgYmVoYXZpb3JzLiBPciwgdGhlcmUgbWF5IGJlIGd1aWRhbmNlIGFib3V0IHdoZW4gdG8gdXNl IElBX1BBcyBpbiBTb2xpY2l0cyBhbmQgd2hlbiBub3Q/IEZvciBleGFtcGxlLCB1c2UgaXQgZm9y IHBvaW50LXRvLXBvaW50IGludGVyZmFjZXMgb25seT8gTm90ZSB0aGF0IEknbSBub3QgcHJvbW90 aW5nIG9uZSBjaG9pY2Ugb3ZlciBhbm90aGVyIC0gdGhhdCBpcyBmb3IgeW91IChhbmQgdGhlIFdH KSB0byBkZWNpZGUuDQoNCi0gUGVyaGFwcyBub3QgYWJzb2x1dGVseSBuZWNlc3NhcnkgKHNpbmNl IEkgd291bGQgaG9wZSBpdCBvYnZpb3VzKSwgYnV0IGl0IG1heSBiZSB1c2VmdWwgdG8gaW5kaWNh dGUgdGhhdCB0aGUgUERfRVhDTFVERSAoUkZDIDY2MDMpIG9wdGlvbiBtYXkgbm90IGJlIGVuY2Fw c3VsYXRlZCBpbiB0aGUgSUFQUkVGSVggb3B0aW9ucyB0aGF0IGFyZSBlbmNhcHN1bGF0ZWQgaW4g YW4gSUFfUEQ/IChSRkMgNjYwMyBpcyBwcmV0dHkgZGVwZW5kZW50IG9uIFBELikNCg0KLSBCZXJu aWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNoZW5nIEppYW5nIFttYWls dG86amlhbmdzaGVuZ0BodWF3ZWkuY29tXSANClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyMSwgMjAx MiAxMDowNSBQTQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KTsgQW5kcmUgS29zdHVyDQpDYzogZGhj IFdHOyBUZWQgTGVtb24NClN1YmplY3Q6IFJFOiBbZGhjd2ddIFdHTEM6IGRyYWZ0LWlldGYtZGhj LWhvc3QtZ2VuLWlkLTAyDQoNClRoZSBhdXRob3JzIGhhdmUgc3VibWl0dGVkIGFuIHVwZGF0ZWQg MDMgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IGFjY29yZGluZyB0byB0aGUgbGF0ZXN0IGRpc2N1c3Np b24gb24gdGhlIG1haWwgbGlzdC4NCg0KQW1vbmcgd2l0aCBtaW5vciBtb2RpZmljYXRpb25zLCB0 aGUgYXV0aG9ycyBoYXZlIGxhcmdlbHkgcmV3cml0dGVuIHRoZSBpbnRyb2R1Y3Rpb24vbW90aXZh dGlvbiBzZWN0aW9uLCBob3BpbmcgdGhpcyB3b3VsZCBjbGFyaWZ5IHRoZSB0YXJnZXQgc2NlbmFy aW9zLg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1ob3N0LWdl bi1pZC0wMw0KDQpEaXNjdXNzaW9uL3Jldmlldy9jb21tZW50cyBhcmUgd2VsY29tZS4NCg0KQmVz dCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9t OiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmDQo+T2YgU2hlbmcgSmlhbmcNCj5TZW50OiBUaHVyc2RheSwgQXVndXN0IDE2LCAy MDEyIDExOjQ4IEFNDQo+VG86IEJlcm5pZSBWb2x6ICh2b2x6KTsgQW5kcmUgS29zdHVyDQo+Q2M6 IGRoYyBXRzsgVGVkIExlbW9uDQo+U3ViamVjdDogUmU6IFtkaGN3Z10gV0dMQzogZHJhZnQtaWV0 Zi1kaGMtaG9zdC1nZW4taWQtMDINCj4NCj5IaSwgQmVybmllIGFuZCBBbmRyZQ0KPg0KPlRoYW5r cyBmb3IgeW91ciBjb21tZW50cy4gQWN0dWFsbHksIHdlIGFyZSBxdWl0ZSBvcGVuIHRvIGRpc2N1 c3MuIFRoZSBvbmx5DQo+cmVhc29uIHdlIHJlcXVlc3QgV0dMQyBpcyB0aGVyZSBpcyBubyBhbnkg ZGlzY3Vzc2lvbiBmb3IgdGhpcyBkcmFmdCBmb3IgbGFzdCAxMg0KPm1vbnRocyBhbmQgd2UgaGF2 ZSBhZGRyZXNzZWQgYWxsIGNvbW1lbnRzIHdlIHJlY2VpdmVkLg0KPg0KPlNpbmNlIHlvdSBoYXZl IHJhaXNlZCBuZXcgZGlzY3Vzc2lvbiwgd2UgYXJlIGhhcHB5IHRvIGRlbGF5IHRoZSBwcm9jZXNz IHRpbGwNCj5hbGwgb3BlbiBpc3N1ZXMgZ2V0IGFkZHJlc3NlZC4gVGhpcyBpcyBnb29kIGZvciBv dXIgd29yayB0byBiZSByZWFsIG1hdHVyZS4gOikNCj4NCj5TZWUgbXkgcmVwbHkgaW4gbGluZXMu DQo+DQo+U2hlbmcNCj4NCj4+V2hhdCBhYm91dCB0aGUgb3RoZXIgdGhpbmdzIFJBcyBwcm92aWRl PyBTdWNoIGFzIHRoZSByb3V0ZXJzIGFuZCBvbi1saW5rDQo+Pm5vdGlmaWNhdGlvbiAuLi4gQXJl IFJBcyBhY3RpdmUgaW4gdGhlc2UgbmV0d29ya3Mgb3Igbm90Pw0KPg0KPlRoaXMgd29yayBkb2Vz IE5PVCByZXBsYWNlIG5laWdoYm9yIGRpc2NvdmVyeS4gUkEgaXMgYWN0aXZlIGluIG91ciB0YXJn ZXQNCj5uZXR3b3JrLiBORCBpcyBtYWlubHkgZm9yIHJlYWNoYWJpbGl0eS9yb3V0aW5nIHB1cnBv c2UuDQo+DQo+VGhpcyB3b3JrIGlzIHRvIG1ha2UgdGhlIGFkZHJlc3MgY29uZmlndXJhdGlvbiBh bGwgYnkgREhDUHY2LCByYXRoZXIgdGhhbiBwYXJ0DQo+YnkgUkEsIHBhcnQgYnkgREhDUHY2LiBX aXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgREhDUHY2IHRha2VzIG92ZXIgYWxsDQo+YWRkcmVzcyBj b25maWd1cmF0aW9uLCBhc3NpZ25pbmcgMTI4LWJpdCBhZGRyZXNzIGlzIGluc3VmZmljaWVudC4g U29tZSBob3N0DQo+d2FudCB0byB1c2Ugc2VsZi1nZW5lcmF0ZWQgYWRkcmVzcywgQ0dBIGlzIG9u bHkgb25lIGV4YW1wbGUsIG90aGVycw0KPmluY2x1ZGluZyBFVUk2NCBhbmQgcHJpdmFjeSBhZGRy ZXNzLg0KPg0KPlRoaXMgd29yayBpcyBhIGdlbmVyaWMgcHJlZml4IGFzc2lnbm1lbnQvYW5ub3Vu Y2VtZW50IG1lY2hhbmlzbS4gSXQgaXMNCj5hbHRlcm5hdGl2ZSBvZiBSQSBwcmVmaXggYXNzaWdu bWVudC9hbm5vdW5jZW1lbnQuDQo+DQo+DQo+ZHJhZnQtaWV0Zi1kaGMtc2VjdXJlLWRoY3B2NiBp cyBub3RoaW5nIHRvIGRvIHdpdGggYWRkcmVzcyBjb25maWd1cmF0aW9uLiBJdCBpcw0KPkFGVEVS IENHQSBhZGRyZXNzZXMgZ2VuZXJhdGVkLCB1c2luZyB0aGVtIHRvIHByb3RlY3QgREhDUHY2IG1l c3NhZ2UNCj5leGNoYW5naW5nLg0KPg0KPmRyYWZ0LWlldGYtZGhjLWNnYS1jb25maWctZGhjcHY2 IGlzIHNwZWNpZmljIENHQSBjb25maWd1cmF0aW9uLiBTaW5jZSB3ZQ0KPnNlcGFyYXRlZCBwcmVm aXggYXNzaWdubWVudCB0byBiZSB0aGlzIGdlbmVyaWMgbWVjaGFuaXNtLCB0aGF0IGRyYWZ0IGlz IG9ubHkNCj5mb2N1c2luZyBvbiBDR0EgYXBwcm92ZSBwcm9jZXNzLiBIb3dldmVyLCBpZiB0aGUg ZGlzY3Vzc2lvbiB0aGluayBwcmVmaXgNCj5hc3NpZ25tZW50IGlzIG9ubHkgbWVhbmluZ2Z1bCBm b3IgQ0dBLCB3ZSBoYXZlIG5vIHByb2JsZW0gdG8gY29tYmluZSB0aGlzDQo+YmFjayB0byBDR0Eg Y29uZmlndXJhdGlvbiBkcmFmdC4NCj4NCj5MZXQncyBmaXJzdCBkaXNjdXNzIHRoZSByZXF1aXJl bWVudC9wcm9ibGVtIGZpcnN0LiBXZSBjYW4gY29tZSBiYWNrIHRvDQo+dGVjaG5pY2FsIGRldGFp bHMgbGF0ZXIuDQo+DQo+UmVnYXJkcywNCj4NCj5TaGVuZw0KPg0KPj5BbHNvIGhvdyBpcyB0aGUg Y2xpZW50J3MgYXNzaWdubWVudCBvZiBhZGRyZXNzZXMgY29uc2lkZXJlZA0KPj5ESENQdjYtbWFu YWdlZD8NCj4+DQo+PkhvdyBpcyB0aGlzIGFueSBkaWZmZXJlbnQgZnJvbSBzdGF0ZWxlc3M/DQo+ Pg0KPj5UaGUgb25seSBkaWZmZXJlbmNlIHdpdGggdGhpcyBvdmVyIG5vcm1hbCBzdGF0ZWxlc3Mg aXMgdGhhdCB5b3UgY291bGQgZ2l2ZQ0KPmVhY2gNCj4+Y2xpZW50IGl0cyBvd24gcHJlZml4LCB3 aGVyZWFzIFJBcyBhcmUgc2VudCB0byBhbGwgZGV2aWNlcyBvbiB0aGUgbGluay4gQnV0IEkNCj4+ ZG9uJ3QgcmVjYWxsIHRoZSBkb2N1bWVudCBtZW50aW9uaW5nIHN1Y2ggYSBuZXR3b3JrIChhbmQg aW4gc29tZSBjYXNlcw0KPj53aGVyZSB0aGlzIG1pZ2h0IG9jY3VyLCB1c3VhbGx5IHRoZXJlIGFy ZSB0dW5uZWxzIGludm9sdmVkIGFuZCBwcm90b2NvbHMgc3VjaA0KPj5hcyBwcHApLiBBbmQgeW91 IHdvdWxkIGhhdmUgdG8gZGVzY3JpYmUgc3VjaCBhIG5ldHdvcmsgYW5kIGV4cGxhaW4gd2h5IFJT cw0KPj5hbmQgUkFzIGFyZSBpbnN1ZmZpY2VudCBvciBub3QgdXN1YWJsZS9wcmF0aWNhbC4NCj4+ DQo+PldoZW4gdGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRzIGEgZG9jdW1lbnQgdG8gd29yayBvbiwg dGhhdCBkb2VzIG5vdA0KPm1lYW4NCj4+aXQgd2lsbCBuZWNlc3NhcmlseSBhZHZhbmNlLiBTb21l dGltZXMgbm90IGFsbCBvZiB0aGUgaXNzdWVzIGFyZSB3ZWxsDQo+PnVuZGVyc3Rvb2QgZWFybHkg aW4gdGhlIHByb2Nlc3MuIFRoZXJlIGFyZSBvdGhlciBjYXNlcyB3aGVyZSBpdCBjYW4gdGFrZQ0K Pm1hbnkNCj4+eWVhcnMgdG8gd29yayBvdXQgdGhlIGRldGFpbHMgYW5kIGFkZHJlc3MgdGhlIGNv bmNlcm5zIGJlZm9yZSB0aGUgZG9jdW1lbnQNCj4+aXMgcmVhZHkuIFRoZSBwcm9jZXNzIGNhbiBi ZSBmcnVzdHJhdGluZyBhbmQgZGVtb3RpdmF0aW5nLiBCdXQgdGhlIHJlc3VsdCBpcw0KPj51c3Vh bGx5IGZvciB0aGUgYmVzdC4NCj4+DQo+PkFsc28sIGFzIENHQXMgYXJlIG1lbnRpb25lZCBhcyBv bmUgcG9zc2libGUgdXNhZ2UgbW9kZWwsIEkgdGhpbmsgaXQgd291bGQNCj4+YWdhaW4gYmUgaW1w b3J0YW50IHRvIHVuZGVyc3RhbmQgd2h5IHRoZSBvdGhlciB3b3JrcyBpbiB0aGlzIGFyZWENCj4+ KGRyYWZ0LWlldGYtZGhjLWNnYS1jb25maWctZGhjcHY2IGFuZCBkcmFmdC1pZXRmLWRoYy1zZWN1 cmUtZGhjcHY2KSBhcmUgbm90DQo+PmFwcHJvcHJpYXRlIG9yIGRvIG5vdCBjb3ZlciBhbGwgb2Yg dGhlIHJlcXVpcmVtZW50cyAtIGFuZCBpdCBtaWdodCBiZSB3b3J0aA0KPj5jb25zaWRlcmluZyB3 b3JraW5nIHdpdGggdGhvc2UgYXV0aG9ycz8gTm90ZSBhbHNvIHRoYXQgaW4gbm9ybWFsIERIQ1B2 NiwNCj4+Y2xpZW50cyBtYXkgcmVxdWVzdCBleHBsaWNpdCBhZGRyZXNzZXMgYW5kIHNvIHVzaW5n IENHQSBhZGRyZXNzZXMgdmlhDQo+REhDUHY2DQo+Pmlzbid0IGltcG9zc2libGUgKHNvbWUgc2Vy dmVycyBkbyByZXF1aXJlIGEgcmFuZ2Ugb2YgYWRkcmVzc2VzIHRvIGJlDQo+PmNvbmZpZ3VyZWQg anVzdCBsaWtlIGZvciB2NCwgYnV0IEkgY29uc2lkZXIgdGhhdCBhcHByb2FjaCB0byBsaW1pdCB3 aGF0IHY2IGhhcw0KPnRvDQo+Pm9mZmVyIC0tIHRoZSBzZXJ2ZXIgSSB3b3JrIG9uIGRvZXMgbm90 IGhhdmUgdGhpcyByZXN0cmljdGlvbikuDQo+Pg0KPj5JIGNhbiBhZ3JlZSB3aXRoIHlvdSB0aGF0 IHRoZSB3b3JsZCBpc24ndCBhcyBzaW1wbGUgYXMgd2Ugd291bGQgbGlrZSAtIHRoZXJlDQo+YXJl DQo+PnBsZW50eSBvZiBkZXZpY2VzIHRoYXQgb25seSBzdXBwb3J0IHN0YXRlbGVzcyBhbmQgdGhp cyBtYWtlcyBydW5uaW5nIGEgImZ1bGx5Ig0KPj5ESENQdjYgbWFuYWdlZCBuZXR3b3JrIHdoZXJl IHlvdSBkb24ndCBoYXZlIHRvdGFsIGNvbnRyb2wgb2YgdGhlIGRldmljZXMNCj4+dGhhdCBtYXkg Y29ubmVjdCBpbXBvc3NpYmxlLiBCdXQgYnVpbGRpbmcgbW9yZSBjb21wbGV4aXR5IGFuZCBjaG9p Y2VzIGludG8NCj4+REhDUHY2IGhhcmRseSBzZWVtcyBsaWtlIHRoZSBhIGdvb2QgYXBwcm9hY2gg dG8gc29sdmluZyB0aGlzIHNpbmNlIGl0IHdpbGwgYmUNCj4+ZXZlbiBsb25nZXIgYmVmb3JlIGFs bCBvZiB0aGUgZGV2aWNlcyBzdXBwb3J0IHRoZXNlIG5ldyBjb25maWd1cmF0aW9uDQo+bW9kZWxz DQo+Pi0gb3Igc29tZSBtYXkgY2hvc2Ugbm90IHRvIGltcGxlbWVudCBESENQdjYgYXQgYWxsLg0K Pj4NCj4+QW55d2F5LCBpZiBJIGhhdmVuJ3Qgc2FpZCBpdCBiZWZvcmUgb3IgaXQgaXNuJ3QgeWV0 IGNsZWFyLCBJIGhhdmUgc2VyaW91cw0KPm9iamVjdGlvbnMNCj4+dG8gYWR2YW5jaW5nIHRoaXMg d29yayBpbiBpdHMgY3VycmVudCBmb3JtIGFuZCBnaXZlbiBpdHMgY3VycmVudCBtb3RpdmF0aW9u LiBJZg0KPj50aGUgcmF0aW9uYWwgZm9yIG5lZWRpbmcgdGhlc2UgY2FwYWJpbGl0aWVzIGFuZCBo b3cgdGhleSBhcmUgdXNlZCBiZXR3ZWVuDQo+PmNsaWVudHMsIHJlbGF5cywgYW5kIHNlcnZlcnMg YW5kIHRoZSBuZXR3b3JrIGFyZSBleHBsYWluZWQsIEkgd2lsbCBiZSBoYXBweSB0bw0KPj5yZW1v dmUgbXkgb2JqZWN0aW9ucy4NCj4+DQo+Pi0gQmVybmllDQo+Pg0KPj5PbiBBdWcgMTUsIDIwMTIs IGF0IDk6MDggUE0sICJBbmRyZSBLb3N0dXIiIDxha29zdHVyQGluY29nbml0by5jb20+DQo+Pndy b3RlOg0KPj4NCj4+PiBMZWF2aW5nIGFzaWRlIHRoZSBpc3N1ZSBvZiB3aGV0aGVyIHRoaXMgInBy ZWZpeCBhbm5vdW5jZW1lbnQiIHNob3VsZA0KPj4+IGJlIGNhcnJpZWQgb3ZlciBESENQdjYsIEkg d29uZGVyIGlmIHRyeWluZyB0byBmaXQgdGhpcyBpbnRvIGFuDQo+Pj4gSWRlbnRpdHkgQXNzb2Np YXRpb24gaXNuJ3QgcXVpdGUgcmlnaHQgc2luY2UgdGhlcmUgaXMgbm8gaWRlbnRpdHkgdG8NCj4+ PiBiZSBtYW5hZ2VkPyAgIFBlcmhhcHMgYSBjbGVhbmVyIHNvbHV0aW9uIHdvdWxkIGJlIGZvciB0 aGUgZGV2aWNlIHRvDQo+Pj4gYXNrIGZvciBhbiBJQVBSRUZJWCBpbiBhbiBPUk8gaW4gYW4gSW5m b3JtYXRpb24tUmVxdWVzdCwgYW5kIHRoZQ0KPj4+IHNlcnZlciBjYW4gcmVwbHkgd2l0aCBhbiBJ QVBSRUZJWCAodGhhdCBpc24ndCBpbiBhbnkgSUFfKiBvcHRpb24pLg0KPj4+DQo+Pj4gSGF2aW5n IHNhaWQgdGhhdCwgSSdtIHdpdGggVGVkIGluIHRoYXQgSSBkb24ndCBxdWl0ZSBncmFzcCB3aHkg d2UncmUNCj4+PiB0cnlpbmcgdG8gZG8gdGhpcy4gIEl0IHRoZSBuZXR3b3JrIGlzICJmdWxseSBE SENQdjYtbWFuYWdlZCIsIHdvdWxkbid0DQo+Pj4gdGhhdCBtZWFuIHRoYXQgdGhlIGFkbWluaXN0 cmF0b3JzIHdvdWxkIHdhbnQgdG8gY29udHJvbCB0aGUgYWRkcmVzcw0KPj4+IGdlbmVyYXRpb24g aW5zdGVhZCBvZiBsZWF2aW5nIGl0IHVwIHRvIHRoZSBjbGllbnQgdG8gZG8gd2l0aCBpdCBhcyBp dA0KPj4+IHdpbGw/DQo+Pj4NCj4+PiBPbiBXZWQsIEF1ZyAxNSwgMjAxMiBhdCA1OjQ5IFBNLCBT aGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPg0KPj53cm90ZToNCj4+Pj4NCj4+Pj4g SGksIEJlcm5pZSwNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhhbmtzIGZvciB5b3VyIGNvbW1l bnRzLiBTZWUgbXkgcmVwbHkgaW4gbGluZXMuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IFNoZW5n DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IEnigJlkIGFsc28gc3VnZ2VzdCB0aGUgZm9sbG93aW5n IGJlIGNsYXJpZmllZCAoc2VjdGlvbiA0LCBidWxsZXQgMik6DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+ Pj4+ICAgICAgSWYgdGhlcmUgaXMgbm90IGEgcHJvcGVyIHByZWZpeCBhdmFpbGFibGUsIGEgc3Rh dHVzLQ0KPj4+Pg0KPj4+PiAgICAgIGNvZGUgaXMgcmV0dXJuZWQgdG8gdGhlIGhvc3QgYW5kIHRo ZSBwcm9jZWR1cmUgaXMgdGVybWluYXRlZC4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gV2hhdCBz dGF0dXMgY29kZSBhbmQgd2hlcmUgaXMgdGhpcyBzdGF0dXMgY29kZSByZXR1cm5lZC4gTGV04oCZ cyBob3BlIGl0DQo+Pj4+IGZvbGxvd3MgdGhlIElBX1BEIGNvbnZlbnRpb25zIChlc3BlY2lhbGx5 IGlmIHdlIGtlZXAgdGhlIElBSUQgaW4gdGhlDQo+SUFfUEEpLg0KPj4+PiBUaGVyZSBpcyBubyBu ZXcgc3RhdHVzIGNvZGUgcmVxdWVzdGVkLCBkbyBhcHBhcmVudGx5IGl0IGlzIG9uZSBvZiB0aGUN Cj4+Pj4gZXhpc3RpbmcgY29kZXMgKFJGQyAzMzE1LzM2MzMpPw0KPj4+Pg0KPj4+Pg0KPj4+Pg0K Pj4+PiA8U2hlbmc+IEl0IGlzIHRoZSBleGlzdGluZyBOb1ByZWZpeEF2YWlsIHN0YXR1cyBjb2Rl LCBkZWZpbmVkIGluIFJGQyAzNjMzLg0KPj4+PiBJIGhhdmUganVzdCBhZGRlZCBhbiBleHBsaWNp dCBleHBsYW5hdGlvbiBmb3IgdGhpcy4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+ Pj4gVGhpcyB3b3JrIGFsc28gc2VlbXMgdG8gYmUgdG8gcmVwbGFjaW5nIFJvdXRlciBTb2xpY2l0 YXRpb24vUm91dGVyDQo+Pj4+IEFkdmVydGlzZW1lbnQgbWVzc2FnZXMgdG8gYWR2ZXJ0aXNlIHRo ZSBwcmVmaXhlcyAoZm9yIHN0YXRlbGVzcw0KPj4+PiBhdXRvY29uZmlndXJhdGlvbikuIERvIHdl IHJlYWxseSB3YW50IHRoaXMuIEFuZCwgbWlnaHQgbm90IHRoaXMgYmUNCj4+c29tZXRoaW5nDQo+ Pj4+IHRvIGRpc2N1c3MgaW4gYSBzbGlnaHRseSB3aWRlciBJRVRGIGF1ZGllbmNlLiBQZXJoYXBz IGl0IGhhcyBhbHJlYWR5IGJlZW4gKEkNCj4+Pj4gaGF2ZW7igJl0IGZvbGxvd2VkIHRoaXMgd29y ayB0aGF0IGNsb3NlbHkpLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiA8U2hlbmc+IEl0IGlzIHRo ZSBhc3N1bXB0aW9uIHdlIHRha2UuIEkgYmVsaWV2ZSB3ZSBoYWQgdGhlIFdHDQo+Y29uc2Vuc3Vz LA0KPj4+PiBieSBhZG9wdGluZyBhcyBXRyBkb2N1bWVudC4gQmVjYXVzZSB0aGlzIG9ubHkgaGFw cGVucyBpbiBhIGZ1bGx5DQo+Pj4+IERIQ1B2Ni1tYW5hZ2VkIG5ldHdvcmssIGRvZXMgbm90IGlt cGFjdCBhbnkgb3RoZXIgbmV0d29yayB0aGF0IHVzZQ0KPj5SQSBmb3INCj4+Pj4gU0xBQ0MsIHNv IEkgdGhpbmsgZGlzY3Vzc2lvbiBpbiBESEMgaXMgZW5vdWdoLg0KPj4+DQo+Pj4gLS0NCj4+PiBB bmRyZSBLb3N0dXINCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IGRoY3dnIG1haWxpbmcgbGlzdA0KPj4+IGRoY3dnQGlldGYub3JnDQo+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZGhjd2cgbWFpbGluZyBs aXN0DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RoY3dnDQo= From mohamed.boucadair@orange.com Fri Aug 24 04:49:28 2012 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 BC2D021F8705 for ; Fri, 24 Aug 2012 04:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7hMuH5xPoUj for ; Fri, 24 Aug 2012 04:49:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EA62321F86A2 for ; Fri, 24 Aug 2012 04:49:27 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0CAAE2DC5BA for ; Fri, 24 Aug 2012 13:49:27 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EA98423804B for ; Fri, 24 Aug 2012 13:49:26 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 24 Aug 2012 13:49:04 +0200 From: To: "dhcwg@ietf.org" Date: Fri, 24 Aug 2012 13:49:03 +0200 Thread-Topic: RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGA Message-ID: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.24.105415 Subject: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 24 Aug 2012 11:49:28 -0000 Dear all, I submitted a new I-D defining a new message type to trigger a server to is= sue a RECONFIGURE message when RSSO is used. The text is available at: https://datatracker.ietf.org/doc/draft-boucadair-= dhc-triggered-reconfigure Comments and suggestions are more than welcome.=20 Cheers, Med= From Ted.Lemon@nominum.com Fri Aug 24 06:44:07 2012 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 681AC21F8686 for ; Fri, 24 Aug 2012 06:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKRmlneLkcKM for ; Fri, 24 Aug 2012 06:44:05 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9216221F865B for ; Fri, 24 Aug 2012 06:44:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUDeFJUwHL2tPYPhraIeTkr9qZOh9rHG9@postini.com; Fri, 24 Aug 2012 06:44: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 85FF91B82B9 for ; Fri, 24 Aug 2012 06:44:04 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 7350919005C; Fri, 24 Aug 2012 06:44:04 -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.02.0247.003; Fri, 24 Aug 2012 06:43:58 -0700 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGAABLMSoA= Date: Fri, 24 Aug 2012 13:43:58 +0000 Message-ID: <264AF650-EB56-4C12-9A1D-F1A92FEACB39@nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> 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: multipart/alternative; boundary="_000_264AF650EB564C129A1DF1A92FEACB39nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 24 Aug 2012 13:44:07 -0000 --_000_264AF650EB564C129A1DF1A92FEACB39nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com wrote: Comments and suggestions are more than welcome. In section 2, you propose that the reconfigure-request include an RSOO, but= this is actually not necessary; what will happen is that the RECONFIGURE-R= EQUEST will trigger a RECONFIGURE, the client will then send a RENEW, the r= elay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAM= E option, and the DHCP server will send a REPLY containing the AFTR_NAME op= tion. So there's no need to include that in the RECONFIGURE-REQUEST. Th= is is a minor point--it would certainly do no _harm_ to include the AFTR_NA= ME option in the RSOO on the RECONFIGURE-REQUEST. So of course if you make this change, you'd have to fix up section 3.2. I would also change this, in section 3.2: If the server is configured to reject RECONFIGURE-REQUEST, any received REC= ONFIGURE-REQUEST is silently dropped. To this: If the server is configured to reject RECONFIGURE-REQUEST, the server MUST = silently discard any RECONFIGURE-REQUEST it receives. It might be good to consistently say "silently discard" instead of "discard= " in that section. Section 3.3 also mentions sending the RSOO, and, if you accept my argument = above, should not. In addition to the issues discussed in the Security Considerations section = of RFC5007, you might also want to add this (possibly to section 3.2, not t= o the Security Considerations section): Because this message provides a mechanism for triggering the DHCP Reconfigu= re message, and the DHCP Reconfigure message can be used by an attacker to = control the timing of a DHCP renewal, the DHCP server must have some mechan= ism for determining that the relay agent is a trusted entity. RECONFIGURE= -REQUEST messages originating from unknown relay agents MUST be silently dr= opped. Aside from this, the document looks good, and seems useful. Are you propo= sing that the working group should adopt this work? --_000_264AF650EB564C129A1DF1A92FEACB39nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9F34C5D822A43844BA509AA32B1D723A@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com wrote:
Comments and suggestions are more than welcome. 

In section 2, you propose that the reconfigure-request include an RSOO= , but this is actually not necessary; what will happen is that the RECONFIG= URE-REQUEST will trigger a RECONFIGURE, the client will then send a RENEW, = the relay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAME option, and the DHCP serv= er will send a REPLY containing the AFTR_NAME option.   So there's no = need to include that in the RECONFIGURE-REQUEST.   This is a minor poi= nt--it would certainly do no _harm_ to include the AFTR_NAME option in the RSOO on the RECONFIGURE-REQUEST.

So of course if you make this change, you'd have to fix up section 3.2= .

I would also change this, in section 3.2:

If the server is configured to reject RECONFIGURE-REQUEST, a=
ny received RECONFIGURE-REQUEST is silently dropped.

To this:

If the server is configured to reject RECONFIGURE-REQUEST, t=
he server MUST silently discard any RECONFIGURE-REQUEST it receives.

It might be good to consistently say "silently discard" inst= ead of "discard" in that section.

Section 3.3 also mentions sending the RSOO, and, if you accept my argu= ment above, should not.

In addition to the issues discussed in the Security Considerations sec= tion of RFC5007, you might also want to add this (possibly to section 3.2, = not to the Security Considerations section):

Because this message provides a mechanism for triggering the DHCP Reco= nfigure message, and the DHCP Reconfigure message can be used by an attacke= r to control the timing of a DHCP renewal, the DHCP server must have some m= echanism for determining that the relay agent is a trusted entity.   RECONFIGURE-REQUEST messages origi= nating from unknown relay agents MUST be silently dropped.

Aside from this, the document looks good, and seems useful.   Are= you proposing that the working group should adopt this work?

--_000_264AF650EB564C129A1DF1A92FEACB39nominumcom_-- From roberta.maglione@telecomitalia.it Fri Aug 24 07:33:39 2012 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 E09EF21F86CB for ; Fri, 24 Aug 2012 07:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjbbYhab0gcc for ; Fri, 24 Aug 2012 07:33:39 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id DAD8921F86C2 for ; Fri, 24 Aug 2012 07:33:38 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 24 Aug 2012 16:33:33 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 24 Aug 2012 16:33:33 +0200 From: Maglione Roberta To: "'mohamed.boucadair@orange.com'" Date: Fri, 24 Aug 2012 16:33:33 +0200 Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGAAAWJUTA= Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519702F16B@GRFMBX704BA020.griffon.local> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Ullio Mario Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 24 Aug 2012 14:33:40 -0000 Hi Med, I read the draft and I think this is an interesting work. I have few comments: - I would suggest adding an informative reference to RFC5176 where you talk= about CoA messages; - I would suggest replacing the Radius Server entity originating Change of = Authorization (CoA) Requests with Dynamic Authorization Client (DAC), becau= se according to RFC 5176 "While it is possible that the DAC is co-resident = with a RADIUS authentication or accounting server, this need not necessaril= y be the case." - minor/editorial: in figures 2 and 3 I would replace AFTR_NAME with DS-Li= te-Tunnel-Name (RFC6519) into the RADIUS messages and OPTION_AFTR_NAME (RFC= 6334) into the DHCPv6 messages. Thanks Best Regards -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of m= ohamed.boucadair@orange.com Sent: venerd=EC 24 agosto 2012 13.49 To: dhcwg@ietf.org Subject: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucad= air-dhc-triggered-reconfigure) Dear all, I submitted a new I-D defining a new message type to trigger a server to is= sue a RECONFIGURE message when RSSO is used. The text is available at: https://datatracker.ietf.org/doc/draft-boucadair-= dhc-triggered-reconfigure Comments and suggestions are more than welcome. Cheers, Med _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From mohamed.boucadair@orange.com Fri Aug 24 07:40:20 2012 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 A92BD21F86E0 for ; Fri, 24 Aug 2012 07:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFzDd8deqnpx for ; Fri, 24 Aug 2012 07:40:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC4121F8683 for ; Fri, 24 Aug 2012 07:40:19 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 9B2343B421F; Fri, 24 Aug 2012 16:40:18 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 74B3A35C045; Fri, 24 Aug 2012 16:40:18 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 24 Aug 2012 16:39:56 +0200 From: To: Ted Lemon Date: Fri, 24 Aug 2012 16:39:54 +0200 Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGAABLMSoAADm1sMA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E5332AACB@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> <264AF650-EB56-4C12-9A1D-F1A92FEACB39@nominum.com> In-Reply-To: <264AF650-EB56-4C12-9A1D-F1A92FEACB39@nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E5332AACBPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.24.130320 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 24 Aug 2012 14:40:20 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5332AACBPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Ted, Thank your for the review. Please see inline. Cheers, Med ________________________________ De : Ted Lemon [mailto:Ted.Lemon@nominum.com] Envoy=E9 : vendredi 24 ao=FBt 2012 15:44 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : dhcwg@ietf.org Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bou= cadair-dhc-triggered-reconfigure) On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com wrote: Comments and suggestions are more than welcome. In section 2, you propose that the reconfigure-request include an RSOO, but= this is actually not necessary; what will happen is that the RECONFIGURE-R= EQUEST will trigger a RECONFIGURE, the client will then send a RENEW, the r= elay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAM= E option, and the DHCP server will send a REPLY containing the AFTR_NAME op= tion. So there's no need to include that in the RECONFIGURE-REQUEST. Th= is is a minor point--it would certainly do no _harm_ to include the AFTR_NA= ME option in the RSOO on the RECONFIGURE-REQUEST. [Med] That's make sense too. I changed "MUST" to "MAY" in Section 3.3: the = point is to provide the dhcp server with more information to help the serve= r whether a RECONFIGURE is needed. If for some reason, the server detects t= he same information has been already supplied to the client, it may decide = to not generate a RECONFIGURE message. So of course if you make this change, you'd have to fix up section 3.2. I would also change this, in section 3.2: If the server is configured to reject RECONFIGURE-REQUEST, any received REC= ONFIGURE-REQUEST is silently dropped. To this: If the server is configured to reject RECONFIGURE-REQUEST, the server MUST = silently discard any RECONFIGURE-REQUEST it receives. It might be good to consistently say "silently discard" instead of "discard= " in that section. [Med] I updated my local copy. Section 3.3 also mentions sending the RSOO, and, if you accept my argument = above, should not. [Med] Changed "MUST" to "MAY" for the reason mentioned above in my local co= py. In addition to the issues discussed in the Security Considerations section = of RFC5007, you might also want to add this (possibly to section 3.2, not t= o the Security Considerations section): Because this message provides a mechanism for triggering the DHCP Reconfigu= re message, and the DHCP Reconfigure message can be used by an attacker to = control the timing of a DHCP renewal, the DHCP server must have some mechan= ism for determining that the relay agent is a trusted entity. RECONFIGURE= -REQUEST messages originating from unknown relay agents MUST be silently dr= opped. [Med] I updated Section 3.2 with the proposed text. Thanks. Aside from this, the document looks good, and seems useful. Are you propo= sing that the working group should adopt this work? [Med] Yes. Thanks. --_000_94C682931C08B048B7A8645303FDC9F36E5332AACBPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Ted,
 
Thank your for the review.
 
Please see inline.
 
Cheers,
Med

De : Ted Lemon=20 [mailto:Ted.Lemon@nominum.com]
Envoy=E9 : vendredi 24 ao= =FBt 2012=20 15:44
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc := =20 dhcwg@ietf.org
Objet : Re: [dhcwg] RECONFIGURE Triggered b= y=20 DHCPv6 Relay Agents=20 (draft-boucadair-dhc-triggered-reconfigure)

On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com= =20 wrote:
Comments=20 and suggestions are more than welcome. 

In section 2, you propose that the reconfigure-request include an RS= OO,=20 but this is actually not necessary; what will happen is that the=20 RECONFIGURE-REQUEST will trigger a RECONFIGURE, the client will then send= a=20 RENEW, the relay will piggyback an RSOO on the RENEW containing, e.g., th= e new=20 AFTR_NAME option, and the DHCP server will send a REPLY containing the=20 AFTR_NAME option.   So there's no need to include that in the=20 RECONFIGURE-REQUEST.   This is a minor point--it would certainly do = no=20 _harm_ to include the AFTR_NAME option in the RSOO on the=20 RECONFIGURE-REQUEST.
[Med] That's make sense too. I changed "MU= ST"=20 to "MAY" in Section 3.3: the point is to provide the dhcp serve= r=20 with more information to help the server whether a RECONFIGURE is=20 needed. If for some reason, the server detects the same=20 information has been already supplied to the client, it may decide t= o not=20 generate a RECONFIGURE message.   

So of course if you make this change, you'd have to fix up section=20 3.2.

I would also change this, in section 3.2:

If the server is configured to reject RECONFIGURE-REQUE=
ST, any received RECONFIGURE-REQUEST is silently dropped.

To this:

If the server is configured to reject RECONFIGURE-REQUE=
ST, the server MUST silently discard any RECONFIGURE-REQUEST it receives.

It might be good to consistently say "silently discard" instead of=20 "discard" in that section.
[Med] I updated my loc= al=20 copy.  

Section 3.3 also mentions sending the RSOO, and, if you accept my=20 argument above, should not.
[Med] Changed "MUST" t= o "MAY" for=20 the reason mentioned above in my local copy.

In addition to the issues discussed in the Security Considerations=20 section of RFC5007, you might also want to add this (possibly to section = 3.2,=20 not to the Security Considerations section):

Because this message provides a mechanism for triggering the DHCP=20 Reconfigure message, and the DHCP Reconfigure message can be used by an=20 attacker to control the timing of a DHCP renewal, the DHCP server must ha= ve=20 some mechanism for determining that the relay agent is a trusted entity.= =20   RECONFIGURE-REQUEST messages originating from unknown relay agents= MUST=20 be silently dropped.
[Med] I updated Section 3.2 with = the=20 proposed text. Thanks. 

Aside from this, the document looks good, and seems useful.   A= re=20 you proposing that the working group should adopt this work?
[Med] Yes. Thanks.=20   

--_000_94C682931C08B048B7A8645303FDC9F36E5332AACBPUEXCB1Bnante_-- From mohamed.boucadair@orange.com Fri Aug 24 07:56:46 2012 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 5E34F21F84A2 for ; Fri, 24 Aug 2012 07:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sytPrJoDaLYZ for ; Fri, 24 Aug 2012 07:56:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1449B21F86E0 for ; Fri, 24 Aug 2012 07:56:45 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 71E5D3246A5; Fri, 24 Aug 2012 16:56:44 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5607735C045; Fri, 24 Aug 2012 16:56:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 24 Aug 2012 16:56:22 +0200 From: To: Maglione Roberta Date: Fri, 24 Aug 2012 16:56:21 +0200 Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGAAAWJUTAAAPTYcA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E5332AADE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> <282BBE8A501E1F4DA9C775F964BB21FE519702F16B@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519702F16B@GRFMBX704BA020.griffon.local> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.24.143315 Cc: "dhcwg@ietf.org" , Ullio Mario Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 24 Aug 2012 14:56:46 -0000 Hi Roberta,=20 Thank you for the review.=20 Please see inline.=20 Cheers, Med >-----Message d'origine----- >De : Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 >Envoy=E9 : vendredi 24 ao=FBt 2012 16:34 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Ullio Mario; dhcwg@ietf.org >Objet : RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay=20 >Agents (draft-boucadair-dhc-triggered-reconfigure) > >Hi Med, > I read the draft and I think this is an interesting work. >I have few comments: >- I would suggest adding an informative reference to RFC5176=20 >where you talk about CoA messages; Med: Done. >- I would suggest replacing the Radius Server entity=20 >originating Change of Authorization (CoA) Requests with=20 >Dynamic Authorization Client (DAC), because according to RFC=20 >5176 "While it is possible that the DAC is co-resident with a=20 >RADIUS authentication or accounting server, this need not=20 >necessarily be the case." Med: I updated "RADIUS Server" to "RADIUS Server/DAC".=20 >- minor/editorial: in figures 2 and 3 I would replace=20 >AFTR_NAME with DS-Lite-Tunnel-Name (RFC6519) into the RADIUS=20 >messages and OPTION_AFTR_NAME (RFC6334) into the DHCPv6 messages. Med: Done. I didn't added a ref to these two RFCs because I want the docume= nt be generic and not focus on the example itself.=20 > > >Thanks >Best Regards > > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 >On Behalf Of mohamed.boucadair@orange.com >Sent: venerd=EC 24 agosto 2012 13.49 >To: dhcwg@ietf.org >Subject: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents=20 >(draft-boucadair-dhc-triggered-reconfigure) > >Dear all, > >I submitted a new I-D defining a new message type to trigger a=20 >server to issue a RECONFIGURE message when RSSO is used. > >The text is available at:=20 >https://datatracker.ietf.org/doc/draft-boucadair-dhc-triggered- >reconfigure > >Comments and suggestions are more than welcome. > >Cheers, >Med >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg > >Questo messaggio e i suoi allegati sono indirizzati=20 >esclusivamente alle persone indicate. La diffusione, copia o=20 >qualsiasi altra azione derivante dalla conoscenza di queste=20 >informazioni sono rigorosamente vietate. Qualora abbiate=20 >ricevuto questo documento per errore siete cortesemente=20 >pregati di darne immediata comunicazione al mittente e di=20 >provvedere alla sua distruzione, Grazie. > >This e-mail and any attachments is confidential and may=20 >contain privileged information intended for the addressee(s)=20 >only. Dissemination, copying, printing or use by anybody else=20 >is unauthorised. If you are not the intended recipient, please=20 >delete this message and any attachments and advise the sender=20 >by return e-mail, Thanks. > >= From akostur@incognito.com Fri Aug 24 08:16:35 2012 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 07B3521F872A for ; Fri, 24 Aug 2012 08:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.895 X-Spam-Level: X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU8qmAQrNtiL for ; Fri, 24 Aug 2012 08:16:34 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with SMTP id 54E0A21F872D for ; Fri, 24 Aug 2012 08:16:34 -0700 (PDT) Received: from mail-qa0-f43.google.com ([209.85.216.43]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKUDea0VplzeUD/kdm3iqNhPKuVh/xmEhY@postini.com; Fri, 24 Aug 2012 08:16:34 PDT Received: by qatk31 with SMTP id k31so622716qat.9 for ; Fri, 24 Aug 2012 08:16:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Pk5OYYyspW3j6me1AoG6+wIDzAIkKg+9OjOlLaRgOhQ=; b=fw7CS77AJ7+Yy4OadccjJ2nz75vYJoaU+GcuydW2iGIyhSCiqxZesRv6VFbyoZW9j2 Fza5dgMIL5RsRfpa6sp7K6gv1mMinDYmX58JqjZpXY6+pl7Okmpz4bImX8dqceybMp3G N8lJ1FumtdlVBfQuocOoIWjPr9jqWzJ9tKQMZ5GzLLbHtM0ZprG205xFWb8q8U8HoAus QUr6aHDO8JFiuW3hxwu41ByNm5ulGWxKXakf+r2waG+4wOefcrstSKrscWqWmHiIh/Ep CUXu2YDiKvvGEuvFYlsDCLsFNNoBAP9qc9S5gDO8jAJBJde8MN3uWVWEomwbelISIG+a BnlQ== MIME-Version: 1.0 Received: by 10.224.77.14 with SMTP id e14mr9174029qak.89.1345821393215; Fri, 24 Aug 2012 08:16:33 -0700 (PDT) Received: by 10.229.32.4 with HTTP; Fri, 24 Aug 2012 08:16:33 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 24 Aug 2012 08:16:33 -0700 Message-ID: From: Andre Kostur To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlnkBtfeGfaipZTImabufxaJPKgtGv4ayvZs7dfHYxRmlkpkosqzgB0Ca7FeM6v+tLnWZfC Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 24 Aug 2012 15:16:35 -0000 A question that popped into my mind is how does the server decide whether the client will be doing a Renew, Rebind, or Information-Request? Perhaps the RA MUST supply an OPTION_RECONF_MSG? Also, is the RA expected to monitor the clients as to whether they are reconfigure capable, or will the RA rely on the server to be watching that? Do we want the server to be able to report back to the RA that the client cannot do Reconfigure? On Fri, Aug 24, 2012 at 4:49 AM, wrote: > > Dear all, > > I submitted a new I-D defining a new message type to trigger a server to > issue a RECONFIGURE message when RSSO is used. > > The text is available at: > https://datatracker.ietf.org/doc/draft-boucadair-dhc-triggered-reconfigure > > Comments and suggestions are more than welcome. > > Cheers, > Med > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Andre Kostur From Ted.Lemon@nominum.com Fri Aug 24 08:22:17 2012 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 7D7F821F872A for ; Fri, 24 Aug 2012 08:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UAaSOBncsUO for ; Fri, 24 Aug 2012 08:22:16 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id A58AC21F8722 for ; Fri, 24 Aug 2012 08:22:14 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUDecJpoAk4aZo4q5YjjkikD5cs1oQ25W@postini.com; Fri, 24 Aug 2012 08:22:14 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 EB3261B82F7 for ; Fri, 24 Aug 2012 08:22:13 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 E05A819005C for ; Fri, 24 Aug 2012 08:22:13 -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.02.0247.003; Fri, 24 Aug 2012 08:22:14 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: Call for adoption: draft-boucadair-dhc-triggered-reconfigure Thread-Index: AQHNggw8RB5j9kIDsUGrLGIrni1hsw== Date: Fri, 24 Aug 2012 15:22:13 +0000 Message-ID: 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 Subject: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure 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, 24 Aug 2012 15:22:17 -0000 The author of this draft has requested that the working group consider adop= ting it as a working group item. The document is in scope for the current= DHC working group charter. The document proposes a mechanism whereby a D= HCP relay agent co-located with a RADIUS agent can trigger a DHCP Reconfigu= re when it receives a notification from the RADIUS server that information = previously provided in the Relay-Supplied Options option has changed. If you think this is something the working group should work on, please rep= ly to this message saying so. If you think the working group should not d= o this work, please reply to this message saying so. We will evaluate con= sensus to adopt on September 7. From akostur@incognito.com Fri Aug 24 08:24:02 2012 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 BC61121F872A for ; Fri, 24 Aug 2012 08:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acX2rdhIhFkU for ; Fri, 24 Aug 2012 08:24:02 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id 6F5B221F86C7 for ; Fri, 24 Aug 2012 08:23:58 -0700 (PDT) Received: from mail-qc0-f180.google.com ([209.85.216.180]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKUDecjpwmw+k56n6f91f7L90FdSELveqq@postini.com; Fri, 24 Aug 2012 08:23:58 PDT Received: by qcmv28 with SMTP id v28so1244907qcm.25 for ; Fri, 24 Aug 2012 08:23:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=5g3ayRmqAwcfAMTBSg82li2cJZrZJgYMgnsaXPe9U0U=; b=lhnG7o9q7CdSFHNVXLFJwLKOcweQoeWZaZ2LZblJjxppNBg0gu2V/FA01k8ve4uR4w OeP91Tk+0HZAsqZwxclUe6TtwjL91++9ntCxN+RZWCcJ1U+4JBkQaOlWPyt+2+ID6L8H zeAdYaw0VJ4fEpRGqQX6Cfxk4J8TjAQbF4lQ44rHzWsL3QDG2Od7JnKUsc2ORJTYmDJe Rb/f6VJHRi2gv4+VPF4ouFiT6kAL6vJqAjXbx21+eb2r78ZDCCXfo0foUnzUifzJVlC8 KI0IJDF4iT9ubiqcl0sgrGVjwROvPZyAqvcuvq++QDHQjbc+JHEjToYJ8x6F6YImeuer CxtQ== MIME-Version: 1.0 Received: by 10.224.185.198 with SMTP id cp6mr9204391qab.79.1345821837437; Fri, 24 Aug 2012 08:23:57 -0700 (PDT) Received: by 10.229.32.4 with HTTP; Fri, 24 Aug 2012 08:23:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Aug 2012 08:23:57 -0700 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkXXK88lw1aTs0UDzJ/1ZWBZ9oh2G6N8Rt2RTinUYfvTQVWoR0zbPYSRWUm888WYPrZkTOH Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure 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, 24 Aug 2012 15:24:02 -0000 I can see this being useful in certain environments. Yes. On Fri, Aug 24, 2012 at 8:22 AM, Ted Lemon wrote: > The author of this draft has requested that the working group consider ad= opting it as a working group item. The document is in scope for the curre= nt DHC working group charter. The document proposes a mechanism whereby a= DHCP relay agent co-located with a RADIUS agent can trigger a DHCP Reconfi= gure when it receives a notification from the RADIUS server that informatio= n previously provided in the Relay-Supplied Options option has changed. > > If you think this is something the working group should work on, please r= eply to this message saying so. If you think the working group should not= do this work, please reply to this message saying so. We will evaluate c= onsensus to adopt on September 7. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=20 Andre Kostur From Ted.Lemon@nominum.com Fri Aug 24 08:32:12 2012 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 E3EAE21F86C3 for ; Fri, 24 Aug 2012 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgJ56bl4yPC0 for ; Fri, 24 Aug 2012 08:32:12 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1D21F86B1 for ; Fri, 24 Aug 2012 08:32:11 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUDeeefwKXtb9AungPKY6V438JpqyUdao@postini.com; Fri, 24 Aug 2012 08:32: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 266951B82F7 for ; Fri, 24 Aug 2012 08:32:09 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 1E06119005C for ; Fri, 24 Aug 2012 08:32:09 -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.02.0247.003; Fri, 24 Aug 2012 08:32:09 -0700 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNgg2f2GWemYRp/0G7NT9hbKcz6w== Date: Fri, 24 Aug 2012 15:32:08 +0000 Message-ID: <91484F36-D059-4D90-8BFE-60434864A579@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: <52BAE29824D9404EA2E9A96862321B29@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 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, 24 Aug 2012 15:32:13 -0000 The authors have proposed that the working group adopt the prefix pool opti= on draft as a working group item. We have engaged in some correspondence = with participants in the Routing Area, and while some helpful advice was gi= ven, no objections were raised to going forward with the work, and it's a D= HCP protocol extension, so it makes sense for it to happen in the DHC worki= ng group. The document proposes an extension to the DHCP protocol that allows the DHC= P server to communicate prefixes to the provider edge router when doing pre= fix delegation, such that this router can advertise a route to an aggregate= prefix, rather than to many individual prefixes, and so that this router d= oes not have to perform ad-hoc prefix aggregation, which may produce less o= ptimal results. If you think this work should be adopted by the working group, please reply= to this message saying so. If you think this work should not be adopted = by the working group, please reply to this message saying so. We will eva= luate consensus on September 7. From mohamed.boucadair@orange.com Fri Aug 24 08:35:39 2012 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 28BF121F86D5 for ; Fri, 24 Aug 2012 08:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoxmE5XzOOjF for ; Fri, 24 Aug 2012 08:35:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7243321F86CB for ; Fri, 24 Aug 2012 08:35:38 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id B19FA2DC4FF; Fri, 24 Aug 2012 17:35:37 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 96FBA4C063; Fri, 24 Aug 2012 17:35:37 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 24 Aug 2012 17:35:15 +0200 From: To: Andre Kostur Date: Fri, 24 Aug 2012 17:35:14 +0200 Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2CC2Z4IKhdvMmcQSWqXqVlSGmEoQAAa+4Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E5332AAED@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.24.130320 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 24 Aug 2012 15:35:39 -0000 Dear Andre, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Andre Kostur [mailto:akostur@incognito.com]=20 >Envoy=E9 : vendredi 24 ao=FBt 2012 17:17 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : dhcwg@ietf.org >Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay=20 >Agents (draft-boucadair-dhc-triggered-reconfigure) > >A question that popped into my mind is how does the server decide >whether the client will be doing a Renew, Rebind, or >Information-Request? Perhaps the RA MUST supply an OPTION_RECONF_MSG? Med: What I had initially in mind for this new message: is to not require a= ny change to the way RECONFIGURE is managed by the server but only provide = a signal to the DHCPv6 server to issue one. Is there any particular reason = you think the RA should be involved in that process? > >Also, is the RA expected to monitor the clients as to whether they are >reconfigure capable, or will the RA rely on the server to be watching >that? Med: I would say no. Do we want the server to be able to report back to the RA that >the client cannot do Reconfigure? Med: I would say no. > > >On Fri, Aug 24, 2012 at 4:49 AM, wrote: >> >> Dear all, >> >> I submitted a new I-D defining a new message type to trigger=20 >a server to >> issue a RECONFIGURE message when RSSO is used. >> >> The text is available at: >>=20 >https://datatracker.ietf.org/doc/draft-boucadair-dhc-triggered- >reconfigure >> >> Comments and suggestions are more than welcome. >> >> Cheers, >> Med >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > > > >-- >Andre Kostur >= From akostur@incognito.com Fri Aug 24 08:47:52 2012 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 E182921F8504 for ; Fri, 24 Aug 2012 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7uLfJVMvVwv for ; Fri, 24 Aug 2012 08:47:52 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id 3950821F850C for ; Fri, 24 Aug 2012 08:47:52 -0700 (PDT) Received: from mail-qa0-f46.google.com ([209.85.216.46]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUDeiJ2J96PnmUr4OMR4gsOlgnw8FEjJu@postini.com; Fri, 24 Aug 2012 08:47:52 PDT Received: by qaas11 with SMTP id s11so598348qaa.19 for ; Fri, 24 Aug 2012 08:47:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=0AyAz9soR2po2E42Hl+cwY9Z0ud1s3Bq6SayQ+sqRro=; b=CpmAn1alxkq4GKecZNjXDdLdP5frjbVGyHhMMR7pFd4Fkl4RMGAzpdN1BJxSCh/iq/ M7mxnTK6mxawfNQ6xCqzvdabBx1ktyqT4RArTEQW2UBxhRcSfQwO853Jo83BjwyvXgHP Lxv1rat6g7muTTVFd11zSeghnuotzc9MxBrCX4pfARn2s88xLhieJChaQbU6/JjTcAWM mCfkyQlf5p1tw+hSq9xkIz2gHpk2BwutgyijDVc5Ow+jbIdcQwhepYY4d+4CvvnYXGj8 Kzy91RSUX0aej869brPWahC3K6op0JH7P1pivDbj9mT0+lzt1XR82mH7RBU+0kL3G1pL mgdg== MIME-Version: 1.0 Received: by 10.224.214.67 with SMTP id gz3mr9487434qab.70.1345823271139; Fri, 24 Aug 2012 08:47:51 -0700 (PDT) Received: by 10.229.32.4 with HTTP; Fri, 24 Aug 2012 08:47:51 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5332AAED@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5332AAED@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 24 Aug 2012 08:47:51 -0700 Message-ID: From: Andre Kostur To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn23ZDxh/xKmK8SwRVfmGj36G0C1T969grTmfSyQtCFOsvR1wJtCMZs9DckxYRdXTlxCxin Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 24 Aug 2012 15:47:53 -0000 Normally the server is being told administratively to reconfigure a client, and presumably which of the three methods to use. This is just another form of that. I could see it being changed to: the RA MAY supply an OPTION_RECONF_MSG, and if not supplied, the server may determine which form of Reconfigure to use. On Fri, Aug 24, 2012 at 8:35 AM, wrote: > Dear Andre, > > Please see inline. > > Cheers, > Med > >>-----Message d'origine----- >>De : Andre Kostur [mailto:akostur@incognito.com] >>Envoy=E9 : vendredi 24 ao=FBt 2012 17:17 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : dhcwg@ietf.org >>Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay >>Agents (draft-boucadair-dhc-triggered-reconfigure) >> >>A question that popped into my mind is how does the server decide >>whether the client will be doing a Renew, Rebind, or >>Information-Request? Perhaps the RA MUST supply an OPTION_RECONF_MSG? > > Med: What I had initially in mind for this new message: is to not require= any change to the way RECONFIGURE is managed by the server but only provid= e a signal to the DHCPv6 server to issue one. Is there any particular reaso= n you think the RA should be involved in that process? > >> >>Also, is the RA expected to monitor the clients as to whether they are >>reconfigure capable, or will the RA rely on the server to be watching >>that? > > Med: I would say no. > > Do we want the server to be able to report back to the RA that >>the client cannot do Reconfigure? > > Med: I would say no. > >> >> >>On Fri, Aug 24, 2012 at 4:49 AM, wrote: >>> >>> Dear all, >>> >>> I submitted a new I-D defining a new message type to trigger >>a server to >>> issue a RECONFIGURE message when RSSO is used. >>> >>> The text is available at: >>> >>https://datatracker.ietf.org/doc/draft-boucadair-dhc-triggered- >>reconfigure >>> >>> Comments and suggestions are more than welcome. >>> >>> Cheers, >>> Med >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> >> >> >> >>-- >>Andre Kostur >> --=20 Andre Kostur Senior Product Design Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com From marc.blanchet@viagenie.ca Fri Aug 24 11:18:41 2012 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 8234621F85F4 for ; Fri, 24 Aug 2012 11:18:41 -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.417, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4RbymcL1nJI for ; Fri, 24 Aug 2012 11:18:41 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id E51F421F85EA for ; Fri, 24 Aug 2012 11:18:40 -0700 (PDT) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 17AB0425F1; Fri, 24 Aug 2012 14:18:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> Date: Fri, 24 Aug 2012 14:18:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6A9A63FB-3760-4B86-AD5A-D23A9EEEF9F8@viagenie.ca> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1278) Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 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, 24 Aug 2012 18:18:41 -0000 support for wg adoption. Marc. Le 2012-08-24 =E0 11:32, Ted Lemon a =E9crit : > The authors have proposed that the working group adopt the prefix pool = option draft as a working group item. We have engaged in some = correspondence with participants in the Routing Area, and while some = helpful advice was given, no objections were raised to going forward = with the work, and it's a DHCP protocol extension, so it makes sense for = it to happen in the DHC working group. >=20 > The document proposes an extension to the DHCP protocol that allows = the DHCP server to communicate prefixes to the provider edge router when = doing prefix delegation, such that this router can advertise a route to = an aggregate prefix, rather than to many individual prefixes, and so = that this router does not have to perform ad-hoc prefix aggregation, = which may produce less optimal results. >=20 > If you think this work should be adopted by the working group, please = reply to this message saying so. If you think this work should not be = adopted by the working group, please reply to this message saying so. = We will evaluate consensus on September 7. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From tomasz.mrugalski@gmail.com Fri Aug 24 11:25:49 2012 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 0085721F867F for ; Fri, 24 Aug 2012 11:25:49 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4O5R4iMVTGa for ; Fri, 24 Aug 2012 11:25:48 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9297121F8668 for ; Fri, 24 Aug 2012 11:25:47 -0700 (PDT) Received: by eekb45 with SMTP id b45so816006eek.31 for ; Fri, 24 Aug 2012 11:25:46 -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:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=H4Bv2a5SZbc75kPF5DIVxi9wWHbrqndIUgd6RByVTFs=; b=fpuA/HGZs8r/n+B5fJxmsTZiCkQ060ek1kq9Rj9vWuOgPUpi2tXOWj/i4VGmXiiXkC HunoRI84v6kl/VI3LV0S+tt8VDiqSlIbYpXbEkoagnAYYuHKsZlhmWQFHuevEfVQXbJv ua2nAzuXDCGqjm55OF/nMYaneGxwZT/AKDBL8DfPRoC1K2AUgCB7VQKjtykRtcXhQKZQ OQhD4JfWKsMhMd4FkBfkIupNzLN9Y6m1f68NpH4l5OV7N+TGAgNkOPbFfQAiWPuriXsY rSD32TZXN4eGg5oKKV+93cClHG05vloXBHHm6NkQu5b9ipJRVO9XUrQEEUENWQ1kBBes sDvQ== Received: by 10.14.184.133 with SMTP id s5mr8699160eem.31.1345832746735; Fri, 24 Aug 2012 11:25:46 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:d069:65b6:5b6b:842b? ([2001:470:6061:1:d069:65b6:5b6b:842b]) by mx.google.com with ESMTPS id c6sm31817321eep.7.2012.08.24.11.25.45 (version=SSLv3 cipher=OTHER); Fri, 24 Aug 2012 11:25:46 -0700 (PDT) Message-ID: <5037C726.2070406@gmail.com> Date: Fri, 24 Aug 2012 20:25:42 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: dhcwg References: In-Reply-To: X-TagToolbar-Keys: D20120824202542880 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 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, 24 Aug 2012 18:25:49 -0000 On 30.07.2012 03:35, Leaf yeh wrote: > Dear DHC folks, > > The draft (ver.-08) & the proposed (OPTION_PREFIX_POOL) on the > agenda of IETF84 DHC session > (https://datatracker.ietf.org/meeting/84/agenda/dhc/ ), is waiting > for your review and comments. Hi, You've asked for it, so here are my comments. Although there are many things mentioned below, I think the draft is a good idea. It is in a good shape and I support it. None of the things mentioned below are show-stoppers, and most can be easily fixed. I will send out separate mail to respond to adoption call. Generic comments: - Multiple prefix pools seem to be allowed (section 6, paragraph 7 suggests that). It may be useful to note that multiple prefix pools must not overlap. - There are many normative looking words (must, shall etc.) that are not capitalized. - Have you considered defining new leasequery query type: QUERY_BY_PREFIX_POOL? Server could return all leases that belong to specified prefix pool. I think it would be easier to implement one new query type than modifying the code for existing 3 query types. - Since your option affects how existing query types in leasequery work, the front page of the draft should have "updates RFC5007, 5460 (if approved)" clause. - I think I have commented on this before, but I can't find it anywhere, so I'll restate my concerns again. This is basically a signalling protocol on top of normal exchange. In its current form it allows server to make strange things like make the pool active when responding to RELEASE or saying that the pool is released when assigning a prefix in response to REQUEST. - That draft was written in BBF networks in mind, but it can be used in a general case as well. A statement to point that out should be added. Comments specific to the text: - Section 1: This is really a nit-pick style comment "The DHCPv6 protocol". I always have problem how to write it. Adding protocol after DHCP is redundant, as P in DHCP stands for protocol. On the other hand, removing "protocol" would make it less readable by people who don't know what DHCP acronym stands for. I think it probably should stay as it is. - Section 1, second paragraph. You mentiond RRs without defining that acronym. Although it is later explained in section 2, it would be good to replace its first use with "Requesting Router (RR)". - Section 1. First paragraph on page 4. "Bulk Leasequery [RFC5460] specifies a mechanism for bulk transfer of the binding data of each delegated prefix from the server to the requestor (i.e., a DHCPv6 relay agent)". While requestor is typically the relay agent, it doesn't have to be. It may be a separate entity as well. I would replace "i.e." with "typically". - Section 1, the last paragraph. "The automatic mechanisms described in this document depends". It should be "mechanism depends" or "mechanisms depend". - Section 2, Requestor definition. RFC5007 defines requestor as a note that sends leasequery messages. While it is typically a router, it doesn't have to be one. Requestor may be a separate tool that can be run on hosts or routers alike. - Section 4. ipv6-prefix should be of variable length. In most cases the prefix used here will be /56 or even shorter. That will result in at least 9 bytes being zeros. BTW This approach will be recommended in the next version of draft-ietf-dhc-option-guidelines. - Section 4. It is customary to include list of messages that MAY/MUST NOT include that option. Something like "Server MAY include this option in RELAY-REPL if relay included OPTION_PREFIX_POOL in ORO option in RELAY-FORW. It MUST NOT appear in any messages sent by clients. It MAY/MUST NOT appear in LEASEQUERY message.". - Section 4. "If the administrative policy on the server does not permit to support route aggregation on the DHCPv6 relay agent, the status of the prefix pool will always be 'Released'." Wouldn't it be better to just not include OPTION_PREFIX_POOL? - Section 5, second paragraph. "The relay agent should include the Interface ID option". Is this normative language? I think it is, so it should be "SHOULD". - Section 5. Consider the following scenario: There are X requesting routers behind a relay. Server is configured to allow route aggregation, so pool option is sent. Then administrator decides to stop using aggregation, so he turns it off. When X+1 client comes in, the server does not send PREFIX_POOL anymore, so according to paragraph 4 in section 5, relay must withdraw the associated route. How are the first X clients reachable? I suppose the relay must keep routes to them anyway and the one received in PREFIX_POOL is an additional one, not a replacement, right? - Section 5. The last paragraph about leasequery should probably be moved to a separate section "Leasequery requestor behavior". - Section 6, paragraph 2. "After receiving the Option Request option (OPTION_ORO, 6) requesting the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay- forward messages of the PD". What does PD mean in this context? I think you meant "relay-forward messages that encapsulate messages with IA_PD options". It's awfully lot of words, but I'm not sure how to say it simpler. - Section 6, paragraph 6. "When the administrator of the server changes the setting not to support route aggregation on the relay agent for the particular prefix pool, the status of the prefix pool may change from 'Active' to be 'Released' if at least one delegated prefix within the prefix pool has the valid lease.". I think once administrator disables it, the server should always set status to released. The "if at least one..." part in not necessary. - Section 6, paragraph 6. Why does the server have to send RECONFIGURE? So the relay can re-learn RR prefixes once aggregation has been disabled? It is related to my question about RR remembering (or not) the specific routes. Anyway, it would be less intrusive to say that relay must use leasequery to learn existing delegations than forcing all clients to do reconfigure, especially that for clients nothing will change. Also, keep in mind that RRs may not support reconfigure as it is an optional feature. - Section 6, last 2 paragraphs. I would move discussion about leasequery to a separate sub-section. - Section 6, last paragraph. Why repeating prefix pool in every client-data option? It will all contain the same value. It would be more reasonable to send it back only one or even not send it at all if requestor sent prefix pool option. If requestor did that, are there any cases where server could send back the prefix pool option with different values than the requestor asked for? I don't think so. - Section 7. Security consideration should also reference section 15 of RFC3633. Questions: 1. Let's assume the PE router announces 2001:db8:1::/48 prefix that is split into /56 prefixes. Someone tries to reach a customer that is currently offline. What is PE supposed to do with those packets? Respond with ICMP type=1 code=0 (no route to destination)? 2. PE has a 2001:db8:1::/48 prefix and there are 2 prefixes delegated to clients: 2001:db8:1:8000::/64 and 2001:db8:1:8001::/64. The admnistrative policy does not allow route aggregation, so OPTION_PREFIX_POOL has status set to release. Is PE allowed to aggregate both routes anyway and announce 2001:db8:1:8000::/63? Perhaps allowing such behaviour could be defined as status code = 2. I don't know if controlling this is a good idea, so feel free to ignore this suggestion. Ok, that's it. Sorry for sending such long and boring mail. I hope you find at least some of those comments useful. Again, despite numerous comments, I really support it. Tomek From tomasz.mrugalski@gmail.com Fri Aug 24 11:26:56 2012 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 D7DFE21F86A2 for ; Fri, 24 Aug 2012 11:26:56 -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=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3t6mvqUmcXz for ; Fri, 24 Aug 2012 11:26:56 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2898221F869A for ; Fri, 24 Aug 2012 11:26:56 -0700 (PDT) Received: by eekb45 with SMTP id b45so816281eek.31 for ; Fri, 24 Aug 2012 11:26:55 -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:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=yupQOxB6EPxy7QDmx0GZjLhO6vShQHn9J/6GV3XNJN4=; b=OgQBv+xvPKFuuV6+HFelhhxgqKHKx36IgS37RTPr0SSpYTnJYM4RWsSH21P+7mgi2D Cv7vQbTDVa+IUofDCmIX/2Eu+lR7l/nbN/G78JGS6vLeDsJBuejMV+QkERShgYNYqbpN CaYJNoHXclwVvRR4r95Arco4w+H5mpIjw36Tzil9Qmp6bLnoCt+GiK2vA7cdT+5vdgvy 7nG6kg3te0tB05ZTeucw2hNAjcUqCKtj3qYb9++oXaQFCGYNBACQAzBJDWtdQp38RZln OWe2XGlbQsURfuEXD+f6zvs8JH6iOYAHUJTJBR8BcLzTC5THdB56XBrPsnv8KQV4WEwv B05w== Received: by 10.14.213.201 with SMTP id a49mr8783671eep.4.1345832815092; Fri, 24 Aug 2012 11:26:55 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:d069:65b6:5b6b:842b? ([2001:470:6061:1:d069:65b6:5b6b:842b]) by mx.google.com with ESMTPS id u47sm31811807eeo.9.2012.08.24.11.26.53 (version=SSLv3 cipher=OTHER); Fri, 24 Aug 2012 11:26:54 -0700 (PDT) Message-ID: <5037C76B.3050707@gmail.com> Date: Fri, 24 Aug 2012 20:26:51 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> In-Reply-To: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> X-TagToolbar-Keys: D20120824202651750 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 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, 24 Aug 2012 18:26:57 -0000 On 24.08.2012 17:32, Ted Lemon wrote: > The authors have proposed that the working group adopt the prefix > pool option draft as a working group item. I support this work and its adoption. Tomek From sarikaya2012@gmail.com Fri Aug 24 12:23:18 2012 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 EE5B721F8613 for ; Fri, 24 Aug 2012 12:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPKnkyYWwmZR for ; Fri, 24 Aug 2012 12:23:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBABB21F84E7 for ; Fri, 24 Aug 2012 12:23:16 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5655209obb.31 for ; Fri, 24 Aug 2012 12:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=z4kzh4ECfFKU4JZLLT/DKoKK4hbTPtRV6pplxaUG28c=; b=L9RXIEddQQ9NsgUJmxgUv0knQlABVDK3JKyUX9gpofdgM4/y2lRv7pqt56Cj8WtLWj 6vFTXxFzptkcmxCaAJ/HVLZw/nnmnrojluuItehhkBlVS4cRqDrLdxIkSpwOVXKTn8zZ a2bShOaZdeKNSM49igbKPBsNZLHp/Gkz/079xvw2kwU9uLkDGw/px2hGuC4xSzZtClHu ltKg2W/WIasXrRWJYyeEuY5V+kFb+2b55WlCTS3tKr/kGhnS3kzxnVlT/ky/Q6H1b8jy YAOjhFLj3JwssNGAkFGOJnxjfNP3ts9U9N1bW9V3QrsVoMM18/XY4wXt+B9Y5s7j6crS ustQ== MIME-Version: 1.0 Received: by 10.50.5.196 with SMTP id u4mr3367621igu.41.1345836196349; Fri, 24 Aug 2012 12:23:16 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Fri, 24 Aug 2012 12:23:16 -0700 (PDT) In-Reply-To: <5037C76B.3050707@gmail.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <5037C76B.3050707@gmail.com> Date: Fri, 24 Aug 2012 14:23:16 -0500 Message-ID: From: Behcet Sarikaya To: Tomek Mrugalski Content-Type: text/plain; charset=ISO-8859-1 Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:23:21 -0000 Support. Behcet On Fri, Aug 24, 2012 at 1:26 PM, Tomek Mrugalski wrote: > On 24.08.2012 17:32, Ted Lemon wrote: >> The authors have proposed that the working group adopt the prefix >> pool option draft as a working group item. > > I support this work and its adoption. > > Tomek > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From hermin.anggawijaya@gmail.com Fri Aug 24 15:12:47 2012 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 0EC5221F8473 for ; Fri, 24 Aug 2012 15:12:47 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 842luwa+VHbF for ; Fri, 24 Aug 2012 15:12:46 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6417621F8470 for ; Fri, 24 Aug 2012 15:12:46 -0700 (PDT) Received: by qan41 with SMTP id 41so610152qan.10 for ; Fri, 24 Aug 2012 15:12: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:content-transfer-encoding; bh=/vI6K3lu70z6nKtgWSdTa2fVdz6E+yK3QjVx6A5JdNg=; b=rGAwP/2EBg2TO4FTZq3e+oRhpRjYTL6ltq0q7jP2fZLF8/JapKTREFCZ84JuJXZx9w 5Rz9Y3SOcZxsJnWllmsFzP/HOMk4RBy7ToSZqN7KG78oEffw8G3jpA1AhDXiZbeFZug4 f3MD8ReLRDdTOg5nNCMDwSYhITfB22B862lqowGre+q3IrBQRz8vUwc1MP//GaLlOvJE MJhvAYJBkQzYDAXB1stZprxpH8mMGMAvcPV+3EzPdixaB9mqT9fy288+JiMxUB2T7xPB K9fdqJ1ASxOWmaLiS/D7Rtu59XNbbhcvKBA1HidYM5ECmWUiXaTJF/ygs87jiURVKi14 NQCw== MIME-Version: 1.0 Received: by 10.224.216.7 with SMTP id hg7mr11336316qab.3.1345846365937; Fri, 24 Aug 2012 15:12:45 -0700 (PDT) Received: by 10.49.40.135 with HTTP; Fri, 24 Aug 2012 15:12:45 -0700 (PDT) In-Reply-To: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> Date: Sat, 25 Aug 2012 10:12:45 +1200 Message-ID: From: Hermin Anggawijaya To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org WG" Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 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, 24 Aug 2012 22:12:47 -0000 I support wg adoption On Sat, Aug 25, 2012 at 3:32 AM, Ted Lemon wrote: > The authors have proposed that the working group adopt the prefix pool op= tion draft as a working group item. We have engaged in some correspondenc= e with participants in the Routing Area, and while some helpful advice was = given, no objections were raised to going forward with the work, and it's a= DHCP protocol extension, so it makes sense for it to happen in the DHC wor= king group. > > The document proposes an extension to the DHCP protocol that allows the D= HCP server to communicate prefixes to the provider edge router when doing p= refix delegation, such that this router can advertise a route to an aggrega= te prefix, rather than to many individual prefixes, and so that this router= does not have to perform ad-hoc prefix aggregation, which may produce less= optimal results. > > If you think this work should be adopted by the working group, please rep= ly to this message saying so. If you think this work should not be adopte= d by the working group, please reply to this message saying so. We will e= valuate consensus on September 7. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From matozga@gmail.com Fri Aug 24 15:43:16 2012 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 837F321F8523 for ; Fri, 24 Aug 2012 15:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb3znNjdxSf4 for ; Fri, 24 Aug 2012 15:43:14 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8708421F8460 for ; Fri, 24 Aug 2012 15:43:13 -0700 (PDT) Received: by wicr5 with SMTP id r5so1163100wic.13 for ; Fri, 24 Aug 2012 15:43:12 -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:content-type; bh=5bROY2/H1Xs7hG3s8NZfkXHjaJcq2sOrlTpeQzv0l6M=; b=kvxIXg51Ug9mScOiHfzDBsIVmu3zjWOOuRGUyZ0mtiefPyZwRkpdCyJrBisjABRFN6 4yBIihQ8/NQP2QuqQef/3BSR8rrt63kINUK7uR3Ht7bu9IHZDyRWSwedpbdaR0hSJl0p 44PIH4UH3zqotNjX11BbAhBdu9t7zbutWqUNOaslH8WcFnfNRc/UJm/j4i+mHuUlzEW7 VaUvgiJYEVgUD8OQLvlJ2bUJGb/6HZHHiA2m3c8/HIDXKEv6d5Up/rgWkmTZidMvC6MN rGMya6Gm6YWjWE+JNk6w9OL3mKTf0mhJPzoRlO4e1Et96+Lvw3Sag6ZzWTok/LBaYhg6 uI7g== MIME-Version: 1.0 Received: by 10.180.86.106 with SMTP id o10mr8624437wiz.22.1345848192665; Fri, 24 Aug 2012 15:43:12 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Fri, 24 Aug 2012 15:43:12 -0700 (PDT) Date: Sat, 25 Aug 2012 00:43:12 +0200 Message-ID: From: =?ISO-8859-2?Q?Mateusz_O=BFga?= To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=f46d0418275272085f04c80ab3d8 Subject: [dhcwg] Small mistake in RFC 3315? 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, 24 Aug 2012 22:45:24 -0000 --f46d0418275272085f04c80ab3d8 Content-Type: text/plain; charset=ISO-8859-1 Hello, I recently read RFC 3315 and I found a mistake in one place (in my opinion). Section 22.5: "Note that an IA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_TA have expired, the IA can be considered as having expired." Should be: "Note that an IA_TA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_TA have expired, the IA_TA can be considered as having expired." This is mistake made by writing/forming RFC document? Should I report errata for this? Regards, Mateusz --f46d0418275272085f04c80ab3d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I recently read RFC 3315 and I found a mistake in one place (= in my opinion).

Section 22.5:

"Note that an IA has no ex= plicit "lifetime" or "lease length" of its own.
When= the valid lifetimes of all of the addresses in an IA_TA have expired,
the IA can be considered as having expired."

Should be:

= "Note that an IA_TA has no explicit "lifetime" or "leas= e length" of its own.
When the valid lifetimes of all of the addres= ses in an IA_TA have expired,
the IA_TA can be considered as having expired."

This is mistake= made by writing/forming RFC document?
Should I report errata for this?<= br>

Regards,
Mateusz
--f46d0418275272085f04c80ab3d8-- From matozga@gmail.com Fri Aug 24 15:49:42 2012 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 7D96E21F8608 for ; Fri, 24 Aug 2012 15:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0V1De8KG9cJ for ; Fri, 24 Aug 2012 15:49:41 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id DEE4721F8602 for ; Fri, 24 Aug 2012 15:49:40 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1098924wib.13 for ; Fri, 24 Aug 2012 15:49:40 -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:content-type; bh=ONc2r6fgK7NUWbkLPtlwsSFsj4SbZILjoMnUrCaO14U=; b=xkK+KPReG+OSymmvrUUqThyOMkgsCnjJh3Ti8MAuWlWV/P8EoLkz0b+r4mbhN+Rl+F OyQjYk/lz7mKC5uc1xQwFqZdTlPyCVpXiRIuN8aWdy+5qbYomMg+tresEZJM7zKbge2o jDmqoRDt4PmCmeKw37gvvYZpSu9bCldma+H7Ngnpi5YnR5vYigaXBf5759Sn94F9dqh6 f2H0494QmCRS1IvaunlQzlLaKZ0eqKVVhz4WCx8+VXa7x2zr6FNyDidlOzZDYmW5cvYs uAT0l/GV8OmzusR1ML1CQG9wUBw1QiNhAM2ZgZKD9Y+aZHNeOGBc2PoW1Rz1hWxbl4uK wxqA== MIME-Version: 1.0 Received: by 10.216.131.13 with SMTP id l13mr3426429wei.195.1345848579826; Fri, 24 Aug 2012 15:49:39 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Fri, 24 Aug 2012 15:49:39 -0700 (PDT) Date: Sat, 25 Aug 2012 00:49:39 +0200 Message-ID: From: =?ISO-8859-2?Q?Mateusz_O=BFga?= To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=0016e6da98d385a49604c80aca26 Subject: [dhcwg] Small mistake in RFC 3315? 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, 24 Aug 2012 22:49:42 -0000 --0016e6da98d385a49604c80aca26 Content-Type: text/plain; charset=ISO-8859-1 Hello, I recently read RFC 3315 and I found a mistake in one place (in my opinion). Section 22.5: "Note that an IA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_TA have expired, the IA can be considered as having expired." Should be: "Note that an IA_TA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_TA have expired, the IA_TA can be considered as having expired." This is mistake made by writing/forming RFC document? Should I report errata for this? Regards, Mateusz --0016e6da98d385a49604c80aca26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I recently read RFC 3315 and I found a mistake in one place (= in my opinion).

Section 22.5:

"Note that an IA has no ex= plicit "lifetime" or "lease length" of its own.
When= the valid lifetimes of all of the addresses in an IA_TA have expired,
the IA can be considered as having expired."

Should be:

= "Note that an IA_TA has no explicit "lifetime" or "leas= e length" of its own.
When the valid lifetimes of all of the addres= ses in an IA_TA have expired,
the IA_TA can be considered as having expired."

This is mistake= made by writing/forming RFC document?
Should I report errata for this?<= br>

Regards,
Mateusz
--0016e6da98d385a49604c80aca26-- From ghalwasi@cisco.com Fri Aug 24 17:54:44 2012 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 E14E821F85FC for ; Fri, 24 Aug 2012 17:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.44 X-Spam-Level: X-Spam-Status: No, score=-10.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vmxqgbSONqG for ; Fri, 24 Aug 2012 17:54:44 -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 100B521F85AC for ; Fri, 24 Aug 2012 17:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=1528; q=dns/txt; s=iport; t=1345856084; x=1347065684; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Xv3J9hoVJPTyUGCh2etW4yJg50xAP/F9gClxmMHMgww=; b=JXV+fdKDbCgwZJQw9z8xK9mYWU51AfxLK9MRFVmReEflrtS2skxh0nVd iads7+MzP/Q7N7+RMjcpwn6/bhZVNo+/Y1V0gL7y2ED0clhfSuCa2XrrC zLfG3/iuf4WmJR9f+SyokdZQfxdpRq+UJ37LOznaaeB1zL3UdD/SqwaW7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGshOFCtJXG8/2dsb2JhbABFumuBB4IgAQEBBAEBAQ8BCh00FwQCAQgRBAEBCxQJBycLFAkIAgQBEggah2sLmV6gBwSLCIYxYAOkAoFngmM X-IronPort-AV: E=Sophos;i="4.80,307,1344211200"; d="scan'208";a="115149912" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 25 Aug 2012 00:54:43 +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 q7P0shOi023923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Aug 2012 00:54:43 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Fri, 24 Aug 2012 19:54:43 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNgg2f2GWemYRp/0G7NT9hbKcz65dptBgg Date: Sat, 25 Aug 2012 00:54:42 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0E74A7@xmb-aln-x06.cisco.com> References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> In-Reply-To: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.73.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19134.004 x-tm-as-result: No--35.566200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 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, 25 Aug 2012 00:54:45 -0000 I support the adoption of this draft. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, August 24, 2012 9:02 PM To: dhcwg@ietf.org WG Subject: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 The authors have proposed that the working group adopt the prefix pool opti= on draft as a working group item. We have engaged in some correspondence = with participants in the Routing Area, and while some helpful advice was gi= ven, no objections were raised to going forward with the work, and it's a D= HCP protocol extension, so it makes sense for it to happen in the DHC worki= ng group. The document proposes an extension to the DHCP protocol that allows the DHC= P server to communicate prefixes to the provider edge router when doing pre= fix delegation, such that this router can advertise a route to an aggregate= prefix, rather than to many individual prefixes, and so that this router d= oes not have to perform ad-hoc prefix aggregation, which may produce less o= ptimal results. If you think this work should be adopted by the working group, please reply= to this message saying so. If you think this work should not be adopted = by the working group, please reply to this message saying so. We will eva= luate consensus on September 7. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From jiangsheng@huawei.com Fri Aug 24 22:57:54 2012 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 A72FF21F8534 for ; Fri, 24 Aug 2012 22:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuaiUqg5khaq for ; Fri, 24 Aug 2012 22:57:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B908B21F8533 for ; Fri, 24 Aug 2012 22:57:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id ALR00397; Fri, 24 Aug 2012 21:57:52 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Aug 2012 22:56:51 -0700 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Aug 2012 22:56:48 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.47]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Sat, 25 Aug 2012 13:56:45 +0800 From: Sheng Jiang To: Andre Kostur Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 Thread-Index: AQHNePgJ6EjzoGF6j0KwHUjTOoQDGZdXH58ggAAgh9CAAdqGoIAA+Bcg//+14QCAECZq4A== Date: Sat, 25 Aug 2012 05:56:44 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F24964@szxeml545-mbx.china.huawei.com> References: <2DCA645F-CDDF-4311-8417-3A9771AD3F71@nominum.com> <90903C21C73202418A48BFBE80AEE5EB0D028F@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F0504A@szxeml545-mbx.china.huawei.com> <90903C21C73202418A48BFBE80AEE5EB0D40AF@xmb-aln-x06.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B9239F060CC@szxeml545-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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02 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, 25 Aug 2012 05:57:54 -0000 PkkgdGhpbmsgdGhhdCBpZiB0aGUgZGV2aWNlIHdhbnRzIGEgUEEsIGl0IHNob3VsZCBzdXBwbHkg YW4gSUFfUEEgaW4NCj5pdHMgU29saWNpdC4gIFRoZSBkZXZpY2UgbmVlZHMgdG8gc3BlY2lmeSBh biBJQUlELiAgQW4gT1JPIGlzDQo+aW5zdWZmaWNpZW50Lg0KDQpIaSwgQW5kcmUsDQoNCllvdSBh cmUgcmlnaHQgdGhhdCBPUk8gaXMgaW5zdWZmaWNpZW50IGhlcmUuIEluIHRoZSBsYXRlc3QgbW9k aWZpY2F0aW9uLCB3ZSBoYXZlIHJlbW92ZWQgT1JPIG1vZGVsLiBUaGUgY2xpZW50IG5lZWRzIHRv IGluY2x1ZGUgYW4gSUFfUEEgd2l0aCBJQUlEIHNwZWNpZmllZC4gVGhlcmUgaXMgbm8gcHJlZml4 IGFubm91bmNlbWVudC9hZHZlcnRpc2UgbW9kZWwgaW4gdGhlIGN1cnJlbnQgZHJhZnQgYW55bW9y ZS4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQoNCj5PbiBUdWUsIEF1ZyAxNCwgMjAxMiBh dCA4OjEyIFBNLCBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPg0KPndyb3RlOg0K Pj4NCj4+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPkZyb206IFNoZW5nIEppYW5n IFttYWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tXQ0KPj4gPlNlbnQ6IE1vbmRheSwgQXVndXN0 IDEzLCAyMDEyIDE6MDUgUE0NCj4+ID5UbzogR2F1cmF2IEhhbHdhc2lhIChnaGFsd2FzaSk7IFRl ZCBMZW1vbjsgZGhjIFdHDQo+PiA+U3ViamVjdDogUkU6IFdHTEM6IGRyYWZ0LWlldGYtZGhjLWhv c3QtZ2VuLWlkLTAyDQo+PiA+DQo+PiA+SGksIEdhdXJhdiwNCj4+ID4NCj4+ID5UaGFua3MgZm9y IHlvdXIgY2FyZWZ1bGx5IHJldmlldy4gUmVwbHkgaW4gbGluZXMuIFdpdGggYWxsIHlvdXIgY29t bWVudHMNCj4+ID5hZGRyZXNzZWQsIHdvdWxkIHlvdSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQgZm9y d2FyZD8NCj4+ID5bR2F1cmF2XSBDZXJ0YWlubHkuIEkgc3VwcG9ydCB0aGUgZG9jdW1lbnQgZm9y d2FyZC4NCj4+ID4NCj4+ID4+SSBsaWtlIHRoZSBpZGVhIGJ1dCBJIGRvIGhhdmUgZmV3IGNvbW1l bnRzOi0uDQo+PiA+Pg0KPj4gPj4xLikgQWJzdHJhY3QgZG9lcyBub3Qgc2VlbXMgY2xlYXIgdG8g bWUuDQo+PiA+PlRoaXMgZG9jdW1lbnQgaW50cm9kdWNlIGEgcHJvY2VkdXJlIGZvciBjb25maWd1 cmluZyBob3N0cycgSVB2Ng0KPj4gPj4gICBhZGRyZXNzIHdoaWNoIHRoZSBwcmVmaXggaXMgYXNz aWduZWQgZnJvbSBhIERIQ1B2NiBzZXJ2ZXIgdGhyb3VnaA0KPj4gPj4gICBESENQdjYgcHJvdG9j b2wgd2hpbGUgdGhlIGludGVyZmFjZSBpZGVudGlmaWVycyBhcmUgaW5kZXBlbmRlbnRseQ0KPj4g Pj4gICBnZW5lcmF0ZWQgYnkgdGhlIGhvc3RzLg0KPj4gPg0KPj4gPlJld29yZGVkOiBUaGlzIGRv Y3VtZW50IGludHJvZHVjZXMgYSBuZXcgREhDUHY2IHByb2NlZHVyZSB0bw0KPmNvbmZpZ3VyZQ0K Pj4gPmhvc3RzJyBJUHY2IGFkZHJlc3Nlcy4gSW4gdGhpcyBuZXcgcHJvY2VkdXJlLCB0aGUgcHJl Zml4IGlzIGFkdmVydGlzZWQgZnJvbQ0KPmENCj4+ID5ESENQdjYgc2VydmVyIHRocm91Z2ggREhD UHY2IHByb3RvY29sIHdoaWxlIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmllcnMgYXJlDQo+PiA+aW5k ZXBlbmRlbnRseSBnZW5lcmF0ZWQgYnkgdGhlIGhvc3RzLg0KPj4gPg0KPj4gPj4yLikgU2VjdGlv biAxIC4gSW50cm9kdWN0aW9uLiBDaGFuZ2UgImhvc3QtZ2VuYXJhdGVkIiB0bw0KPiJob3N0LWdl bmVyYXRlZCINCj4+ID4+My4pIFNlY3Rpb24gMSAuIEludHJvZHVjdGlvbi4gQ2hhbmdlICJzZXBh cmF0cyIgdG8gInNlcGFyYXRlcyINCj4+ID4+NC4pIFNlY3Rpb24gMSAuIEludHJvZHVjdGlvbi4g Q2hhbmdlICJpbmdlcmZhY2UgaWRlbnRpZmllcnMiIHRvDQo+PiA+PiJpbnRlcmZhY2UgaWRlbnRp ZmllcnMiDQo+PiA+DQo+PiA+QWxsIGNoYW5nZWQuDQo+PiA+DQo+PiA+PjUuKSBTZWN0aW9uIDQu ICBUaGlzIHNlY3Rpb24gdGFsa3MgYWJvdXQgdGhlIG5ldyBJQV9QQSBvcHRpb24gYnV0IGRvZXMN Cj4+ID4+bm90IGV4cGxpY2l0bHkgc2F5IHRoYXQgdGhpcyBvcHRpb24gbmVlZHMgdG8gYmUgaW5z ZXJ0ZWQgaW4gU09MSUNJVA0KPm1lc3NhZ2UuDQo+PiA+DQo+PiA+SGF2ZSBhZGRlZCBhIHNlbnRl bmNlIGZvciB0aGlzLiBIb3dldmVyLCB0aGlzIGlzIG9ubHkgYSBNQVkuICJBIGhvc3QgTUFZDQo+ PiA+aW5jbHVkZSBhIE9wdGlvbiBSZXF1ZXN0IE9wdGlvbiBpbiBhIFNvbGljaXQgb3IgUmVxdWVz dCBtZXNzYWdlIHRvIHJlcXVlc3QNCj5hDQo+PiA+SUFfUEEgZXhwbGljaXRseS4iIFRoZSBwcmVm aXggYXNzaWdubWVudCBjb3VsZCBiZSBpbiBhZHZlcnRpc2UgbW9kZWwuIEl0IGlzDQo+bm90DQo+ PiA+bmVjZXNzYXJ5IHRoYXQgYSBob3N0IHJlcXVlc3QgYSBJQV9QQS4NCj4+ID5bR2F1cmF2XSBJ IGRvbid0IHVuZGVyc3RhbmQgdGhpcyBwYXJ0IGNvbXBsZXRlbHkuIFNvIHlvdSBhcmUgc2F5aW5n IHRoYXQNCj5ob3N0DQo+PiA+Y2FuIHNlbmQgIkRIQ1AgUkVRVUVTVCIgbWVzc2FnZSBhcyB3ZWxs IGluc3RlYWQgb2YgU09MSUNJVC4/IENhbiB5b3UNCj4+ID5wbGVhc2UgZWxhYm9yYXRlIGl0IGlu IGRldGFpbC4NCj4+DQo+PiA8U2hlbmc+WWVzLiBBZnRlciBkaXNjb3ZlcnkgYSBESENQdjYgc2Vy dmVyIHdpdGggc29saWNpdCBtZXNzYWdlLCBhIGhvc3QNCj5jYW4gdXNlIGEgUmVxdWVzdCBtZXNz YWdlIHRvIHJlcXVlc3QgcHJlZml4IGFzc2lnbm1lbnQgYnkgaW5jbHVkZSBhIElBX1BBLA0KPmlu c3RlYWQgb2YgSUFfTkEgb3IgSUFfVEEuIFRoZSBzZXJ2ZXIgdGhlbiByZXR1cm4gcHJlZml4IGlu Zm9ybWF0aW9uIHJhdGhlcg0KPnRoYW4gYWRkcmVzcy4gSW4gb3VyIHVuZGVyc3RhbmRpbmcsIHRo aXMgcHJvY2VkdXJlIGlzIG9uZSB3YXkgb2YgYWRkcmVzcw0KPmNvbmZpZ3VyYXRpb24sIG5vdCBv dGhlciBpbmZvcm1hdGlvbi4NCj4+DQo+PiBPb3BzLi4uIFdpdGggdGhpcywgaXQgc2VlbXMgd2Ug dXBkYXRlIFJGQzMzMTUgYSBsaXR0bGUgYml0LiBNYXliZSB3ZSBzaG91bGQNCj5pbmNsdWRlIGFu IHVwZGF0ZSBoZWFkZXIgaW4gdGhlIGRvY3VtZW50Lg0KPj4NCj4+IFRoZSBhYm92ZSBzZW50ZW5j ZSBuZWVkcyBhIGxpdHRsZSBiaXQgcmV2aXNlOiAiQSBob3N0IE1BWSBpbmNsdWRlIGEgT3B0aW9u DQo+UmVxdWVzdCBPcHRpb24gaW4gYSBTb2xpY2l0IG9yIElBX1BBIGluIGEgUmVxdWVzdCBtZXNz YWdlIHRvIHJlcXVlc3QgYSBwcmVmaXgNCj5hc3NpZ25tZW50IGV4cGxpY2l0bHkuIg0KPj4NCj4+ IFdoZW4gdGhlIHByZWZpeCBhc3NpZ25tZW50IGluIGFkdmVydGlzZSBtb2RlbCwgZXZlbiBpZiBh IGhvc3QgZG9lcyBub3QNCj5yZXF1ZXN0LCBESENQdjYgc2VydmVyIGNhbiBwdXNoIGl0IGluaXRp YXRpdmVseS4NCj4+DQo+PiA+PjYuKSBBcyB0aGlzIHByb2NlZHVyZSBpcyBpbmRlZWQgInN0YXRl IGxlc3MiIGZyb20gdGhlIERIQ1B2Ng0KPj4gPj5wZXJzcGVjdGl2ZSwgd2h5IGRvbid0IHdlIHdh bnQgdG8gdXNlICJJbmZvcm1hdGlvbi1SZXF1ZXN0IiBtZXNzYWdlDQo+PiA+Pmluc3RlYWQgb2Yg U09MSUNJVCBmcm9tIHRoZSBob3N0Lj8NCj4+ID4NCj4+ID5SZXF1ZXN0IG1lc3NhZ2UgaXMgcG9z c2libGUsIHRvby4gU2VlIHRoZSBhYm92ZSBuZXcgc2VudGVuY2UuDQo+PiA+DQo+PiA+W0dhdXJh dl0gSSB3YXMgcmVmZXJyaW5nIHRvICJJbmZvcm1hdGlvbi1SZXF1ZXN0KDExKSIgbWVzc2FnZSBu b3QNCj4+ID4iUmVxdWVzdCgzKSINCj4+DQo+PiBBcyBleHBsYWluZWQgYWJvdmUsIHdlIHRoaW5r IHRoaXMgcHJvY2VkdXJlIGlzIGFkZHJlc3MgYXNzb2NpYXRlZC4gU28sDQo+UmVxdWVzdCBpcyBt b3JlIHByb3Blci4NCj4+DQo+PiBTaGVuZw0KPj4NCj4+ID4+Ny4pIFdoYXQgc2hvdWxkIHRoZSBo b3N0IGRvIGFmdGVyIHRpbWVycyBleHBpcmUuPyBBbmQgaXMgdGhlIERIQ1B2Ng0KPj4gPj5SRUNP TkZJR1VSRSBtZXNzYWdlIHN1cHBvcnRlZCBmb3IgdGhpcyBvcHRpb24gdHlwZS4gSSB0aGluayB0 aGlzIHNob3VsZA0KPj4gPj5iZSBjbGFyaWZpZWQgaW4gdGhlIGRyYWZ0Lg0KPj4gPg0KPj4gPkhh dmUgYWRkZWQgdHdvIHNlbnRlbmNlcyBpbiBTZWN0aW9uIDQgdG8gZGVzY3JpYmUgdGhlIHBvdGVu dGlhbCBmb2xsb3cgdXANCj4+ID5vcGVyYXRpb246DQo+PiA+DQo+PiA+V2hlbiB0aGUgaG9zdCBy ZWFjaGVzIFQxIG9yIFQyIGRlZmluZWQgaW4gU2VjdGlvbiA1LjEsIGl0IFNIT1VMRCB1c2UgdGhl DQo+PiA+c2FtZSBtZXNzYWdlIGV4Y2hhbmdlcywgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMTgs ICJESENQDQo+Q2xpZW50LUluaXRpYXRlZA0KPj4gPkNvbmZpZ3VyYXRpb24gRXhjaGFuZ2UiIG9m IFtSRkMzMzE1XSwgdG8gb2J0YWluIG9yIHVwZGF0ZSBwcmVmaXgoZXMpIGZyb20NCj5hDQo+PiA+ REhDUHY2IHNlcnZlci4NCj4+ID4NCj4+ID5BIERIQ1B2NiBzZXJ2ZXIgTUFZIGluaXRpYXRpdmVs eSBzZW5kIGEgcmVjb25maWd1cmF0aW9uIG1lc3NhZ2UgdG8gdGhlDQo+aG9zdCwNCj4+ID5hcyBk ZXNjcmliZWQgaW4gc2VjdGlvbiAxOSwgIkRIQ1AgU2VydmVyLSBJbml0aWF0ZWQgQ29uZmlndXJh dGlvbg0KPkV4Y2hhbmdlIg0KPj4gPm9mIFtSRkMzMzE1XSwgdG8gY2F1c2UgcHJlZml4KGVzKSBp bmZvcm1hdGlvbiB1cGRhdGUuDQo+PiA+DQo+PiA+QmVzdCByZWdhcmRzLA0KPj4gPg0KPj4gPlNo ZW5nDQo+PiA+DQo+PiA+PlRoYW5rcywNCj4+ID4+R2F1cmF2DQo+PiA+Pg0KPj4gPj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj5Gcm9tOiBkaGN3Zy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+ID5CZWhhbGYNCj4+ID4+T2YgVGVk IExlbW9uDQo+PiA+PlNlbnQ6IE1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDc6MzUgQU0NCj4+ID4+ VG86IGRoYyBXRw0KPj4gPj5TdWJqZWN0OiBbTUFSS0VUSU5HXSBbZGhjd2ddIFdHTEM6IGRyYWZ0 LWlldGYtZGhjLWhvc3QtZ2VuLWlkLTAyDQo+PiA+Pg0KPj4gPj5UaGUgYXV0aG9ycyBoYXZlIHJl cXVlc3RlZCBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciB0aGlzIGRyYWZ0Lg0KPlRoZQ0K Pj4gPj5kcmFmdCBwcm92aWRlcyBhIG1lY2hhbmlzbSB3aGVyZWJ5IHRoZSBESENQIHNlcnZlciBj YW4gaW5kaWNhdGUgdG8gdGhlDQo+PiA+PkRIQ1AgY2xpZW50IHdoaWNoIHByZWZpeCBpdCBzaG91 bGQgdXNlIGZvciBhdXRvY29uZmlndXJhdGlvbiwgZm9yIGluc3RhbmNlDQo+Zm9yDQo+PiA+PkNH QSBhZGRyZXNzIGdlbmVyYXRpb24uICAgVGhpcyBkcmFmdCBoYXMgYmVlbiBoYW5naW5nIGFyb3Vu ZCBmb3IgYQ0KPndoaWxlLA0KPj4gPj5hbmQgY291bGQgZGVmaW5pdGVseSB1c2UgbW9yZSBleWVz IG9uIGl0LiAgIFBsZWFzZSB0YWtlIHRoZSB0aW1lIHRvDQo+cmV2aWV3IGl0Ow0KPj4gPj5pZiB5 b3UgdGhpbmsgaXQncyBhIGdvb2QgaWRlYSwgcGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBm b3IgYWR2YW5jaW5nDQo+dGhlDQo+PiA+PmRyYWZ0LiAgIElmIHlvdSB0aGluayBpdCdzIGEgYmFk IGlkZWEsIHBsZWFzZSBpbmRpY2F0ZSB0aGF0IHlvdSBkbyBub3QNCj5zdXBwb3J0DQo+PiA+PmFk dmFuY2luZyBpdC4gICBJZiB5b3UgaGF2ZSBjb21tZW50cywgdGhleSB3b3VsZCBiZSB2ZXJ5IG11 Y2gNCj4+ID5hcHByZWNpYXRlZC4NCj4+ID4+DQo+PiA+PldlIHdpbGwgZGV0ZXJtaW5lIGNvbnNl bnN1cyBvbiBBdWd1c3QgMjcuDQo+PiA+Pg0KPj4gPj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj5kaGN3ZyBtYWlsaW5nIGxpc3QNCj4+ID4+ZGhj d2dAaWV0Zi5vcmcNCj4+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aGN3Zw0KPj4gPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gPj5kaGN3ZyBtYWlsaW5nIGxpc3QNCj4+ID4+ZGhjd2dAaWV0Zi5vcmcNCj4+ID4+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGRoY3dnIG1haWxpbmcgbGlz dA0KPj4gZGhjd2dAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGhjd2cNCj4NCj4NCj4NCj4NCj4tLQ0KPkFuZHJlIEtvc3R1cg0K From ghalwasi@cisco.com Sun Aug 26 07:26:36 2012 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 E65FF21F8534 for ; Sun, 26 Aug 2012 07:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slIduaMVTKpl for ; Sun, 26 Aug 2012 07:26:36 -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 426C421F8466 for ; Sun, 26 Aug 2012 07:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=1371; q=dns/txt; s=iport; t=1345991196; x=1347200796; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fceVFGN9YvhX/c7/v4WjH11QhxDVhwx5dRWa38QZYpo=; b=WuAG9IVgRWALiOqik573TJSv9TSMfjDSpOc94vKndLjTAxSJUGWlgw4M WDnjgtpd8QvxJPqo8nnKpoZ2QcSYUwohpYh7x0BolNwj0fyGUdumiIShB rnNljvybu3m9+DIwLvDyAqH9hX0wZMgyLN7RxYhDV5ZxnRrq+lDd2KRC8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALcwOlCtJV2b/2dsb2JhbABFumqBB4IgAQEBBAEBAQ8BCh00FwQCAQgRBAEBCxQJBycLFAkIAgQBEggah2sLnB6fJQSLCIYxYAOkA4FngmOBYQ X-IronPort-AV: E=Sophos;i="4.80,315,1344211200"; d="scan'208";a="115374479" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 26 Aug 2012 14:26:35 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7QEQZQ6017758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Aug 2012 14:26:35 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 09:26:35 -0500 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , "dhcwg@ietf.org WG" Thread-Topic: Call for adoption: draft-boucadair-dhc-triggered-reconfigure Thread-Index: AQHNggw8RB5j9kIDsUGrLGIrni1hs5dsJFiA Date: Sun, 26 Aug 2012 14:26:34 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0E8342@xmb-aln-x06.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.65.71.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19138.005 x-tm-as-result: No--43.231700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure 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, 26 Aug 2012 14:26:37 -0000 I read this draft and like the capability which this draft is proposing to = add. Having said that I am in favor of adopting this draft as working group= draft. I have few comments which I will post on other email-thread. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, August 24, 2012 8:52 PM To: dhcwg@ietf.org WG Subject: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigu= re The author of this draft has requested that the working group consider adop= ting it as a working group item. The document is in scope for the current= DHC working group charter. The document proposes a mechanism whereby a D= HCP relay agent co-located with a RADIUS agent can trigger a DHCP Reconfigu= re when it receives a notification from the RADIUS server that information = previously provided in the Relay-Supplied Options option has changed. If you think this is something the working group should work on, please rep= ly to this message saying so. If you think the working group should not d= o this work, please reply to this message saying so. We will evaluate con= sensus to adopt on September 7. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ghalwasi@cisco.com Sun Aug 26 07:41:23 2012 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 D110221F852D for ; Sun, 26 Aug 2012 07:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.281 X-Spam-Level: X-Spam-Status: No, score=-10.281 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icnGNfRZx38v for ; Sun, 26 Aug 2012 07:41:22 -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 7150421F852B for ; Sun, 26 Aug 2012 07:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=18039; q=dns/txt; s=iport; t=1345992082; x=1347201682; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i1CyyOPFXO4h+8+7JlO/KbUIChCE5x23QWpOqGgf9Xo=; b=XP2DX8CWz67zgDUU2uKebPqKovaTyv5IKjFJ8EjmV27SNXGDdDuj1uwF 7F6zkETxne4qa3h8a7aqf5pWwPKx+nJpT8r7nX7ampDrZDbso0RSCY+F+ rXUuEjLn6q30q8V6Nv4ijgL2SrOgbK0jrvflwoyTDG2VXzlwDyAva7Wlm U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKA0OlCtJXG8/2dsb2JhbABFgkq4IIEHgiABAQEEEgEaTBACAQgRBAEBCxkEBzIUCQgBAQQBDQUIGodrnBufKYsIhjFgA4gam2mBZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,315,1344211200"; d="scan'208,217";a="115167489" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 26 Aug 2012 14:41:21 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7QEfLuT021285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Aug 2012 14:41:21 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 09:41:21 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "mohamed.boucadair@orange.com" , Ted Lemon Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGAABLMSoAADm1sMABI9adw Date: Sun, 26 Aug 2012 14:41:20 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0E836A@xmb-aln-x06.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> <264AF650-EB56-4C12-9A1D-F1A92FEACB39@nominum.com> <94C682931C08B048B7A8645303FDC9F36E5332AACB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5332AACB@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19138.005 x-tm-as-result: No--50.013300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB0E836Axmbalnx06ciscocom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 26 Aug 2012 14:41:23 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB0E836Axmbalnx06ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, I have few comments on this draft. 1.) I think just restricting this proposed capability to RSOO is not a good= idea. I can think of use cases in which relay agent might want to trigger = RECONFIGURE in non-RSOO scenarios as well. (Infact I am working on a I.D wh= ich is work in progress which proposes similar capability in DHCPv4). Proba= bly you can refer RSOO as the use case for this draft instead of restrictin= g this for only RSOO scenario. This is also inline with the comments from T= ed on the other email thread on not including RSOO in the RECONFIG-REQUEST= message. 2.) I also agree comment from Andre Kostur wherein Relay Agent MAY include = OPTION_RECONF_MSG option in the RECONFIGURE-REQUEST message to indicate wha= t do you want the client to send after receiving RECONFIGURE message. i.e R= enew/Info-Request. Infact there is a I.D which is also proposing to add Reb= ind capability triggered by RECONFIGURE message. (draft-droms-dhc-dhcpv6-so= lmaxrt-update-03). So it would certainly be useful to include OPTION_RECONF= _MSG on this message. Thanks, Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of m= ohamed.boucadair@orange.com Sent: Friday, August 24, 2012 8:10 PM To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bo= ucadair-dhc-triggered-reconfigure) Dear Ted, Thank your for the review. Please see inline. Cheers, Med ________________________________ De : Ted Lemon [mailto:Ted.Lemon@nominum.com] Envoy=E9 : vendredi 24 ao=FBt 2012 15:44 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : dhcwg@ietf.org Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bou= cadair-dhc-triggered-reconfigure) On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com wrote: Comments and suggestions are more than welcome. In section 2, you propose that the reconfigure-request include an RSOO, but= this is actually not necessary; what will happen is that the RECONFIGURE-R= EQUEST will trigger a RECONFIGURE, the client will then send a RENEW, the r= elay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAM= E option, and the DHCP server will send a REPLY containing the AFTR_NAME op= tion. So there's no need to include that in the RECONFIGURE-REQUEST. Th= is is a minor point--it would certainly do no _harm_ to include the AFTR_NA= ME option in the RSOO on the RECONFIGURE-REQUEST. [Med] That's make sense too. I changed "MUST" to "MAY" in Section 3.3: the = point is to provide the dhcp server with more information to help the serve= r whether a RECONFIGURE is needed. If for some reason, the server detects t= he same information has been already supplied to the client, it may decide = to not generate a RECONFIGURE message. So of course if you make this change, you'd have to fix up section 3.2. I would also change this, in section 3.2: If the server is configured to reject RECONFIGURE-REQUEST, any received REC= ONFIGURE-REQUEST is silently dropped. To this: If the server is configured to reject RECONFIGURE-REQUEST, the server MUST = silently discard any RECONFIGURE-REQUEST it receives. It might be good to consistently say "silently discard" instead of "discard= " in that section. [Med] I updated my local copy. Section 3.3 also mentions sending the RSOO, and, if you accept my argument = above, should not. [Med] Changed "MUST" to "MAY" for the reason mentioned above in my local co= py. In addition to the issues discussed in the Security Considerations section = of RFC5007, you might also want to add this (possibly to section 3.2, not t= o the Security Considerations section): Because this message provides a mechanism for triggering the DHCP Reconfigu= re message, and the DHCP Reconfigure message can be used by an attacker to = control the timing of a DHCP renewal, the DHCP server must have some mechan= ism for determining that the relay agent is a trusted entity. RECONFIGURE= -REQUEST messages originating from unknown relay agents MUST be silently dr= opped. [Med] I updated Section 3.2 with the proposed text. Thanks. Aside from this, the document looks good, and seems useful. Are you propo= sing that the working group should adopt this work? [Med] Yes. Thanks. --_000_90903C21C73202418A48BFBE80AEE5EB0E836Axmbalnx06ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

I have few comments on this draft.

 

1.) I think just restricting this proposed capabi= lity to RSOO is not a good idea. I can think of use cases in which relay ag= ent might want to trigger RECONFIGURE in non-RSOO scenarios as well. (Infac= t I am working on a I.D which is work in progress which proposes similar capability in DHCPv4). Probably you can= refer RSOO as the use case for this draft instead of restricting this for = only RSOO scenario. This is also inline with the comments from Ted on the o= ther email thread on not including  RSOO in the RECONFIG-REQUEST message.  

 

2.) I also agree comment from Andre Kostur wherei= n Relay Agent MAY include OPTION_RECONF_MSG option in the RECONFIGURE-REQUE= ST message to indicate what do you want the client to send after receiving = RECONFIGURE message. i.e Renew/Info-Request. Infact there is a I.D which is also proposing to add Rebind capability tri= ggered by RECONFIGURE message. (draft-droms-dhc-dhcpv6-solmaxrt-update-03).= So it would certainly be useful to include OPTION_RECONF_MSG on this messa= ge.

 <= /p>

Thanks,=

Gaurav<= /p>

 <= /p>

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Friday, August 24, 2012 8:10 PM
To: Ted Lemon
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (d= raft-boucadair-dhc-triggered-reconfigure)

 

Dear Ted,

 

Thank your for the review.

 

Please see inline.

 

Cheers,

Med

 

De : Ted Lemon [mailto:Ted.Lemon@nominum= .com]
Envoy=E9 : vendredi 24 ao=FBt 2012 15:44
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : dhcwg@ietf.org
Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agent= s (draft-boucadair-dhc-triggered-reconfigure)=

On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com wrote:

Comments and suggestions are more tha= n welcome. 

 

In section 2, you propose that the reconfigure-reque= st include an RSOO, but this is actually not necessary; what will happen is= that the RECONFIGURE-REQUEST will trigger a RECONFIGURE, the client will t= hen send a RENEW, the relay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAME option, and the D= HCP server will send a REPLY containing the AFTR_NAME option.   So the= re's no need to include that in the RECONFIGURE-REQUEST.   This is a m= inor point--it would certainly do no _harm_ to include the AFTR_NAME option in the RSOO on the RECONFIGURE-REQUEST.

[Med] That's make sense too. I change= d "MUST" to "MAY" in Section 3.3: the point is to = provide the dhcp server with more information to help the server wheth= er a RECONFIGURE is needed. If for some reason, the server detects the same = information has been already supplied to the client, it may decide to = not generate a RECONFIGURE message.   

 

So of course if you make this change, you'd have to = fix up section 3.2.

 

I would also change this, in section 3.2:=

 

If the server is configured to reject REC=
ONFIGURE-REQUEST, any received RECONFIGURE-REQUEST is silently dropped.

 

To this:

 

If the server is configured to reject REC=
ONFIGURE-REQUEST, the server MUST silently discard any RECONFIGURE-REQUEST =
it receives.

 

It might be good to consistently say "silently = discard" instead of "discard" in that section.
[Med] I updated my local copy.  

 

Section 3.3 also mentions sending the RSOO, and, if = you accept my argument above, should not.
[Med] Changed "MUST" to "MAY" for the reason = mentioned above in my local copy.

 

In addition to the issues discussed in the Security = Considerations section of RFC5007, you might also want to add this (possibl= y to section 3.2, not to the Security Considerations section):

 

Because this message provides a mechanism for trigge= ring the DHCP Reconfigure message, and the DHCP Reconfigure message can be = used by an attacker to control the timing of a DHCP renewal, the DHCP serve= r must have some mechanism for determining that the relay agent is a trusted entity.   RECONFIGURE-REQUEST messa= ges originating from unknown relay agents MUST be silently dropped.
[Med] I updated Section 3.2 with the proposed text. Thanks.&= nbsp;

 

Aside from this, the document looks good, and seems = useful.   Are you proposing that the working group should adopt this w= ork?
[Med] Yes. Thanks.   

 

--_000_90903C21C73202418A48BFBE80AEE5EB0E836Axmbalnx06ciscocom_-- From ghalwasi@cisco.com Sun Aug 26 07:47:44 2012 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 54AAF21F8458 for ; Sun, 26 Aug 2012 07:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOg7ki+EKEFT for ; Sun, 26 Aug 2012 07:47:41 -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 1AFF421F8456 for ; Sun, 26 Aug 2012 07:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=19693; q=dns/txt; s=iport; t=1345992461; x=1347202061; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+IeDKfbGhIupG4btDfSsMP38jTienmEUYwD3mM8acKQ=; b=idTaVlRfdULpRjaJy/BkhJIzWFIm9vYsBrm0LEMnaDL/kmVjy99qHVTC mmTFCHxtBbk3W6tqSW9rhmLOT4h4D6wsMduW0Skaf08AWVeoTUnMLWkGP 1tdnb7SmWN7dTTuv3SOhhZKoXKbEa5XIPTLOIg7bb+cBE+WIKgem4vlVY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANY1OlCtJXG//2dsb2JhbABFgkq4IIEHgiABAQEEEgEaTBACAQgRBAEBCxkEBzIUCQgBAQQBDQUIGodrnBqfKosIhjFgA4gam2mBZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,315,1344211200"; d="scan'208,217";a="115407001" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 26 Aug 2012 14:47:40 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7QEleh6001663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Aug 2012 14:47:40 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 09:47:39 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "mohamed.boucadair@orange.com" , Ted Lemon Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGAABLMSoAADm1sMABI9adwAACgFqA= Date: Sun, 26 Aug 2012 14:47:38 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0E8385@xmb-aln-x06.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> <264AF650-EB56-4C12-9A1D-F1A92FEACB39@nominum.com> <94C682931C08B048B7A8645303FDC9F36E5332AACB@PUEXCB1B.nanterre.francetelecom.fr> <90903C21C73202418A48BFBE80AEE5EB0E836A@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB0E836A@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.169] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19138.004 x-tm-as-result: No--49.146600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB0E8385xmbalnx06ciscocom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 26 Aug 2012 14:47:44 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB0E8385xmbalnx06ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Specifying the correct reference to RFC. Hi Med, I have few comments on this draft. 1.) I think just restricting this proposed capability to RSOO is not a good= idea. I can think of use cases in which relay agent might want to trigger = RECONFIGURE in non-RSOO scenarios as well. (Infact I am working on a I.D wh= ich is work in progress which proposes similar capability in DHCPv4). Proba= bly you can refer RSOO as the use case for this draft instead of restrictin= g this for only RSOO scenario. This is also inline with the comments from T= ed on the other email thread on not including RSOO in the RECONFIG-REQUEST= message. 2.) I also agree comment from Andre Kostur wherein Relay Agent MAY include = OPTION_RECONF_MSG option in the RECONFIGURE-REQUEST message to indicate wha= t do you want the client to send after receiving RECONFIGURE message. i.e R= enew/Info-Request. Infact there is a RFC which added capability to trigger = REBIND after receiving RECONFIGURE message. (Rebind Capability in DHCPv6 Re= configure Messages - RFC 6644). So it would certainly be useful to include = OPTION_RECONF_MSG on this message. Thanks, Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of moham= ed.boucadair@orange.com Sent: Friday, August 24, 2012 8:10 PM To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bo= ucadair-dhc-triggered-reconfigure) Dear Ted, Thank your for the review. Please see inline. Cheers, Med ________________________________ De : Ted Lemon [mailto:Ted.Lemon@nominum.com] Envoy=E9 : vendredi 24 ao=FBt 2012 15:44 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : dhcwg@ietf.org Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bou= cadair-dhc-triggered-reconfigure) On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com wrote: Comments and suggestions are more than welcome. In section 2, you propose that the reconfigure-request include an RSOO, but= this is actually not necessary; what will happen is that the RECONFIGURE-R= EQUEST will trigger a RECONFIGURE, the client will then send a RENEW, the r= elay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAM= E option, and the DHCP server will send a REPLY containing the AFTR_NAME op= tion. So there's no need to include that in the RECONFIGURE-REQUEST. Th= is is a minor point--it would certainly do no _harm_ to include the AFTR_NA= ME option in the RSOO on the RECONFIGURE-REQUEST. [Med] That's make sense too. I changed "MUST" to "MAY" in Section 3.3: the = point is to provide the dhcp server with more information to help the serve= r whether a RECONFIGURE is needed. If for some reason, the server detects t= he same information has been already supplied to the client, it may decide = to not generate a RECONFIGURE message. So of course if you make this change, you'd have to fix up section 3.2. I would also change this, in section 3.2: If the server is configured to reject RECONFIGURE-REQUEST, any received REC= ONFIGURE-REQUEST is silently dropped. To this: If the server is configured to reject RECONFIGURE-REQUEST, the server MUST = silently discard any RECONFIGURE-REQUEST it receives. It might be good to consistently say "silently discard" instead of "discard= " in that section. [Med] I updated my local copy. Section 3.3 also mentions sending the RSOO, and, if you accept my argument = above, should not. [Med] Changed "MUST" to "MAY" for the reason mentioned above in my local co= py. In addition to the issues discussed in the Security Considerations section = of RFC5007, you might also want to add this (possibly to section 3.2, not t= o the Security Considerations section): Because this message provides a mechanism for triggering the DHCP Reconfigu= re message, and the DHCP Reconfigure message can be used by an attacker to = control the timing of a DHCP renewal, the DHCP server must have some mechan= ism for determining that the relay agent is a trusted entity. RECONFIGURE= -REQUEST messages originating from unknown relay agents MUST be silently dr= opped. [Med] I updated Section 3.2 with the proposed text. Thanks. Aside from this, the document looks good, and seems useful. Are you propo= sing that the working group should adopt this work? [Med] Yes. Thanks. --_000_90903C21C73202418A48BFBE80AEE5EB0E8385xmbalnx06ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Specifying the correct re= ference to RFC.

 

Hi Med,

 

I have few comments on this draft.

 

1.) I think just restricting this proposed capabi= lity to RSOO is not a good idea. I can think of use cases in which relay ag= ent might want to trigger RECONFIGURE in non-RSOO scenarios as well. (Infac= t I am working on a I.D which is work in progress which proposes similar capability in DHCPv4). Probably you can= refer RSOO as the use case for this draft instead of restricting this for = only RSOO scenario. This is also inline with the comments from Ted on the o= ther email thread on not including  RSOO in the RECONFIG-REQUEST message.  

 

2.) I also agree comment from Andre Kostur wherein Relay =
Agent MAY include OPTION_RECONF_MSG option in the RECONFIGURE-REQUEST messa=
ge to indicate what do you want the client to send after receiving RECONFIG=
URE message. i.e Renew/Info-Request. Infact there is a RFC which added capability to trigger REBIND after receiving RECONFIGURE message. (Rebind Capability in DHCPv6 Reconfigure Messages – RFC 6644). So it would certainly be useful to include OPTION_RECONF=
_MSG on this message.

 <= /p>

Thanks,=

Gaurav<= /p>

 <= /p>

 <= /p>

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Friday, August 24, 2012 8:10 PM
To: Ted Lemon
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (d= raft-boucadair-dhc-triggered-reconfigure)

 

Dear Ted,

 

Thank your for the review.

 

Please see inline.

 

Cheers,

Med

 

De : Ted Lemon [mailto:Ted.Lemon@nominum= .com]
Envoy=E9 : vendredi 24 ao=FBt 2012 15:44
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : dhcwg@ietf.org
Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agent= s (draft-boucadair-dhc-triggered-reconfigure)=

On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com wrote:

Comments and suggestions are more tha= n welcome. 

 

In section 2, you propose that the reconfigure-reque= st include an RSOO, but this is actually not necessary; what will happen is= that the RECONFIGURE-REQUEST will trigger a RECONFIGURE, the client will t= hen send a RENEW, the relay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAME option, and the D= HCP server will send a REPLY containing the AFTR_NAME option.   So the= re's no need to include that in the RECONFIGURE-REQUEST.   This is a m= inor point--it would certainly do no _harm_ to include the AFTR_NAME option in the RSOO on the RECONFIGURE-REQUEST.

[Med] That's make sense too. I change= d "MUST" to "MAY" in Section 3.3: the point is to = provide the dhcp server with more information to help the server wheth= er a RECONFIGURE is needed. If for some reason, the server detects the same = information has been already supplied to the client, it may decide to = not generate a RECONFIGURE message.   

 

So of course if you make this change, you'd have to = fix up section 3.2.

 

I would also change this, in section 3.2:=

 

If the server is configured to reject REC=
ONFIGURE-REQUEST, any received RECONFIGURE-REQUEST is silently dropped.

 

To this:

 

If the server is configured to reject REC=
ONFIGURE-REQUEST, the server MUST silently discard any RECONFIGURE-REQUEST =
it receives.

 

It might be good to consistently say "silently = discard" instead of "discard" in that section.
[Med] I updated my local copy.  

 

Section 3.3 also mentions sending the RSOO, and, if = you accept my argument above, should not.
[Med] Changed "MUST" to "MAY" for the reason = mentioned above in my local copy.

 

In addition to the issues discussed in the Security = Considerations section of RFC5007, you might also want to add this (possibl= y to section 3.2, not to the Security Considerations section):

 

Because this message provides a mechanism for trigge= ring the DHCP Reconfigure message, and the DHCP Reconfigure message can be = used by an attacker to control the timing of a DHCP renewal, the DHCP serve= r must have some mechanism for determining that the relay agent is a trusted entity.   RECONFIGURE-REQUEST messa= ges originating from unknown relay agents MUST be silently dropped.
[Med] I updated Section 3.2 with the proposed text. Thanks.&= nbsp;

 

Aside from this, the document looks good, and seems = useful.   Are you proposing that the working group should adopt this w= ork?
[Med] Yes. Thanks.   

 

--_000_90903C21C73202418A48BFBE80AEE5EB0E8385xmbalnx06ciscocom_-- From roberta.maglione@telecomitalia.it Sun Aug 26 13:17:10 2012 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 4A0AA21F8554 for ; Sun, 26 Aug 2012 13:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.862 X-Spam-Level: X-Spam-Status: No, score=-0.862 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me1V-IgEkKHv for ; Sun, 26 Aug 2012 13:17:09 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 74B9621F8530 for ; Sun, 26 Aug 2012 13:17:09 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Sun, 26 Aug 2012 22:17:05 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Sun, 26 Aug 2012 22:17:05 +0200 From: Maglione Roberta To: 'Ted Lemon' , "dhcwg@ietf.org WG" Date: Sun, 26 Aug 2012 22:17:05 +0200 Thread-Topic: Call for adoption: draft-boucadair-dhc-triggered-reconfigure Thread-Index: AQHNggw8RB5j9kIDsUGrLGIrni1hs5dsizEQ Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519702F16D@GRFMBX704BA020.griffon.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigure 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, 26 Aug 2012 20:17:10 -0000 I read the draft I think it is useful. I support the adoption of this document as WG item. Roberta -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: venerd=EC 24 agosto 2012 17.22 To: dhcwg@ietf.org WG Subject: [dhcwg] Call for adoption: draft-boucadair-dhc-triggered-reconfigu= re The author of this draft has requested that the working group consider adop= ting it as a working group item. The document is in scope for the current= DHC working group charter. The document proposes a mechanism whereby a D= HCP relay agent co-located with a RADIUS agent can trigger a DHCP Reconfigu= re when it receives a notification from the RADIUS server that information = previously provided in the Relay-Supplied Options option has changed. If you think this is something the working group should work on, please rep= ly to this message saying so. If you think the working group should not d= o this work, please reply to this message saying so. We will evaluate con= sensus to adopt on September 7. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From jiangsheng@huawei.com Sun Aug 26 20:44:25 2012 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 4ABE221F8552 for ; Sun, 26 Aug 2012 20:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whAqMQPIR0Jj for ; Sun, 26 Aug 2012 20:44:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF9B21F84FD for ; Sun, 26 Aug 2012 20:44:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id APE00899; Sun, 26 Aug 2012 19:44:22 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 26 Aug 2012 20:40:19 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 26 Aug 2012 20:40:19 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.47]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Mon, 27 Aug 2012 11:40:11 +0800 From: Sheng Jiang To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-03 Thread-Index: Ac2AFqKIr/l0UPxTSEe//xSbfC8VdAD7uWXg Date: Mon, 27 Aug 2012 03:40:10 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F2522F@szxeml545-mbx.china.huawei.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4EF172@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4EF172@xmb-rcd-x04.cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: multipart/mixed; boundary="_002_5D36713D8A4E7348A7E10DF7437A4B9239F2522Fszxeml545mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-03 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, 27 Aug 2012 03:44:25 -0000 --_002_5D36713D8A4E7348A7E10DF7437A4B9239F2522Fszxeml545mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEJlcm5pZSwNCg0KVGhhbmtzIHNvIG11Y2ggZm9yIHlvdXIgY29tbWVudHMuIFRoZXkgaGVs cCBhIGxvdCBmb3IgaW1wcm92aW5nIHRoZSBxdWFsaXR5IG9mIHRoaXMgZHJhZnQuIEkgYW0gbWFr aW5nIHRoZSBjb3JyZXNwb25kZW50IGNoYW5nZXMuIFNlZSByZXBsaWVzIGluIGxpbmVzLg0KDQpJ IGFsc28gYXR0YWNoZWQgYW4gb25nb2luZyB2ZXJzaW9uLiBJdCB3aWxsIG9ubHkgc3VibWl0IGFm dGVyIHRoZSBkaXNjdXNzaW9uIGdldCBzdGFibGUuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcN Cg0KPi0gQW4gQWR2ZXJ0aXNlIHNob3VsZCBORVZFUiBhc3NpZ24gYW55dGhpbmcuIEEgUmVwbHkg aXMgdGhlIG9ubHkgdGhpbmcgDQo+dGhhdCBjYW4gZG8gdGhhdC4NCj4NCj4gICAgICAgVGhlIERI Q1B2NiBzZXJ2ZXIgYXNzaWducyBvbmUgb3IgbW9yZSBwcmVmaXhlcyB0byB0aGUgaG9zdCBpbg0K PiAgICAgICBBZHZlcnRpc2UgbWVzc2FnZXMgb3IgaW4gdGhlIFJlcGx5IG1lc3NhZ2VzIHJlc3Bv bmRpbmcgdG8gdGhlDQo+ICAgICAgIHByZWZpeCByZXF1ZXN0cyBmcm9tIHRoZSBob3N0cy4NCj4N Cj5UaGUgYXNzaWdubWVudCBkb2Vzbid0IG9jY3VyIHVudGlsIHRoZSBSZXBseSAobm90ZSBhbHNv IHRoZSAib3IiKS4gVGhpcyANCj5pcyB2ZXJ5IGJhZCBhbmQgd2Ugc2hvdWxkIG5vdCBiZSBtaXNs ZWFkaW5nIHBlb3BsZSB0aGF0IGFsbCB0aGV5IG5lZWQgDQo+aXMgU29saWNpdC9BZHZlcnRpc2Uu DQoNClllcywgeW91IGFyZSByaWdodC4gSSBoYXZlIHJlbW92ZWQgYXNzaWdubWVudCBpbiBhZHZl cnRpc2UgbWVzc2FnZS4NCg0KPi0gVGhpcyBkb2N1bWVudCBzdGlsbCBmYWlscyB0byBjbGFyaWZ5 IHRoZSBvbi1saW5rIHN0YXR1cyBvZiB0aGUgUEEgDQo+cHJlZml4IChJIHdvdWxkIGFzc3VtZSBp dCBpcyBOT1Qgb24tbGluayB1bmxlc3Mgc28gYWR2ZXJ0aXNlZCBpbiBhbiANCj5SQSkuIEkgaGF2 ZW4ndCBsb29rZWQgYmFjayBhdCB0aGUgc3RhdGVsZXNzIGF1dG9jb25maWd1cmF0aW9uIGRvY3Vt ZW50IA0KPnRvIHNlZSBpZiB0aGVyZSBpcyBhbnl0aGluZyBlbHNlIHRoYXQgYSBSQSBQcmVmaXgg SW5mb3JtYXRpb24gT3B0aW9uIA0KPmNvbW11bmljYXRlcyB0aGF0IG1pZ2h0IGFsc28gYmUgbWlz c2luZw0KPi0gb2J2aW91c2x5IHRoZSBBIChzdGF0ZWxlc3MpIGlzbid0IG5lZWQgc2luY2UgaXQg aXMgaW1wbGljaXQgaW4gdGhlIElBX1BBLg0KDQpJIGRvbid0IHRoaW5rIFBBIHNob3VsZCBtYXRj aCBhbGwgUkEgUHJlZml4IEluZm9ybWF0aW9uLiBPbi1saW5rIHN0YXR1cyBpcyBmb3IgdGhlIHJl YWNoYWJpbGl0eSwgd2hpY2ggSUFfUEEgZG9lcyBub3QgY2FyZS4gRGlmZmVyZW50IGZyb20gZHJh ZnQtZHJvbXMtZGhjLWRoY3B2Ni1kZWZhdWx0LXJvdXRlciwgd2UgZG9uJ3Qgd2FudCB0byByZXBs YWNlIE5EIHJlYWNoYWJpbGl0eSBhbmQgcm91dGluZyBmdW5jdGlvbnMuIEhvd2V2ZXIsIEkgaGF2 ZSBhZGRlZCB0aGUgYmVsb3cgdGV4dCBhcyBleHBsYW5hdGlvbiBpbnRvIHRoZSBkcmFmdC4NCg0K IkNvbXBhcmluZyB3aXRoIFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb24gaW4gTkQsIFNlY3Rpb24g NC42LjIgb2YgUkZDNDg2MSwgdGhlIElBX1BBIG9wdGlvbiBkb2VzIG5vdCBwcm92aWRlIEwgZmxh ZyBhbmQgQSBmbGFnLiAgVGhlIEEgKGF1dG9ub21vdXMgYWRkcmVzcy1jb25maWd1cmF0aW9uIGZs YWcpIGlzbid0IG5lZWQgb2J2aW91c2x5IGJlY2F1c2UgdGhlIElBX1BBIGlzIGltcGxpY2l0IGZv ciBzdGF0ZWxlc3MgYWRkcmVzcyBjb25maWd1cmF0aW9uLiBCZWNhdXNlIHRoZSBJQV9QQSBpcyBv bmx5IGFkZHJlc3MgcmVsZXZhbnQsIGl0IGRvZXMgbm90IHJlbGV2YW50IHRvIHJlYWNoYWJpbGl0 eSBvciByb3V0aW5nIGFuZCB0aGUgREhDUHY2IHNlcnZlciBtYXkgbm90IHN1cmUgdGhlIG9uLWxp bmsgc3RhdGUuIFNvIEwgKG9uLUxpbmspIGZsYWcgaXMgbm90IGluY2x1ZGUuIFRoZSBESENQdjYg Y2xpZW50IHNob3VsZCB0cmVhdCB0aGUgcHJlZml4IGFzIHNhbWUgYXMgTCBmbGFnIG5vdCBzZXQs IHdoaWNoIG1ha2VzIG5vIHN0YXRlbWVudCBhYm91dCBvbi1saW5rIG9yIG9mZi1saW5rIHByb3Bl cnRpZXMgb2YgdGhlIHByZWZpeC4iDQoNCj4tIEkgd291bGQgdGhpbmsgaXQgd291bGQgaW1wcm92 ZSB0aGluZ3MgdG8gbW92ZSB0aGUgNi4gQXBwbGljYWJpbGl0eSANCj5zZWN0aW9uIHRvIGVhcmxp ZXIgaW4gdGhlIGRvY3VtZW50IChmb3IgZXhhbXBsZSwgYWZ0ZXIgc2VjdGlvbiAxKS4NCg0KSGF2 ZSBkb25lIHRoaXMuDQoNCj4tIEkgdGhpbmsgdGhpcyBkb2N1bWVudCBuZWVkcyB0byBjbGFyaWZ5 IHdoYXQgYSBob3N0IGRvZXMgaWYgdGhlIHNhbWUgDQo+cHJlZml4IGlzIGNvbW11bmljYXRlZCAo Zm9yIGVzc2VudGlhbGx5IHN0YXRlbGVzcyB1c2FnZSkgdmlhIGJvdGggUkFzIA0KPmFuZCBESENQ djYuIEZvciBleGFtcGxlLCBtdXN0IGl0IGNvbnRpbnVlIHRvIHJlbmV3IGl0IHdpdGggdGhlIERI Q1Agc2VydmVyLg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgc2hvdWxkIGJlIGFuIGlzc3VlLiBJbiBw cmluY2lwbGUsIEFJX1BBIGFuZCBSQSBQcmVmaXggSW5mb3JtYXRpb24gT3B0aW9uIHNob3VsZCBO T1QgYmUgdXNlZCBmb3IgdGhlIHNhbWUgcHJlZml4LiBOZXR3b3JrIG9wZXJhdG9yIHNob3VsZCBh dm9pZCB0aGlzIGluIG5ldHdvcmsgZGVzaWduLiBIb3dldmVyLCBldmVuIHRoaXMgaGFwcGVucywg aXQgc2hvdWxkIG5vdCBiZSBoYXJtZnVsLiBJbXBsZW1lbnRhdGlvbiBjYW4gdXNlIGFueSBvbmUg b2YgaXQgYW5kIHNhZmVseSBpZ25vcmUgYW5vdGhlciBvbmUuIFdoeSBib3RoZXI/DQoNCj4tIFRo ZXJlIHByb2JhYmx5IG5lZWRzIHRvIGJlIHNvbWUgdGV4dCByZWdhcmRpbmcgc29tZSBjb25zaWRl cmF0aW9ucyANCj5mb3IgREhDUCBzZXJ2ZXJzIGFuZCBjbGllbnRzLiBGb3IgZXhhbXBsZSwgaWYg YSBJQV9QQSBjYXBhYmxlIGNsaWVudCANCj5jb25uZWN0cyB0byBhIG5ldHdvcmssIGFuZCB0aGUg REhDUCBzZXJ2ZXIgaXMgbm90IElBX1BBIGNhcGFibGUsIHRoZSANCj5Tb2xpY2l0IHdpbGwgcmVz dWx0IGluIG5vIG9yIEFkdmVydGlzZXMgd2l0aG91dCBJQV9QQXMuIEEgY2xpZW50IGNvdWxkIA0K Pm5vdyBjb250aW51ZSBTb2xpY2l0aW5nICh3aXRoIGFwcHJvcHJpYXRlIHJldHJhbnNtaXNzaW9u cykgb3IgaXQgY291bGQgDQo+J2ZhaWxvdmVyJyB0byBkb2luZyBJQV9OQS9JQV9UQSByZXF1ZXN0 cz8gT3IgcGVyaGFwcyBqdXN0IHdhaXQgZm9yIA0KPnN0YXRlbGVzcyAoUlMvUkEpIHRvIGVpdGhl ciBwcm92aWRlIGl0IHN0YXRlbGVzcyBhdXRvY29uZmlndXJhdGlvbiBvciANCj5pbmRpY2F0ZSB0 aGF0IGl0IHNob3VsZCBkbyBESENQICh3aXRoIElBX05BL0lBX1RBKT8gUGVyaGFwcyBhcmUgcmVh c29ucyANCj5mb3IgZWFjaCBvZiB0aGVzZSBiZWhhdmlvcnMuIE9yLCB0aGVyZSBtYXkgYmUgZ3Vp ZGFuY2UgYWJvdXQgd2hlbiB0byANCj51c2UgSUFfUEFzIGluIFNvbGljaXRzIGFuZCB3aGVuIG5v dD8gRm9yIGV4YW1wbGUsIHVzZSBpdCBmb3IgDQo+cG9pbnQtdG8tcG9pbnQgaW50ZXJmYWNlcyBv bmx5PyBOb3RlIHRoYXQgSSdtIG5vdCBwcm9tb3Rpbmcgb25lIGNob2ljZSBvdmVyIGFub3RoZXIg LSB0aGF0IGlzIGZvciB5b3UgKGFuZCB0aGUgV0cpIHRvIGRlY2lkZS4NCg0KUGVyc29uYWxseSwg SSBiZWxpZXZlIHRoaXMgY29uc2lkZXJhdGlvbiBpcyBtb3JlIGltcGxlbWVudGVyIGNob2ljZXMs IHJhdGhlciB0aGFuIHN0YW5kYXJkIHdvcmsuIEhvd2V2ZXIsIEkgaGF2ZSBhZGRlZCB0aGUgYmVs b3cgdGV4dC4NCg0KIklmIGFuIElBX1BBIGNhcGFibGUgY2xpZW50IGNvbm5lY3RzIHRvIGEgbmV0 d29yaywgYW5kIHRoZSBESENQdjYgc2VydmVyIGlzIG5vdCBJQV9QQSBjYXBhYmxlLCB0aGUgU29s aWNpdCBvciBSZXF1ZXN0IG1lc3NhZ2Ugd2l0aCBJQV9QQSBPcHRpb24gd2lsbCByZXN1bHQgaW4g bm8gUmVwbHksIFJlcGx5IHdpdGhvdXQgSUFfUEFzLCBvciBSZXBseSB3aXRoIGEgU3RhdHVzIENv ZGUgY29udGFpbmluZyBVbnNwZWNGYWlsLiBUaGUgY2xpZW50IE1BWSBkZWNpZGUgdGhlIG5ldHdv cmsgZG9lcyBub3Qgc3VwcG9ydCBJQV9QQSBpbW1lZGlhdGVseSBvciBhZnRlciBhIHBlcmlvZCBv ZiBzb2xpY2l0aW5nICh3aXRoIGxpbWl0ZWQgcmV0cmFuc21pc3Npb25zIHRpbWVzKS4gVGhlbiwg aXQgTUFZICdmYWlsb3ZlcicgdG8gSUFfTkEvSUFfVEEgcmVxdWVzdHMuIg0KDQo+LSBQZXJoYXBz IG5vdCBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSAoc2luY2UgSSB3b3VsZCBob3BlIGl0IG9idmlvdXMp LCBidXQgDQo+aXQgbWF5IGJlIHVzZWZ1bCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBQRF9FWENMVURF IChSRkMgNjYwMykgb3B0aW9uIG1heSANCj5ub3QgYmUgZW5jYXBzdWxhdGVkIGluIHRoZSBJQVBS RUZJWCBvcHRpb25zIHRoYXQgYXJlIGVuY2Fwc3VsYXRlZCBpbiBhbiANCj5JQV9QRD8gKFJGQw0K PjY2MDMgaXMgcHJldHR5IGRlcGVuZGVudCBvbiBQRC4pDQoNCkhhdmUgYWRkZWQgdGhpcyBzdGF0 ZW1lbnQgaW50byB0aGUgZHJhZnQuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg== --_002_5D36713D8A4E7348A7E10DF7437A4B9239F2522Fszxeml545mbxchi_ Content-Type: text/plain; name="draft-ietf-dhc-host-gen-id-04-a.txt" Content-Description: draft-ietf-dhc-host-gen-id-04-a.txt Content-Disposition: attachment; filename="draft-ietf-dhc-host-gen-id-04-a.txt"; size=19821; creation-date="Fri, 24 Aug 2012 02:47:16 GMT"; modification-date="Mon, 27 Aug 2012 03:37:56 GMT" Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICAgICAgICAgIFByZWZpeCBBc3NpZ25tZW50IGluIERIQ1B2Ng0KICAgICAg ICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1kaGMtaG9zdC1nZW4taWQtMDQNCg0KQWJzdHJhY3QN Cg0KICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgZ2VuZXJpYyBob3N0LW9yaWVudGVkIHBy ZWZpeCBhc3NpZ25tZW50DQogICBtZWNoYW5pc20gdXNpbmcgREhDUHY2LiAgSW4gdGhpcyBuZXcg YWRkcmVzcyBjb25maWd1cmF0aW9uIHByb2NlZHVyZSwNCiAgIHRoZSBwcmVmaXggaXMgYXNzaWdu ZWQgZnJvbSBhIERIQ1B2NiBzZXJ2ZXIgdG8gaG9zdHMgdGhyb3VnaCBESENQdjYNCiAgIG1lc3Nh Z2UgZXhjaGFuZ2luZyB3aGlsZSB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZXJzIGFyZSBpbmRlcGVu ZGVudGx5DQogICBnZW5lcmF0ZWQgYnkgdGhlIGhvc3RzLiAgSXQgZW5hYmxlcyBib3RoIGludGVn cmFsIGFkZHJlc3MgYXNzaWdubWVudA0KICAgYW5kIHNlbGYtZ2VuZXJhdGVkIGFkZHJlc3NlcyBp biBvbmUgc2luZ2xlIG1lY2hhbmlzbSwgREhDUHY2LiAgSXQNCiAgIGFsc28gZW5hYmxlcyBzdGF0 ZWxlc3MgYWRkcmVzcyBjb25maWd1cmF0aW9uIHdpdGhvdXQgUkEgYXR0ZW5kYW5jZS4NCg0KDQpU YWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDIuICBUZXJtaW5vbG9neSAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAg My4gIEFwcGxpY2FiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA0DQogICA0LiAgQWRkcmVzcyBBdXRvLWNvbmZpZ3VyYXRpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgIDUuICBESENQdjYgT3BlcmF0aW9uIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgNi4gIERI Q1B2NiBJQV9QQSBPcHRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA3DQogICAgIDYuMS4gIElkZW50aXR5IEFzc29jaWF0aW9uIGZvciBQcmVmaXggQXNzaWdu bWVudCBPcHRpb24gIC4gLiAuIC4gIDcNCiAgICAgNi4yLiAgSUFfUEEgUHJlZml4IE9wdGlvbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgNy4gIElBTkEgY29u c2lkZXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5 DQogICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDkNCiAgIDkuICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgMTAuIFJlZmVyZW5jZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAg IDEwLjEuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDkNCiAgICAgMTAuMi4gSW5mb3JtYXRpdmUgcmVmZXJlbmNlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQoNCg0KMS4gIElu dHJvZHVjdGlvbg0KDQogICBBIGhvc3QgSVB2NiBhZGRyZXNzIGlzIGNvbWJpbmVkIGJ5IGEgcHJl Zml4IGFuZCBhbiBpbnRlcmZhY2UNCiAgIGlkZW50aWZpZXIuICBDdXJyZW50bHksIHRoZXJlIGFy ZSB0d28gbWVjaGFuaXNtcyB0byBjb25maWd1cmUgYSBob3N0DQogICBJUHY2IGFkZHJlc3MuICBb UkZDMzMxNV0gZGVzY3JpYmVzIHRoZSBvcGVyYXRpb24gb2YgYWRkcmVzcw0KICAgYXNzaWdubWVu dCBieSBhIERIQ1B2NiBzZXJ2ZXIuICBUaGUgb3BlcmF0aW9uIGFzc3VtZXMgdGhhdCB0aGUgc2Vy dmVyDQogICBpcyByZXNwb25zaWJsZSBmb3IgdGhlIGFzc2lnbm1lbnQgb2YgYW4gaW50ZWdyYWwg YWRkcmVzcyB3aGljaA0KICAgaW5jbHVkZXMgYm90aCBwcmVmaXggYW5kIGludGVyZmFjZSBpZGVu dGlmaWVyIHBhcnRzIGFzIGRlc2NyaWJlZCBpbg0KICAgW1JGQzQyOTFdLiAgSW4gdGhlIFN0YXRl bGVzcyBBZGRyZXNzIEF1dG9jb25maWd1cmF0aW9uIChTTEFDQywNCiAgIFtSRkM0ODYyXSkgbW9k ZWwsIHRoZSBpbnRlcmZhY2UgSWRlbnRpZmllciBpcyBnZW5lcmF0ZWQgYnkgdGhlIGhvc3QNCiAg IGl0c2VsZiB3aGlsZSB0aGUgcHJlZml4IGlzIGNvbmZpZ3VyZWQgdGhyb3VnaCBSb3V0ZXIgQWR2 ZXJ0aXNlbWVudA0KICAgbWVzc2FnZSBkZWZpbmVkIGluIFtSRkM0ODYxXS4NCg0KICAgSG93ZXZl ciwgaW4gYSBESENQdjYtbWFuYWdlZCBuZXR3b3JrLCBhc3NpZ25pbmcgMTI4LWJpdCBhZGRyZXNz IGlzDQogICBpbnN1ZmZpY2llbnQuICBTb21lIGhvc3RzIG1heSB3YW50IHRvIHVzZSBzZWxmLWdl bmVyYXRlZCBhZGRyZXNzLA0KICAgd2hpY2ggYXJlIGNvbWJpbmVkIGJ5IHByZWZpeGVzIG9idGFp bmVkIGZyb20gbmV0d29yayBjb25maWd1cmF0aW9uDQogICBhbmQgaW50ZXJmYWNlIGlkZW50aWZp ZXJzIGdlbmVyYXRlZCBieSBob3N0cy4gIFRoZSBhcHBsaWNhYmxlIHVzZXINCiAgIGNhc2VzIGlu Y2x1ZGUgQ0dBIFtSRkMzOTcyXSwgbW9kaWZpZWQgRVVJLTY0IGludGVyZmFjZSBpZGVudGlmaWVy DQogICBbRVVJLTY0XSwgdGVtcG9yYXJ5IGFkZHJlc3NlcyBmb3IgcHJpdmFjeSBbUkZDNDk0MV0g YW5kIGV0Yy4NCg0KICAgSW4gdGhlc2Ugc2NlbmFyaW9zLCB0aGUgYWRkcmVzcyBjb25maWd1cmF0 aW9uIHByZWNlZHVyZSBoYXMgdG8gYmUNCiAgIHNwbGl0dGVkIGluIHR3byBtb3RoZWRzOiBpbnRl Z3JhbCBhZGRyZXNzIGFzc2lnbm1lbnQgdGhyb3VnaCBESENQdjYNCiAgIGFuZCBwcmVmaXggYW5u b3VuY2VtZW50IGJ5IFJBIGFkdmVydGlzZW1lbnQuICBTb21lIElTUHMgZGVzaXJlIHRvDQogICBt YW5hZ2UgYWRkcmVzcyBjb25maWd1cmF0aW9uIHVzaW5nIG9uZSBzZXQgb2YgcHJvdG9jb2wsIHJh dGhlciB0aGFuDQogICBtaXh0dXJlIG9mIERIQ1B2NiBhbmQgTmVpZ2hib3IgRGlzY292ZXJ5Lg0K DQogICBUaGVyZSBhcmUgYWxzbyBzb21lIG5ldHdvcmsgZW52aXJvbm1lbnRzIGluIHRoYXQgcGVy Zml4IGFubm91Y2VtZW50DQogICB0aHJvdWdoIFJBcyBtYXkgbm90IGJlIHRoZSBiZXN0IGNob2lj ZS4gIEZvciBleGFtcGxlLCBob3N0cyBtYXkNCiAgIGNvbm5lY3QgdGhyb3VnaCB0dW5uZWxzLCBl aXRoZXIgbGF5ZXIgMiB0dW5uZWxzIG9yIGxheWVyIDMgdHVubmVscy4NCg0KICAgV2hpbGUgYSBS QSBpcyBvbmx5IGFibGUgdG8gYW5ub3VuY2UgcHJlZml4IG9uIGEgc2luZ2xlIGxpbmssIERIQ1B2 Ng0KICAgY29uZmlndXJhdGlvbiBjYW4gYmUgdXNlZCB0byBtYW5hZ2UgbXVsdGlwbGUgbGlua3Mg Ynkgc2V0dXAgREhDUHY2DQogICByZWxheS4NCg0KICAgVXAgdG8gbm93LCB0aGVyZSBpcyBubyBt ZWNoYW5pc20gZm9yIGhvc3Qtb3JpZW50ZWQgcHJlZml4IGFzc2lnbm1lbnQNCiAgIGluIERIQ1B2 Ni4gIFtSRkMzNjMzXSBkZWZpbmVzIFByZWZpeCBEZWxlZ2F0aW9uIG9wdGlvbnMgcHJvdmlkaW5n IGENCiAgIG1lY2hhbmlzbSBmb3IgYXV0b21hdGVkIGRlbGVnYXRpb24gb2YgSVB2NiBwcmVmaXhl cyB1c2luZyB0aGUgREhDUHY2Lg0KICAgVGhpcyBtZWNoYW5pc20gaXMgaW50ZW5kZWQgZm9yIGRl bGVnYXRpbmcgYSBsb25nLWxpdmVkIHByZWZpeCBmcm9tIGENCiAgIGRlbGVnYXRpbmcgcm91dGVy IHRvIGEgcmVxdWVzdGluZyByb3V0ZXIuICBUaGlzIG1lY2hhbmlzbSAiaXMgbm90DQogICBib3Vu ZCB0byB0aGUgYXNzaWdubWVudCBvZiBJUCBhZGRyZXNzZXMgb3Igb3RoZXIgY29uZmlndXJhdGlv bg0KICAgaW5mb3JtYXRpb24gdG8gaG9zdHMiIFtSRkMzNjMzXS4gIEl0IGRlbGVnYXRlcyBwcmVm aXhlcyB0byBhIHJvdXRhYmxlDQogICBkZXZpY2UgZm9yIGl0c2VsZiB1c2Ugb25seS4gIEl0IGRv ZXMgbm90IHN1cHBvcnQgdGhlIGhvc3QtZ2VuZXJhdGVkDQogICBpbnRlcmZhY2UgaWRlbnRpZmll cnMgbW9kZWwsIGluIHdoaWNoIHByZWZpeChlcykgbmVlZCB0byBiZQ0KICAgcHJvcGFnYXRlZCB0 byBob3N0cy4NCg0KICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgZ2VuZXJpYyBwcmVmaXgg YXNzaWdubWVudCBtZWNoYW5pc20gdXNpbmcNCiAgIERIQ1B2Ni4gIEluIHRoaXMgbmV3IGFkZHJl c3MgY29uZmlndXJhdGlvbiBwcm9jZWR1cmUsIHRoZSBwcmVmaXggaXMNCiAgIHByb3BhZ2F0ZWQg ZnJvbSBhIERIQ1B2NiBzZXJ2ZXIgdG8gaG9zdHMgdGhyb3VnaCBESENQdjYgbWVzc2FnZQ0KICAg ZXhjaGFuZ2luZyB3aGlsZSB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZXJzIGFyZSBpbmRlcGVuZGVu dGx5DQogICBnZW5lcmF0ZWQgYnkgdGhlIGhvc3RzLiAgSXQgZW5hYmxlcyBib3RoIGludGVncmFs IGFkZHJlc3MgYXNzaWdubWVudA0KICAgYW5kIHNlbGYtZ2VuZXJhdGVkIGFkZHJlc3NlcyBpbiBv bmUgc2luZ2xlIG1lY2hhbmlzbSwgREhDUHY2LiAgTm90ZSwNCiAgIGluIG1hbnkgc2NlbmFyaW9z LCBOZWlnaGJvciBEaXNjb3ZlcnkgW1JGQzQ4NjFdIGlzIHN0aWxsIG5lZWRlZCBmb3INCiAgIHJv dXRpbmcgYW5kIHJlYWNoYWJpbGl0eS4gIEluIG90aGVyIHNjZW5hcmlvcywgdGhpcyBtZWNoYW5p c20gZW5hYmxlcw0KICAgc3RhdGVsZXNzIGFkZHJlc3MgY29uZmlndXJhdGlvbiB3aGlsZSBSQSBh YnNlbnRzLg0KDQoNCjIuICBUZXJtaW5vbG9neQ0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxE IiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4g dGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBb UkZDMjExOV0uDQoNCiAgIFRoZSB0ZXJtaW5vbG9neSBpbiB0aGlzIGRvY3VtZW50IGlzIG1haW5s eSBiYXNlZCBvbiB0aGUgZGVmaW5pdGlvbnMNCiAgIGluIFtSRkMzMzE1XSBhbmQgW1JGQzM2MzNd Lg0KDQoNCjMuICBBcHBsaWNhYmlsaXR5DQoNCiAgIEluIHBvaW50LXRvLXBvaW50IGxpbmsgbW9k ZWwsIERIQ1B2NiBvcGVyYXRpb24gd2l0aCBob3N0LWdlbmVyYXRlZA0KICAgaW50ZXJmYWNlIGlk ZW50aWZpZXIsIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LCBtYXkgYmUgdXNlZC4NCiAgIFtS RkM0OTY4XSBwcm92aWRlcyBkaWZmZXJlbnQgSVB2NiBsaW5rIG1vZGVscyB0aGF0IGFyZSBzdWl0 YWJsZSBmb3INCiAgIDgwMi4xNiBiYXNlZCBuZXR3b3JrcyBhbmQgYSBwb2ludC10by1wb2ludCBs aW5rIG1vZGVsIGlzIHJlY29tbWVuZGVkLg0KICAgQWxzbywgM0dQUCBhbmQgM0dQUDIgaGF2ZSBl YXJsaWVyIGFkb3B0ZWQgdGhlIHBvaW50LXRvLXBvaW50IGxpbmsNCiAgIG1vZGVsIGJhc2VkIG9u IHRoZSByZWNvbW1lbmRhdGlvbnMgaW4gW1JGQzMzMTRdLiAgSW4gdGhpcyBtb2RlbCwgb25lDQog ICBwcmVmaXggY2FuIG9ubHkgYmUgYXNzaWduZWQgdG8gb25lIGludGVyZmFjZSBvZiBhIGhvc3Qg KG1vYmlsZQ0KICAgc3RhdGlvbikgYW5kIGRpZmZlcmVudCBob3N0cyAobW9iaWxlIHN0YXRpb25z KSBjYW4ndCBzaGFyZSBhIHByZWZpeC4NCiAgIFRoZSB1bmlxdWUgcHJlZml4IGNhbiBiZSB1c2Vk IHRvIGlkZW50aWZ5IHRoZSBob3N0LiAgSXQgaXMgbm90DQogICBuZWNlc3NhcnkgZm9yIGEgREhD UHY2IHNlcnZlciB0byBnZW5lcmF0ZSBhbiBpbnRlcmZhY2UgaWRlbnRpZmllciBmb3INCiAgIHRo ZSBob3N0LiAgVGhlIGhvc3QgbWF5IGdlbmVyYXRlIGl0cyBpbnRlcmZhY2UgaWRlbnRpZmllciBh cw0KICAgZGVzY3JpYmVkIGluIFtSRkM0OTQxXS4gIEFuIGludGVyZmFjZSBpZGVudGlmaWVyIGNv dWxkIGV2ZW4gYmUNCiAgIGdlbmVyYXRlZCB2aWEgcmFuZG9tIG51bWJlciBnZW5lcmF0aW9uLg0K DQogICBbUkZDMzk3Ml0gZGVmaW5lcyBDcnlwdG9ncmFwaGljYWxseSBHZW5lcmF0ZWQgQWRkcmVz c2VzIChDR0EpLCB3aGljaA0KICAgaXMgZ2VuZXJhdGVkIGZyb20gYSBnaXZpbmcgcHJlZml4IGFu ZCBhIHB1YmxpYyBzaWduYXR1cmUga2V5LiAgRm9yDQogICBzZWN1cml0eSByZWFzb25zLCBpdCBp cyBvbmx5IHByb3BlciB0byBiZSBnZW5lcmF0ZWQgdGhlIHVzZXIsIHRoZQ0KICAgaG9zdCBpdHNl bGYuICBJdCByZXF1ZXN0cyBhIHByZWZpeCBiZWZvcmUgdGhlIGludGVyZmFjZSBpZGVudGlmaWVy DQogICBjYW4gYmUgY29tcHV0ZWQuDQoNCiAgIE1vZGlmaWVkIEVVSS02NCBpbnRlcmZhY2UgaWRl bnRpZmllciBbRVVJLTY0XSBpcyBhbHNvIHR5cGljYWxseQ0KICAgZ2VuZXJhdGVkIGJ5IGhvc3Rz LiAgW1JGQzQ5NDFdIGhhcyBkZWZpbmVkIHRlbXBvcmFyeSBhZGRyZXNzZXMgZm9yDQogICBwcml2 YWN5IHB1cnBvc2VzLiAgVGhlIHRlbXBvcmFyeSBhZGRyZXNzZXMgaXMgYWxzbyBnZW5lcmF0ZWQg YnkgaG9zdHMNCiAgIHVzaW5nIHJhbmRvbSBhbGdvcml0aG0uDQoNCiAgIFRoZSBESENQdjYgb3Bl cmF0aW9ucyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgc3VwcG9ydHMNCiAgIGFib3ZlbWVudGlv bmVkIGFkZHJlc3MgbWV0aG9kcywgYW5kIHRoZSBob3N0LWdlbmVyYXRlZCBhZGRyZXNzZXMgdGhh dA0KICAgbWF5IGRlZmluZWQgaW4gdGhlIGZ1dHVyZS4NCg0KNC4gIEFkZHJlc3MgQXV0by1jb25m aWd1cmF0aW9uDQoNCiAgIFJvdXRlciBBZHZlcnRpc2VtZW50cyBpbiBORCBbUkZDNDg2MV0gYWxs b3cgcm91dGVycyB0byBpbmZvcm0gaG9zdHMNCiAgIGhvdyB0byBwZXJmb3JtIEFkZHJlc3MgQXV0 by1jb25maWd1cmF0aW9uLiAgRm9yIGV4YW1wbGUsIHJvdXRlcnMgY2FuDQogICBzcGVjaWZ5IHdo ZXRoZXIgaG9zdHMgc2hvdWxkIHVzZSBESENQdjYgYW5kL29yIHN0YXRlbGVzcyBhZGRyZXNzDQog ICBjb25maWd1cmF0aW9uLiAgSW4gUm91dGVyIEFkdmVydGlzZW1lbnQgbWVzc2FnZSwgTSBhbmQg TyBiaXRzIGFyZQ0KICAgdXNlZCBmb3IgaW5kaWNhdGlvbiBvZiBhZGRyZXNzIGF1dG8tY29uZmln dXJhdGlvbiBtb2RlLg0KDQogICBXaGF0ZXZlciBhZGRyZXNzIGF1dG8tY29uZmlndXJhdGlvbiBt b2RlIGEgaG9zdCB1c2VzLCB0aGUgZm9sbG93aW5nDQogICB0d28gcGFydHMgYXJlIG5lY2Vzc2Fy eSBmb3IgdGhlIGhvc3QgdG8gZm9ybXVsYXRlIGl0J3MgSVB2NiBhZGRyZXNzOg0KDQogICBvICBB IHByZWZpeC4gICJBIGJpdCBzdHJpbmcgdGhhdCBjb25zaXN0cyBvZiBzb21lIG51bWJlciBvZiBp bml0aWFsDQogICAgICBiaXRzIG9mIGFuIGFkZHJlc3MiIFtSRkM0ODYxXS4gIFRoZSBwcmVmaXhl cyBjYW4gYmUgYW5ub3VuY2VkDQogICAgICB0aHJvdWdoIFJvdXRlciBBZHZlcnRpc2VtZW50IG1l c3NhZ2UuICBQcmVmaXggYXNzaWdubWVudCBmcm9tIGENCiAgICAgIERIQ1B2NiBzZXJ2ZXIgaXMg bm90IGN1cnJlbnRseSBzdXBwb3J0Lg0KICAgbyAgQW4gaW50ZXJmYWNlIGlkZW50aWZpZXIuICAi RnJvbSBhZGRyZXNzIGF1dG9jb25maWd1cmF0aW9uJ3MNCiAgICAgIHBlcnNwZWN0aXZlLCBhbiBp bnRlcmZhY2UgaWRlbnRpZmllciBpcyBhIGJpdCBzdHJpbmcgb2Yga25vd24NCiAgICAgIGxlbmd0 aCIgW1JGQzQ4NjJdLiAgTW9kaWZpZWQgRVVJLTY0IGludGVyZmFjZSBpZGVudGlmaWVyIFtFVUkt NjRdDQogICAgICBpcyBhIHdpZGVseS11c2VkIGhvc3QgZ2VuZXJhdGVkIGludGVyZmFjZSBpZGVu dGlmaWVyLiAgSXQNCiAgICAgIGdlbmVyYXRlcyBpbnRlcmZhY2UgaWRlbnRpZmllciBmcm9tIHRo ZSBob3N0IE1BQyBhZGRyZXNzLiAgVGhlDQogICAgICBpbnRlcmZhY2UgaWRlbnRpZmllciBvZiBD R0EgW1JGQzM5NzJdIGlzIGdlbmVyYXRlZCBieSBjb21wdXRpbmcgYQ0KICAgICAgcHJlaWZ4IHRo YXQgd2lsbCBiZSB1c2VkIHRvIGZvcm0gdGhlIENHQSBhbmQgYSBjcnlwdG9ncmFwaGljIGhhc2gN CiAgICAgIG9mIGEgcHVibGljIGtleSBvZiBhIGhvc3QuICBUaGUgaG9zdCBpcyByZXNwb25zaWJs ZSBmb3IgaW50ZXJmYWNlDQogICAgICBpZGVudGlmaWVyIGdlbmVyYXRpb24uDQoNCiAgIEluIHRo ZSBORC1tYW5hZ2VkIGVudmlyb25tZW50LCBSQSBpcyB1c2VkIHRvIGFzc2lnbiB0aGUgcHJlZml4 Lg0KDQogICBTbyBmYXIsIHRoZXJlIGlzIG5vIG1lY2hhbmlzbSB0byBzdXBwb3J0IHRoZSBzY2Vu YXJpbyB0aGF0IHByZWZpeGVzDQogICBhcmUgbWFuYWdlZCBieSBhIERIQ1B2NiBzZXJ2ZXIuICBU aGlzIGRvY3VtZW50IHRhcmdldHMgdG8gbWVldCB0aGlzDQogICBnYXAuICBUaGUgREhDUHY2IG9w ZXJhdGlvbiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZW5hYmxlcyB0aGUNCiAgIERIQ1B2NiBz ZXJ2ZXIgdG8gYXNzaWduIGEgcHJlZml4LCByYXRoZXIgdGhhbiBhIGludGVncmFsIGFkZHJlc3Ms IHRvDQogICB0aGUgaG9zdCwgc28gdGhhdCB0aGUgaG9zdCBjYW4gb2J0YWluIGFuIElQdjYgYWRk cmVzcyBieSBjb21iaW5pbmcNCiAgIHRoZSBwcmVmaXggd2l0aCBpdHMgb3duIGdlbmVyYXRlZCBp bnRlcmZhY2UgaWRlbnRpZmllci4gIEl0IGVuYWJsZXMNCiAgIHRoZSBhdXRvIGFkZHJlc3MgY29u ZmlndXJhdGlvbiB0aHJvdWdoIERIQ1B2Ni4NCg0KDQo1LiAgREhDUHY2IE9wZXJhdGlvbg0KDQog ICBGaWd1cmUgMSBzaG93cyB0aGUgb3BlcmF0aW9uIG9mIHNlcGFyYXRpbmcgcHJlZml4IGFzc2ln bm1lbnQgYW5kDQogICBpbnRlcmZhY2UgaWRlbnRpZmllciBnZW5lcmF0aW9uIGluIHRoZSBESENQ djYuDQoNCiAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tLS0tLSsNCiAg ICAgICAgfEhvc3QoQ2xpZW50KXwgICAgICAgICB8REhDUHY2IFNlcnZlcnwNCiAgICAgICAgKy0t LS0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgfCAgMSBT b2xpY2l0L1JlcXVlc3QgICAgfA0KICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0t PiB8DQogICAgICAgICAgICAgIHwgIDIgUmVwbHkgd2l0aCBJQV9QQSAgIHwNCiAgICAgICAgICAg ICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0gfA0KICAgICAzIENvbWJpbmF0aW9uIG9mIFByZWZp eCAgICAgICAgICB8DQogICAgIGFuZCBJbnRlcmZhY2UgSWRlbnRpZmllciAgICAgICAgIHwNCiAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICAg ICAgICAgICBGaWd1cmUgMTogREhDUHY2IE9wZXJhdGlvbg0KDQogICAxLiAgQSBob3N0IHVzZXMg YSBTb2xpY2l0IG1lc3NhZ2UgdG8gZGlzY292ZXIgREhDUHY2IHNlcnZlcnMuDQogICAgICAgSW5m b3JtYXRpb24gUmVxdWVzdHMgY2FuIGJlIGluY2x1ZGVkIGluIHRoZSBTb2xpY2l0IG1lc3NhZ2Ug b3IgYQ0KICAgICAgIFJlcXVlc3QgbWVzc2FnZSBhZnRlciBkaXNjb3ZlcnkgcHJvY2VkdXJlLiAg SWYgYSBob3N0IHRoYXQgd2FudHMNCiAgICAgICB0byB1c2UgaG9zdCBnZW5lcmF0ZWQgYWRkcmVz c2VzLCBpdCBTSE9VTEQgcmVxdWVzdCBwcmVmaXgNCiAgICAgICBhc3NpZ25tZW50IGV4cGxpY2l0 bHkgYnkgaW5jbHVkaW5nIGFuIElBX1BBIGluIGEgU29saWNpdCBvciBhDQogICAgICAgUmVxdWVz dCBtZXNzYWdlLCBpbiB3aGljaCBhbiBJQUlEIGlzIHByb3ZpZGVkIGJ5IHRoZSBob3N0Lg0KICAg Mi4gIFRoZSBESENQdjYgc2VydmVyIGFzc2lnbnMgb25lIG9yIG1vcmUgcHJlZml4ZXMgdG8gdGhl IGhvc3QgaW4gdGhlDQogICAgICAgUmVwbHkgbWVzc2FnZXMgcmVzcG9uZGluZyB0byB0aGUgcHJl Zml4IHJlcXVlc3RzIGZyb20gdGhlIGhvc3RzLg0KICAgICAgIEEgc2VydmVyIE1VU1QgcmV0dXJu IHRoZSBzYW1lIHNldCBvZiBwcmVmaXhlcyBmb3IgdGhlIHNhbWUgSUFfUEENCiAgICAgICAoYXMg aWRlbnRpZmllZCBieSB0aGUgSUFJRCkgYXMgbG9uZyBhcyB0aG9zZSBwcmVmaXhlcyBhcmUgc3Rp bGwNCiAgICAgICB2YWxpZC4gIEFmdGVyIHRoZSBsaWZldGltZXMgb2YgdGhlIHByZWZpeGVzIGlu IGFuIElBX1RBIGhhdmUNCiAgICAgICBleHBpcmVkLCB0aGUgSUFJRCBtYXkgYmUgcmV1c2VkIHRv IGlkZW50aWZ5IGEgbmV3IElBX1BBIHdpdGggbmV3DQogICAgICAgcHJlZml4LiAgSWYgdGhlcmUg aXMgbm90IGEgcHJvcGVyIHByZWZpeCBhdmFpbGFibGUsIGENCiAgICAgICBOb1ByZWZpeEF2YWls IChkZWZpbmVkIGluIFtSRkMzNjMzXSkgc3RhdHVzLWNvZGUgaXMgcmV0dXJuZWQgdG8NCiAgICAg ICB0aGUgaG9zdCBhbmQgdGhlIHByb2NlZHVyZSBpcyB0ZXJtaW5hdGVkLg0KICAgMy4gIFRoZSBo b3N0IGdlbmVyYXRlcyBhbiBpbnRlcmZhY2UgaWRlbnRpZmllciBhbmQgZm9ybXVsYXRlcyBhDQog ICAgICAgY29tYmluZWQgSVB2NiBhZGRyZXNzIGJ5IGNvbmNhdGVuYXRpbmcgdGhlIGFzc2lnbmVk IHByZWZpeCBhbmQNCiAgICAgICB0aGUgc2VsZi1nZW5lcmF0ZWQgaW50ZXJmYWNlIGlkZW50aWZp ZXIuDQoNCiAgIEFmdGVyIHRoZSBob3N0IGdlbmVyYXRlcyBhbiBJUHY2IGFkZHJlc3MgdXNpbmcg dGhlIGFib3ZlIHByb2NlZHVyZSwNCiAgIHRoZSBob3N0IG1heSBzZW5kIGEgUmVxdWVzdCBtZXNz YWdlIHRvIHRoZSBESENQdjYgc2VydmVyIGluIG9yZGVyIHRvDQogICBjb25maXJtIHRoZSB1c2Fn ZSBvZiB0aGUgbmV3IGFkZHJlc3MuICBUaGUgY29uZmlybWF0aW9uIHByb2NlZHVyZSBtYXkNCiAg IGJlIGNvbXBsZXRlZCB0b2dldGhlciB3aXRoIHRoZSBhZGRyZXNzIHJlZ2lzdHJhdGlvbiBwcm9j ZWR1cmUNCiAgIFtJLUQuaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRpb25dLiAgSG93ZXZlciwgdGhl IGNvbmZpcm1hdGlvbg0KICAgcHJvY2VkdXJlIGlzIG91dCBvZiBzY29wZS4NCg0KICAgV2hlbiB0 aGUgaG9zdCByZWFjaGVzIFQxIG9yIFQyIGRlZmluZWQgaW4gU2VjdGlvbiA2LjEsIGl0IFNIT1VM RCB1c2UNCiAgIHRoZSBzYW1lIG1lc3NhZ2UgZXhjaGFuZ2VzLCBhcyBkZXNjcmliZWQgaW4gc2Vj dGlvbiAxOCwgIkRIQ1AgQ2xpZW50LQ0KICAgSW5pdGlhdGVkIENvbmZpZ3VyYXRpb24gRXhjaGFu Z2UiIG9mIFtSRkMzMzE1XSwgdG8gb2J0YWluIG9yIHVwZGF0ZQ0KICAgcHJlZml4KGVzKSBmcm9t IGEgREhDUHY2IHNlcnZlci4NCg0KICAgQSBESENQdjYgc2VydmVyIE1BWSBpbml0aWF0aXZlbHkg c2VuZCBhIHJlY29uZmlndXJhdGlvbiBtZXNzYWdlIHRvDQogICB0aGUgaG9zdCwgYXMgZGVzY3Jp YmVkIGluIHNlY3Rpb24gMTksICJESENQIFNlcnZlci1Jbml0aWF0ZWQNCiAgIENvbmZpZ3VyYXRp b24gRXhjaGFuZ2UiIG9mIFtSRkMzMzE1XSwgdG8gY2F1c2UgcHJlZml4KGVzKSBpbmZvcm1hdGlv bg0KICAgdXBkYXRlLg0KDQogICBJZiBhbiBJQV9QQSBjYXBhYmxlIGNsaWVudCBjb25uZWN0cyB0 byBhIG5ldHdvcmssIGFuZCB0aGUgREhDUHY2DQogICBzZXJ2ZXIgaXMgbm90IElBX1BBIGNhcGFi bGUsIHRoZSBTb2xpY2l0IG9yIFJlcXVlc3QgbWVzc2FnZSB3aXRoDQogICBJQV9QQSBPcHRpb24g d2lsbCByZXN1bHQgaW4gbm8gUmVwbHksIFJlcGx5IHdpdGhvdXQgSUFfUEFzLCBvciBSZXBseQ0K ICAgd2l0aCBhIFN0YXR1cyBDb2RlIGNvbnRhaW5pbmcgVW5zcGVjRmFpbC4gIFRoZSBjbGllbnQg TUFZIGRlY2lkZSB0aGUNCiAgIG5ldHdvcmsgZG9lcyBub3Qgc3VwcG9ydCBJQV9QQSBpbW1lZGlh dGVseSBvciBhZnRlciBhIHBlcmlvZCBvZg0KICAgc29saWNpdGluZyAod2l0aCBsaW1pdGVkIHJl dHJhbnNtaXNzaW9ucyB0aW1lcykuICBUaGVuLCBpdCBNQVkNCiAgICJmYWlsb3ZlciIgdG8gSUFf TkEvSUFfVEEgcmVxdWVzdHMuDQoNCg0KNi4gIERIQ1B2NiBJQV9QQSBPcHRpb24NCg0KICAgSW4g dGhpcyBzZWN0aW9uLCBvbmUgbmV3IG9wdGlvbiBpcyBkZWZpbmVkLCBJZGVudGl0eSBBc3NvY2lh dGlvbiBmb3INCiAgIFByZWZpeCBBc3NpZ25tZW50IE9wdGlvbiAuICBUaGUgZm9ybWF0IG9mIHRo aXMgbmV3IERIQ1B2NiBJQV9QQQ0KICAgT3B0aW9uIGhhcyBiZWVuIGRlbGliZXJhdGVseSBkZXNp Z25lZCB0byBiZSB0aGUgc2FtZSB3aXRoIElBX1BEDQogICBvcHRpb25bUkZDMzYzM10uICBUaGUg SUFfUEQgUHJlZml4IGFuZCBJQSBBZGRyZXNzIHN1Yi1vcHRpb25zIGZyb20NCiAgIElBX1BEIG9w dGlvbiBhcmUgYWxzbyByZXVzZWQuICBIb3dldmVyLCB0aGUgdHdvIG9wdGlvbnMgYXJlIGRpZmZl cmVudA0KICAgb24gdGhlIHNlbWFudGljcyBhbmQgdXNhZ2UgbW9kZWxzLg0KDQogICBDb21wYXJp bmcgd2l0aCBQcmVmaXggSW5mb3JtYXRpb24gT3B0aW9uIGluIE5ELCBTZWN0aW9uIDQuNi4yIG9m DQogICBbUkZDNDg2MV0sIHRoZSBJQV9QQSBvcHRpb24gZG9lcyBub3QgcHJvdmlkZSBMIGZsYWcg YW5kIEEgZmxhZy4gIFRoZQ0KICAgQSAoYXV0b25vbW91cyBhZGRyZXNzLWNvbmZpZ3VyYXRpb24g ZmxhZykgaXNuJ3QgbmVlZCBvYnZpb3VzbHkNCiAgIGJlY2F1c2UgdGhlIElBX1BBIGlzIGltcGxp Y2l0IGZvciBzdGF0ZWxlc3MgYWRkcmVzcyBjb25maWd1cmF0aW9uLg0KICAgQmVjYXVzZSB0aGUg SUFfUEEgaXMgb25seSBhZGRyZXNzIHJlbGV2YW50LCBpdCBkb2VzIG5vdCByZWxldmFudCB0bw0K ICAgcmVhY2hhYmlsaXR5IG9yIHJvdXRpbmcgYW5kIHRoZSBESENQdjYgc2VydmVyIG1heSBub3Qg c3VyZSB0aGUgb24tDQogICBsaW5rIHN0YXRlLiAgU28gTCAob24tTGluaykgZmxhZyBpcyBub3Qg aW5jbHVkZS4gIFRoZSBESENQdjYgY2xpZW50DQogICBzaG91bGQgdHJlYXQgdGhlIHByZWZpeCBh cyBzYW1lIGFzIEwgZmxhZyBub3Qgc2V0LCB3aGljaCBtYWtlcyBubw0KICAgc3RhdGVtZW50IGFi b3V0IG9uLWxpbmsgb3Igb2ZmLWxpbmsgcHJvcGVydGllcyBvZiB0aGUgcHJlZml4Lg0KDQo2LjEu ICBJZGVudGl0eSBBc3NvY2lhdGlvbiBmb3IgUHJlZml4IEFzc2lnbm1lbnQgT3B0aW9uDQoNCiAg IFRoZSBJQV9QQSBvcHRpb24gaXMgdXNlZCB0byBjYXJyeSBhIHByZWZpeCBhc3NpZ25tZW50IGlk ZW50aXR5DQogICBhc3NvY2lhdGlvbiwgdGhlIHBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRoIHRo ZSBJQV9QQSBhbmQgdGhlDQogICBwcmVmaXhlcyBhc3NvY2lhdGVkIHdpdGggaXQuDQoNCiAgIFRo ZSBmb3JtYXQgb2YgdGhlIElBX1BBIG9wdGlvbiBpczoNCg0KICAgICAgICAwICAgICAgICAgICAg ICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQ0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAgICAgICAgIE9QVElPTl9JQV9QQSAg ICAgICAgICB8ICAgICAgICAgb3B0aW9uLWxlbmd0aCAgICAgICAgIHwNCiAgICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgSUFJRCAoNCBvY3RldHMpICAgICAg ICAgICAgICAgICAgICAgICB8DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQyICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgIC4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAuDQogICAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgSUFfUEEtb3B0aW9ucyAg ICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgICAuICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICBvcHRpb24tY29kZTogICAgICBPUFRJT05fSUFfUEEgKFRCQTEpDQoNCiAgIG9wdGlvbi1s ZW5ndGg6ICAgIDEyICsgbGVuZ3RoIG9mIElBX1BBLW9wdGlvbnMgZmllbGQuDQoNCiAgIElBSUQ6 ICAgICAgICAgICAgIFRoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhpcyBJQV9QQTsgdGhlIElB SUQgbXVzdA0KICAgICAgICAgICAgICAgICAgICAgYmUgdW5pcXVlIGFtb25nIHRoZSBpZGVudGlm aWVycyBmb3IgYWxsIG9mIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgIGhvc3QncyBJQV9QQXMu IFRoZSBudW1iZXIgc3BhY2UgZm9yIElBX1BBIElBSURzIGlzDQogICAgICAgICAgICAgICAgICAg ICBzZXBhcmF0ZSBmcm9tIHRoZSBudW1iZXIgc3BhY2VzIGZvciBJQV9UQSBhbmQgSUFfTkENCiAg ICAgICAgICAgICAgICAgICAgIElBSURzDQoNCiAgIFQxOiAgICAgICAgICAgICAgIFRoZSB0aW1l IGF0IHdoaWNoIHRoZSBob3N0IHNob3VsZA0KICAgICAgICAgICAgICAgICAgICAgY29udGFjdCB0 aGUgREhDUHY2IHNlcnZlciBmcm9tIHdoaWNoIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgcHJl Zml4ZXMgaW4gdGhlIElBX1BBIHdlcmUgb2J0YWluZWQgdG8gZXh0ZW5kIHRoZQ0KICAgICAgICAg ICAgICAgICAgICAgbGlmZXRpbWVzIG9mIHRoZSBwcmVmaXhlcyBhc3NpZ25lZCB0byB0aGUgSUFf UEE7DQogICAgICAgICAgICAgICAgICAgICBUMSBpcyBhIHRpbWUgZHVyYXRpb24gcmVsYXRpdmUg dG8gdGhlIGN1cnJlbnQgdGltZQ0KICAgICAgICAgICAgICAgICAgICAgZXhwcmVzc2VkIGluIHVu aXRzIG9mIHNlY29uZHMuDQoNCiAgIFQyOiAgICAgICAgICAgICAgIFRoZSB0aW1lIGF0IHdoaWNo IHRoZSBob3N0IHNob3VsZA0KICAgICAgICAgICAgICAgICAgICAgY29udGFjdCBhbnkgYXZhaWxh YmxlIERIQ1B2NiBzZXJ2ZXIgdG8gZXh0ZW5kDQogICAgICAgICAgICAgICAgICAgICB0aGUgbGlm ZXRpbWVzIG9mIHRoZSBwcmVmaXhlcyBhc3NpZ25lZCB0byB0aGUNCiAgICAgICAgICAgICAgICAg ICAgIElBX1BBOyBUMiBpcyBhIHRpbWUgZHVyYXRpb24gcmVsYXRpdmUgdG8gdGhlDQogICAgICAg ICAgICAgICAgICAgICBjdXJyZW50IHRpbWUgZXhwcmVzc2VkIGluIHVuaXRzIG9mIHNlY29uZHMu DQoNCiAgIElBX1BBLW9wdGlvbnM6ICAgIE9wdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHRoaXMgSUFf UEEuDQoNCiAgIFRoZSBkZXRhaWxzIG9mIHRoZSBmaWVsZHMgYXJlIHNpbWlsYXIgdG8gdGhlIElB X1BEIG9wdGlvbiBkZXNjcmlwdGlvbg0KICAgaW4gW1JGQzM2MzNdLiAgVGhlIGRpZmZlcmVuY2Ug aXMgaGVyZSBhIERIQ1B2NiBzZXJ2ZXIgYW5kIGEgaG9zdA0KICAgaW52b2x2ZWQsIHdoaWxlIGEg ZGVsZWdhdGluZyByb3V0ZXIgYW5kIHJlcXVlc3Rpbmcgcm91dGVyIGludm9sdmVkIGluDQogICBb UkZDMzYzM10uDQoNCjYuMi4gIElBX1BBIFByZWZpeCBPcHRpb24NCg0KICAgT1BUSU9OX0lBUFJF RklYICgyNikgIklBX1BEIFByZWZpeCBPcHRpb24iIGRlZmluZWQgaW4gU2VjdGlvbiAxMCBvZg0K ICAgW1JGQzM2MzNdIGlzIHJldXNlZC4NCg0KICAgT3JpZ2luYWxseSwgdGhlIG9wdGlvbiBpcyB1 c2VkIGZvciBjb252ZXlpbmcgcHJlZml4IGluZm9ybWF0aW9uDQogICBiZXR3ZWVuIGEgZGVsZWdh dGluZyByb3V0ZXIgYW5kIGEgcmVxdWVzdGluZyByb3V0ZXIuICBIZXJlIHRoZSBJQV9QRA0KICAg UHJlZml4IG9wdGlvbiBpcyB1c2VkIHRvIHNwZWNpZnkgSVB2NiBhZGRyZXNzIHByZWZpeGVzIGFz c29jaWF0ZWQNCiAgIHdpdGggYW4gSUFfUEEgaW4gU2VjdGlvbiA2LjEuICBUaGUgSUFfUEQgUHJl Zml4IG9wdGlvbiBtdXN0IGJlDQogICBlbmNhcHN1bGF0ZWQgaW4gdGhlIElBX1BBLW9wdGlvbnMg ZmllbGQgb2YgYW4gSUFfUEEgb3B0aW9uLg0KDQogICBOb3RlLCB0aGUgUERfRVhDTFVERSBvcHRp b24gW1JGQzY2MDNdIFNIT1VMRCBOT1QgYmUgZW5jYXBzdWxhdGVkIGluDQogICB0aGUgSUFQUkVG SVggb3B0aW9ucyB0aGF0IGFyZSBlbmNhcHN1bGF0ZWQgaW4gYW4gSUFfUEEuDQoNCg0KNy4gIElB TkEgY29uc2lkZXJhdGlvbg0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgREhDUHY2 IFtSRkMzMzE1XSBvcHRpb24sIHdoaWNoIG11c3QgYmUNCiAgIGFzc2lnbmVkIE9wdGlvbiBUeXBl IHZhbHVlcyB3aXRoaW4gdGhlIG9wdGlvbiBudW1iZXJpbmcgc3BhY2UgZm9yDQogICBESENQdjYg bWVzc2FnZXM6DQoNCiAgIFRoZSBPUFRJT05fSUFfUEEgT3B0aW9uIChUQkExKSwgZGVzY3JpYmVk IGluIFNlY3Rpb24gNi4xLg0KDQoNCjguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBT ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBESENQdjYgYXJlIGRlc2NyaWJlZCBpbiBbUkZDMzMx NV0uDQoNCiAgIFRvIGd1YXJkIGFnYWluc3QgYXR0YWNrcyB0aHJvdWdoIHByZWZpeCBhc3NpZ25t ZW50LCBhIGhvc3QgYW5kIGENCiAgIERIQ1B2NiBzZXJ2ZXIgU0hPVUxEIHVzZSBESENQdjYgYXV0 aGVudGljYXRpb24gYXMgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDIxLCAiQXV0aGVudGljYXRp b24gb2YgREhDUCBtZXNzYWdlcyIgb2YgW1JGQzMzMTVdIG9yIFNlY3VyZQ0KICAgREhDUHY2IFtJ LUQuaWV0Zi1kaGMtc2VjdXJlLWRoY3B2Nl0gLg0KDQoNCjkuICBBY2tub3dsZWRnZW1lbnRzDQoN CiAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmtzIFN1cmVzaCBLcmlzaG5hbiwgVGVk IExlbW9uLCBCaW5nDQogICBMaXUsIEFuZHJlIEtvc3R1ciwgR2F1cmF2IEhhbHdhc2lhLCBCZXJu aWUgVm9seiBhbmQgb3RoZXIgbWVtYmVycyBvZg0KICAgREhDIFdHIGZvciB0aGVpciB2YWx1YWJs ZSBjb21tZW50cy4NCg0KDQoxMC4gIFJlZmVyZW5jZXMNCg0KMTAuMS4gIE5vcm1hdGl2ZSBSZWZl cmVuY2VzDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBp biBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJD UCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFtSRkMzMzE1XSAgRHJvbXMsIFIuLCBC b3VuZCwgSi4sIFZvbHosIEIuLCBMZW1vbiwgVC4sIFBlcmtpbnMsIEMuLA0KICAgICAgICAgICAg ICBhbmQgTS4gQ2FybmV5LCAiRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgZm9y DQogICAgICAgICAgICAgIElQdjYgKERIQ1B2NikiLCBSRkMgMzMxNSwgSnVseSAyMDAzLg0KDQog ICBbUkZDMzYzM10gIFRyb2FuLCBPLiBhbmQgUi4gRHJvbXMsICJJUHY2IFByZWZpeCBPcHRpb25z IGZvciBEeW5hbWljDQogICAgICAgICAgICAgIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCAo REhDUCkgdmVyc2lvbiA2IiwgUkZDIDM2MzMsDQogICAgICAgICAgICAgIERlY2VtYmVyIDIwMDMu DQoNCiAgIFtSRkMzOTcxXSAgQXJra28sIEouLCBLZW1wZiwgSi4sIFppbGwsIEIuLCBhbmQgUC4g TmlrYW5kZXIsICJTRWN1cmUNCiAgICAgICAgICAgICAgTmVpZ2hib3IgRGlzY292ZXJ5IChTRU5E KSIsIFJGQyAzOTcxLCBNYXJjaCAyMDA1Lg0KDQogICBbUkZDMzk3Ml0gIEF1cmEsIFQuLCAiQ3J5 cHRvZ3JhcGhpY2FsbHkgR2VuZXJhdGVkIEFkZHJlc3NlcyAoQ0dBKSIsDQogICAgICAgICAgICAg IFJGQyAzOTcyLCBNYXJjaCAyMDA1Lg0KDQogICBbUkZDNDI5MV0gIEhpbmRlbiwgUi4gYW5kIFMu IERlZXJpbmcsICJJUCBWZXJzaW9uIDYgQWRkcmVzc2luZw0KICAgICAgICAgICAgICBBcmNoaXRl Y3R1cmUiLCBSRkMgNDI5MSwgRmVicnVhcnkgMjAwNi4NCg0KICAgW1JGQzQ4NjFdICBOYXJ0ZW4s IFQuLCBOb3JkbWFyaywgRS4sIFNpbXBzb24sIFcuLCBhbmQgSC4gU29saW1hbiwNCiAgICAgICAg ICAgICAgIk5laWdoYm9yIERpc2NvdmVyeSBmb3IgSVAgdmVyc2lvbiA2IChJUHY2KSIsIFJGQyA0 ODYxLA0KICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNy4NCg0KICAgW1JGQzQ4NjJdICBUaG9t c29uLCBTLiwgTmFydGVuLCBULiwgYW5kIFQuIEppbm1laSwgIklQdjYgU3RhdGVsZXNzDQogICAg ICAgICAgICAgIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24iLCBSRkMgNDg2MiwgU2VwdGVtYmVy IDIwMDcuDQoNCiAgIFtSRkM0OTQxXSAgTmFydGVuLCBULiwgRHJhdmVzLCBSLiwgYW5kIFMuIEty aXNobmFuLCAiUHJpdmFjeQ0KICAgICAgICAgICAgICBFeHRlbnNpb25zIGZvciBTdGF0ZWxlc3Mg QWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiBpbg0KICAgICAgICAgICAgICBJUHY2IiwgUkZDIDQ5 NDEsIFNlcHRlbWJlciAyMDA3Lg0KDQogICBbUkZDNjYwM10gIEtvcmhvbmVuLCBKLiwgU2F2b2xh aW5lbiwgVC4sIEtyaXNobmFuLCBTLiwgYW5kIE8uIFRyb2FuLA0KICAgICAgICAgICAgICAiUHJl Zml4IEV4Y2x1ZGUgT3B0aW9uIGZvciBESENQdjYtYmFzZWQgUHJlZml4DQogICAgICAgICAgICAg IERlbGVnYXRpb24iLCBSRkMgNjYwMywgTWF5IDIwMTIuDQoNCjEwLjIuICBJbmZvcm1hdGl2ZSBy ZWZlcmVuY2VzDQoNCiAgIFtSRkMzMzE0XSAgV2Fzc2VybWFuLCBNLiwgIlJlY29tbWVuZGF0aW9u cyBmb3IgSVB2NiBpbiBUaGlyZA0KICAgICAgICAgICAgICBHZW5lcmF0aW9uIFBhcnRuZXJzaGlw IFByb2plY3QgKDNHUFApIFN0YW5kYXJkcyIsDQogICAgICAgICAgICAgIFJGQyAzMzE0LCBTZXB0 ZW1iZXIgMjAwMi4NCg0KICAgW1JGQzQ5NjhdICBNYWRhbmFwYWxsaSwgUy4sICJBbmFseXNpcyBv ZiBJUHY2IExpbmsgTW9kZWxzIGZvciA4MDIuMTYNCiAgICAgICAgICAgICAgQmFzZWQgTmV0d29y a3MiLCBSRkMgNDk2OCwgQXVndXN0IDIwMDcuDQoNCiAgIFtJLUQuaWV0Zi1kaGMtc2VjdXJlLWRo Y3B2Nl0NCiAgICAgICAgICAgICAgSmlhbmcsIFMuIGFuZCBTLiBTaGVuLCAiU2VjdXJlIERIQ1B2 NiBVc2luZyBDR0FzIiwNCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1kaGMtc2VjdXJlLWRoY3B2 Ni0wNiAod29yayBpbiBwcm9ncmVzcyksDQogICAgICAgICAgICAgIE1hcmNoIDIwMTIuDQoNCiAg IFtJLUQuaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRpb25dDQogICAgICAgICAgICAgIEppYW5nLCBT LiBhbmQgRy4gQ2hlbiwgIkEgR2VuZXJpYyBJUHY2IEFkZHJlc3Nlcw0KICAgICAgICAgICAgICBS ZWdpc3RyYXRpb24gU29sdXRpb24gVXNpbmcgREhDUHY2IiwNCiAgICAgICAgICAgICAgZHJhZnQt aWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRpb24tMDAgKHdvcmsgaW4gcHJvZ3Jlc3MpLA0KICAgICAg ICAgICAgICBNYXkgMjAxMi4NCg0KICAgW0VVSS02NF0gICAiR3VpZGVsaW5lcyBmb3IgNjQtYml0 IEdsb2JhbCBJZGVudGlmaWVyIChFVUktNjQpDQogICAgICAgICAgICAgIFJlZ2lzdHJhdGlvbiBB dXRob3JpdHkiLCBodHRwOi8vc3RhbmRhcmRzLmllZWUub3JnLw0KICAgICAgICAgICAgICByZWdh dXRoL291aS90dXRvcmlhbHMvRVVJNjQuaHRtbCIsIE1hcmNoIDE5OTcu --_002_5D36713D8A4E7348A7E10DF7437A4B9239F2522Fszxeml545mbxchi_-- From mohamed.boucadair@orange.com Sun Aug 26 22:26:41 2012 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 5249E21F8602 for ; Sun, 26 Aug 2012 22:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auXW7SVG+nwg for ; Sun, 26 Aug 2012 22:26:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1CF21F855F for ; Sun, 26 Aug 2012 22:26:40 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1106222C61E; Mon, 27 Aug 2012 07:26:38 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E862D238048; Mon, 27 Aug 2012 07:26:37 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 27 Aug 2012 07:26:14 +0200 From: To: Andre Kostur Date: Mon, 27 Aug 2012 07:26:13 +0200 Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2CD8Yw0Ney5h2CTPuIXivEztkbSwCBJL+g Message-ID: <94C682931C08B048B7A8645303FDC9F36E5332AB59@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5332AAED@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.27.42119 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 27 Aug 2012 05:26:41 -0000 Dear Andre, I see the point.=20 I updated the text accordingly.=20 Thanks. Cheers, Med=20 >-----Message d'origine----- >De : Andre Kostur [mailto:akostur@incognito.com]=20 >Envoy=E9 : vendredi 24 ao=FBt 2012 17:48 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : dhcwg@ietf.org >Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay=20 >Agents (draft-boucadair-dhc-triggered-reconfigure) > >Normally the server is being told administratively to reconfigure a >client, and presumably which of the three methods to use. This is >just another form of that. I could see it being changed to: the RA >MAY supply an OPTION_RECONF_MSG, and if not supplied, the server may >determine which form of Reconfigure to use. > >On Fri, Aug 24, 2012 at 8:35 AM, wrote: >> Dear Andre, >> >> Please see inline. >> >> Cheers, >> Med >> >>>-----Message d'origine----- >>>De : Andre Kostur [mailto:akostur@incognito.com] >>>Envoy=E9 : vendredi 24 ao=FBt 2012 17:17 >>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>Cc : dhcwg@ietf.org >>>Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay >>>Agents (draft-boucadair-dhc-triggered-reconfigure) >>> >>>A question that popped into my mind is how does the server decide >>>whether the client will be doing a Renew, Rebind, or >>>Information-Request? Perhaps the RA MUST supply an=20 >OPTION_RECONF_MSG? >> >> Med: What I had initially in mind for this new message: is=20 >to not require any change to the way RECONFIGURE is managed by=20 >the server but only provide a signal to the DHCPv6 server to=20 >issue one. Is there any particular reason you think the RA=20 >should be involved in that process? >> >>> >>>Also, is the RA expected to monitor the clients as to=20 >whether they are >>>reconfigure capable, or will the RA rely on the server to be watching >>>that? >> >> Med: I would say no. >> >> Do we want the server to be able to report back to the RA that >>>the client cannot do Reconfigure? >> >> Med: I would say no. >> >>> >>> >>>On Fri, Aug 24, 2012 at 4:49 AM,=20 > wrote: >>>> >>>> Dear all, >>>> >>>> I submitted a new I-D defining a new message type to trigger >>>a server to >>>> issue a RECONFIGURE message when RSSO is used. >>>> >>>> The text is available at: >>>> >>>https://datatracker.ietf.org/doc/draft-boucadair-dhc-triggered- >>>reconfigure >>>> >>>> Comments and suggestions are more than welcome. >>>> >>>> Cheers, >>>> Med >>>> _______________________________________________ >>>> dhcwg mailing list >>>> dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> >>> >>> >>>-- >>>Andre Kostur >>> > > > >--=20 >Andre Kostur >Senior Product Design Engineer >P: 604-678-2864 >E: akostur@incognito.com >Toll-Free: 1-800-877-1856 > > >F: 604-678-2864 >VoIP: sip:864@sip.incognito.com >= From mohamed.boucadair@orange.com Sun Aug 26 22:38:31 2012 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 991AE21F84CD for ; Sun, 26 Aug 2012 22:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjg7pC8yOXp2 for ; Sun, 26 Aug 2012 22:38:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1761D21F84A7 for ; Sun, 26 Aug 2012 22:38:30 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 96A62324614; Mon, 27 Aug 2012 07:38:28 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7419C23804B; Mon, 27 Aug 2012 07:38:28 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 27 Aug 2012 07:38:04 +0200 From: To: "Gaurav Halwasia (ghalwasi)" , Ted Lemon Date: Mon, 27 Aug 2012 07:38:03 +0200 Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGAABLMSoAADm1sMABI9adwAACgFqAAHzWKkA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E55733CA9@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> <264AF650-EB56-4C12-9A1D-F1A92FEACB39@nominum.com> <94C682931C08B048B7A8645303FDC9F36E5332AACB@PUEXCB1B.nanterre.francetelecom.fr> <90903C21C73202418A48BFBE80AEE5EB0E836A@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB0E8385@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB0E8385@xmb-aln-x06.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E55733CA9PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.27.42119 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 27 Aug 2012 05:38:31 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E55733CA9PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Gaurav, Please see inline. Cheers, Med ________________________________ De : Gaurav Halwasia (ghalwasi) [mailto:ghalwasi@cisco.com] Envoy=E9 : dimanche 26 ao=FBt 2012 16:48 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon Cc : dhcwg@ietf.org Objet : RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bou= cadair-dhc-triggered-reconfigure) Specifying the correct reference to RFC. Hi Med, I have few comments on this draft. 1.) I think just restricting this proposed capability to RSOO is not a good= idea. I can think of use cases in which relay agent might want to trigger = RECONFIGURE in non-RSOO scenarios as well. (Infact I am working on a I.D wh= ich is work in progress which proposes similar capability in DHCPv4). Proba= bly you can refer RSOO as the use case for this draft instead of restrictin= g this for only RSOO scenario. This is also inline with the comments from T= ed on the other email thread on not including RSOO in the RECONFIG-REQUEST= message. [Med] In my local copy, including RSOO is now optional: "an RA MAY include = RSOO option". I also added a sentence to say this procedure can be applied = in non-RSO scenarios. Would you be fine with these changes? 2.) I also agree comment from Andre Kostur wherein Relay Agent MAY include = OPTION_RECONF_MSG option in the RECONFIGURE-REQUEST message to indicate wha= t do you want the client to send after receiving RECONFIGURE message. i.e R= enew/Info-Request. Infact there is a RFC which added capability to trigger = REBIND after receiving RECONFIGURE message. (Rebind Capability in DHCPv6 Re= configure Messages - RFC 6644). So it would certainly be useful to include = OPTION_RECONF_MSG on this message. [Med] Agreed. I updated my local copy accordingly. Thanks, Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of moham= ed.boucadair@orange.com Sent: Friday, August 24, 2012 8:10 PM To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bo= ucadair-dhc-triggered-reconfigure) Dear Ted, Thank your for the review. Please see inline. Cheers, Med ________________________________ De : Ted Lemon [mailto:Ted.Lemon@nominum.com] Envoy=E9 : vendredi 24 ao=FBt 2012 15:44 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : dhcwg@ietf.org Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bou= cadair-dhc-triggered-reconfigure) On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com wrote: Comments and suggestions are more than welcome. In section 2, you propose that the reconfigure-request include an RSOO, but= this is actually not necessary; what will happen is that the RECONFIGURE-R= EQUEST will trigger a RECONFIGURE, the client will then send a RENEW, the r= elay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAM= E option, and the DHCP server will send a REPLY containing the AFTR_NAME op= tion. So there's no need to include that in the RECONFIGURE-REQUEST. Th= is is a minor point--it would certainly do no _harm_ to include the AFTR_NA= ME option in the RSOO on the RECONFIGURE-REQUEST. [Med] That's make sense too. I changed "MUST" to "MAY" in Section 3.3: the = point is to provide the dhcp server with more information to help the serve= r whether a RECONFIGURE is needed. If for some reason, the server detects t= he same information has been already supplied to the client, it may decide = to not generate a RECONFIGURE message. So of course if you make this change, you'd have to fix up section 3.2. I would also change this, in section 3.2: If the server is configured to reject RECONFIGURE-REQUEST, any received REC= ONFIGURE-REQUEST is silently dropped. To this: If the server is configured to reject RECONFIGURE-REQUEST, the server MUST = silently discard any RECONFIGURE-REQUEST it receives. It might be good to consistently say "silently discard" instead of "discard= " in that section. [Med] I updated my local copy. Section 3.3 also mentions sending the RSOO, and, if you accept my argument = above, should not. [Med] Changed "MUST" to "MAY" for the reason mentioned above in my local co= py. In addition to the issues discussed in the Security Considerations section = of RFC5007, you might also want to add this (possibly to section 3.2, not t= o the Security Considerations section): Because this message provides a mechanism for triggering the DHCP Reconfigu= re message, and the DHCP Reconfigure message can be used by an attacker to = control the timing of a DHCP renewal, the DHCP server must have some mechan= ism for determining that the relay agent is a trusted entity. RECONFIGURE= -REQUEST messages originating from unknown relay agents MUST be silently dr= opped. [Med] I updated Section 3.2 with the proposed text. Thanks. Aside from this, the document looks good, and seems useful. Are you propo= sing that the working group should adopt this work? [Med] Yes. Thanks. --_000_94C682931C08B048B7A8645303FDC9F36E55733CA9PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 Gaurav,
 
Please see inline.=20
 
Cheers,
Med

De : Gaurav Halwasia (ghalwasi)= =20 [mailto:ghalwasi@cisco.com]
Envoy=E9 : dimanche 26 ao=FBt= 2012=20 16:48
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted=20 Lemon
Cc : dhcwg@ietf.org
Objet : RE: [dhcw= g]=20 RECONFIGURE Triggered by DHCPv6 Relay Agents=20 (draft-boucadair-dhc-triggered-reconfigure)

Specifying=20 the correct reference to RFC.

 

Hi Med,

 

I have few comments on this draft.

 

1.) I think just restricting this proposed capabi= lity to=20 RSOO is not a good idea. I can think of use cases in which relay agent mi= ght=20 want to trigger RECONFIGURE in non-RSOO scenarios as well. (Infact I am=20 working on a I.D which is work in progress which proposes similar capabil= ity=20 in DHCPv4). Probably you can refer RSOO as the use case for this draft in= stead=20 of restricting this for only RSOO scenario. This is also inline with the= =20 comments from Ted on the other email thread on not including  RSOO i= n the=20 RECONFIG-REQUEST message.  
[Med] In my=20 local copy, including RSOO is now optional: "an RA MAY include RSOO= =20 option". I also added a sentence to say this procedure can be applied in= =20 non-RSO scenarios. Would you be fine with these=20 changes? 

 

2.) I also agree comment from=
 Andre Kostur wherein Relay Agent MAY include OPTION_RECONF_MSG option in t=
he RECONFIGURE-REQUEST message to indicate what do you want the client to s=
end after receiving RECONFIGURE message. i.e Renew/Info-Request. Infact the=
re is a RFC which added capability to trigg=
er REBIND after receiving RECO=
NFIGURE message. (Rebind Capability in DHCPv6 Reconfigure Messages =96 RFC=
 6644). So it would certainly be useful to include OPTION_RECONF_MSG on th=
is message.

[Med] Agreed. I updated my local copy=20 accordingly.  

 <= /P>

Thanks,

Gaurav

 

 

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@iet= f.org]=20 On Behalf Of mohamed.boucadair@orange.com=
Sent:=20 Friday, August 24, 2012 8:10 PM
To: Ted Lemon
Cc: dhcwg@ietf.org
Subject: Re: = [dhcwg]=20 RECONFIGURE Triggered by DHCPv6 Relay Agents=20 (draft-boucadair-dhc-triggered-reconfigure)

 

Dear=20 Ted,

 

Thank = your=20 for the review.

 

Please= see=20 inline.

 

Cheers= ,

Med

 

De : Ted=20 Lemon [mailto:Ted.Lemon@nominu= m.com]=20
Envoy=E9 : vendredi 24 ao=FBt 2012 15:44
=C0 = ;:=20 BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : dhcwg@ietf.org
Objet : Re:=20 [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents=20 (draft-boucadair-dhc-triggered-reconfigure)

On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.c= om=20 wrote:

Co= mments=20 and suggestions are more than welcome. 

 

In section 2, you propose that the reconfigure-req= uest=20 include an RSOO, but this is actually not necessary; what will happen i= s=20 that the RECONFIGURE-REQUEST will trigger a RECONFIGURE, the client wil= l=20 then send a RENEW, the relay will piggyback an RSOO on the RENEW contai= ning,=20 e.g., the new AFTR_NAME option, and the DHCP server will send a REPLY=20 containing the AFTR_NAME option.   So there's no need to include t= hat=20 in the RECONFIGURE-REQUEST.   This is a minor point--it would cert= ainly=20 do no _harm_ to include the AFTR_NAME option in the RSOO on the=20 RECONFIGURE-REQUEST.

[Med= ] That's=20 make sense too. I changed "MUST" to "MAY" in Section 3.3: the= =20 point is to provide the dhcp server with more information to help = the=20 server whether a RECONFIGURE is needed. If for some reason, t= he=20 server detects the same information has been already supplied = ;to=20 the client, it may decide to not generate a RECONFIGURE message.=20   

 

So of course if you make this change, you'd have t= o fix=20 up section 3.2.

 

I would also change this, in section=20 3.2:

 

If the server is configured to =
reject RECONFIGURE-REQUEST, any received RECONFIGURE-REQUEST is silently dr=
opped.

 

To this:

 

If the server is configured to =
reject RECONFIGURE-REQUEST, the server MUST silently discard any RECONFIGUR=
E-REQUEST it receives.

 

It might be good to consistently say "silently dis= card"=20 instead of "discard" in that section.
[Med= ] I=20 updated my local copy.  

 

Section 3.3 also mentions sending the RSOO, and, i= f you=20 accept my argument above, should not.
[Med= ] Changed=20 "MUST" to "MAY" for the reason mentioned above in my local=20 copy.

 

In addition to the issues discussed in the Securit= y=20 Considerations section of RFC5007, you might also want to add this (pos= sibly=20 to section 3.2, not to the Security Considerations=20 section):

 

Because this message provides a mechanism for trig= gering=20 the DHCP Reconfigure message, and the DHCP Reconfigure message can be u= sed=20 by an attacker to control the timing of a DHCP renewal, the DHCP server= must=20 have some mechanism for determining that the relay agent is a trusted=20 entity.   RECONFIGURE-REQUEST messages originating from unknown re= lay=20 agents MUST be silently dropped.
[Med= ] I=20 updated Section 3.2 with the proposed text.=20 Thanks. 

 

Aside from this, the document looks good, and seem= s=20 useful.   Are you proposing that the working group should adopt th= is=20 work?
[Med= ] Yes. Thanks.=20   

 

--_000_94C682931C08B048B7A8645303FDC9F36E55733CA9PUEXCB1Bnante_-- From ghalwasi@cisco.com Sun Aug 26 22:40:56 2012 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 6155D21F84A7 for ; Sun, 26 Aug 2012 22:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.321 X-Spam-Level: X-Spam-Status: No, score=-10.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkg4VWTgE-kl for ; Sun, 26 Aug 2012 22:40:52 -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 7248621F84A1 for ; Sun, 26 Aug 2012 22:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=24282; q=dns/txt; s=iport; t=1346046052; x=1347255652; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NRqZIdyz3Sa+jbIK4QwC/pQHker+3Z8XSGf5NMiPT/g=; b=CuB4M3cmA1cC3L+yZCM19seAn2KtC1N1UaMPaa6XY5KDUXyn2UI1e+yg tJ/2XUGV3mUc+Vr9Y4JqtDKE59t6lCIhkk6UzPZ3T/9Olf/SaJ09b+Mym /SIx1B471At/kWAOZq7c4ae7QMcadIGGY7VPaB8s3WoRNRJg1U31gQDhj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABkHO1CtJXG9/2dsb2JhbABFgkq4JoEHgiABAQEEEgEaTBACAQgRBAEBCxYDBAcyFAkIAgQBDQUIGodrmnSfRosIhjFgA4gam2mBZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,318,1344211200"; d="scan'208,217";a="115482554" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 27 Aug 2012 05:40:51 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7R5epip011197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Aug 2012 05:40:51 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.246]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Mon, 27 Aug 2012 00:40:50 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "mohamed.boucadair@orange.com" , Ted Lemon Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGAABLMSoAADm1sMABI9adwAACgFqAAHzWKkAAADVLg Date: Mon, 27 Aug 2012 05:40:50 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB0E9A18@xmb-aln-x06.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> <264AF650-EB56-4C12-9A1D-F1A92FEACB39@nominum.com> <94C682931C08B048B7A8645303FDC9F36E5332AACB@PUEXCB1B.nanterre.francetelecom.fr> <90903C21C73202418A48BFBE80AEE5EB0E836A@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB0E8385@xmb-aln-x06.cisco.com> <94C682931C08B048B7A8645303FDC9F36E55733CA9@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E55733CA9@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.106.111] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.004 x-tm-as-result: No--49.634400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB0E9A18xmbalnx06ciscocom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 27 Aug 2012 05:40:56 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB0E9A18xmbalnx06ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, Thanks for taking care of my suggestions and comments. I am fine with these= changes. Thanks, Gaurav From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, August 27, 2012 11:08 AM To: Gaurav Halwasia (ghalwasi); Ted Lemon Cc: dhcwg@ietf.org Subject: RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bo= ucadair-dhc-triggered-reconfigure) Dear Gaurav, Please see inline. Cheers, Med ________________________________ De : Gaurav Halwasia (ghalwasi) [mailto:ghalwasi@cisco.com] Envoy=E9 : dimanche 26 ao=FBt 2012 16:48 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon Cc : dhcwg@ietf.org Objet : RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bou= cadair-dhc-triggered-reconfigure) Specifying the correct reference to RFC. Hi Med, I have few comments on this draft. 1.) I think just restricting this proposed capability to RSOO is not a good= idea. I can think of use cases in which relay agent might want to trigger = RECONFIGURE in non-RSOO scenarios as well. (Infact I am working on a I.D wh= ich is work in progress which proposes similar capability in DHCPv4). Proba= bly you can refer RSOO as the use case for this draft instead of restrictin= g this for only RSOO scenario. This is also inline with the comments from T= ed on the other email thread on not including RSOO in the RECONFIG-REQUEST= message. [Med] In my local copy, including RSOO is now optional: "an RA MAY include = RSOO option". I also added a sentence to say this procedure can be applied = in non-RSO scenarios. Would you be fine with these changes? 2.) I also agree comment from Andre Kostur wherein Relay Agent MAY include = OPTION_RECONF_MSG option in the RECONFIGURE-REQUEST message to indicate wha= t do you want the client to send after receiving RECONFIGURE message. i.e R= enew/Info-Request. Infact there is a RFC which added capability to trigger = REBIND after receiving RECONFIGURE message. (Rebind Capability in DHCPv6 Re= configure Messages - RFC 6644). So it would certainly be useful to include = OPTION_RECONF_MSG on this message. [Med]Agreed. I updated my local copy accordingly. Thanks, Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of moham= ed.boucadair@orange.com Sent: Friday, August 24, 2012 8:10 PM To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bo= ucadair-dhc-triggered-reconfigure) Dear Ted, Thank your for the review. Please see inline. Cheers, Med ________________________________ De : Ted Lemon [mailto:Ted.Lemon@nominum.com] Envoy=E9 : vendredi 24 ao=FBt 2012 15:44 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : dhcwg@ietf.org Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bou= cadair-dhc-triggered-reconfigure) On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com wrote: Comments and suggestions are more than welcome. In section 2, you propose that the reconfigure-request include an RSOO, but= this is actually not necessary; what will happen is that the RECONFIGURE-R= EQUEST will trigger a RECONFIGURE, the client will then send a RENEW, the r= elay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAM= E option, and the DHCP server will send a REPLY containing the AFTR_NAME op= tion. So there's no need to include that in the RECONFIGURE-REQUEST. Th= is is a minor point--it would certainly do no _harm_ to include the AFTR_NA= ME option in the RSOO on the RECONFIGURE-REQUEST. [Med] That's make sense too. I changed "MUST" to "MAY" in Section 3.3: the = point is to provide the dhcp server with more information to help the serve= r whether a RECONFIGURE is needed. If for some reason, the server detects t= he same information has been already supplied to the client, it may decide = to not generate a RECONFIGURE message. So of course if you make this change, you'd have to fix up section 3.2. I would also change this, in section 3.2: If the server is configured to reject RECONFIGURE-REQUEST, any received REC= ONFIGURE-REQUEST is silently dropped. To this: If the server is configured to reject RECONFIGURE-REQUEST, the server MUST = silently discard any RECONFIGURE-REQUEST it receives. It might be good to consistently say "silently discard" instead of "discard= " in that section. [Med] I updated my local copy. Section 3.3 also mentions sending the RSOO, and, if you accept my argument = above, should not. [Med] Changed "MUST" to "MAY" for the reason mentioned above in my local co= py. In addition to the issues discussed in the Security Considerations section = of RFC5007, you might also want to add this (possibly to section 3.2, not t= o the Security Considerations section): Because this message provides a mechanism for triggering the DHCP Reconfigu= re message, and the DHCP Reconfigure message can be used by an attacker to = control the timing of a DHCP renewal, the DHCP server must have some mechan= ism for determining that the relay agent is a trusted entity. RECONFIGURE= -REQUEST messages originating from unknown relay agents MUST be silently dr= opped. [Med] I updated Section 3.2 with the proposed text. Thanks. Aside from this, the document looks good, and seems useful. Are you propo= sing that the working group should adopt this work? [Med] Yes. Thanks. --_000_90903C21C73202418A48BFBE80AEE5EB0E9A18xmbalnx06ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

Thanks for taking care of my suggestions and co= mments. I am fine with these changes.

 

Thanks,

Gaurav

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, August 27, 2012 11:08 AM
To: Gaurav Halwasia (ghalwasi); Ted Lemon
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (d= raft-boucadair-dhc-triggered-reconfigure)

 

Dear Gaurav,
 
Please see inline.
 
Cheers,
Med

 

De : Gaurav Halwasia (ghalwas= i) [mailto:ghalwasi@cisco.com]<= /a>
Envoy=E9 : dimanche 26 ao=FBt 2012 16:48
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon
Cc : dhcwg@ietf.org
Objet : RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agent= s (draft-boucadair-dhc-triggered-reconfigure)=

Specifying the correct re= ference to RFC.

 

Hi Med,

 

I have few comments on this draft.

 

1.) I think just restricting this proposed capabi= lity to RSOO is not a good idea. I can think of use cases in which relay ag= ent might want to trigger RECONFIGURE in non-RSOO scenarios as well. (Infac= t I am working on a I.D which is work in progress which proposes similar capability in DHCPv4). Probably you can= refer RSOO as the use case for this draft instead of restricting this for = only RSOO scenario. This is also inline with the comments from Ted on the o= ther email thread on not including  RSOO in the RECONFIG-REQUEST message.  
[Med] In my local copy, including RSOO is now optional: &quo= t;an RA MAY include RSOO option". I also added a sentence to say this = procedure can be applied in non-RSO scenarios. Would you be fine with these changes? 

 

2.) I also agree comment from Andre Kostur wherein Relay =
Agent MAY include OPTION_RECONF_MSG option in the RECONFIGURE-REQUEST messa=
ge to indicate what do you want the client to send after receiving RECONFIG=
URE message. i.e Renew/Info-Request. Infact there is a RFC which added capability to trigger REBIND after receiving RECONFIGURE message. (Rebind Capabil=
ity in DHCPv6 Reconfigure Messages – RFC 6644). So it would certainly=
 be useful to include OPTION_RECONF_MSG on this message.<=
/pre>

[Med]Agreed. I updated my local copy accordingl=
y.  


 <=
/p>

Thanks,=



Gaurav<=
/p>

 <=
/p>

 <=
/p>





From:
dhcwg-bounces@ietf.org 
[mailto:dhcwg-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com

Sent: Friday, August 24, 2012 8:10 PM

To: Ted Lemon

Cc: dhcwg@ietf.org

Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (d=
raft-boucadair-dhc-triggered-reconfigure)






 


Dear Ted,


 


Thank your for the review.



 


Please see inline.


 


Cheers,


Med




 








De : Ted Lemon
[mailto:Ted.Lemon@nominum=
.com]


Envoy=E9 : vendredi 24 ao=FBt 2012 15:44

=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP

Cc : dhcwg@ietf.org

Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agent=
s (draft-boucadair-dhc-triggered-reconfigure)=







On Aug 24, 2012, at 7:49 AM, 
mohamed.boucadair@orange.com wrote:






Comments and suggestions are more tha=
n welcome. 






 




In section 2, you propose that the reconfigure-reque=
st include an RSOO, but this is actually not necessary; what will happen is=
 that the RECONFIGURE-REQUEST will trigger a RECONFIGURE, the client will t=
hen send a RENEW, the relay will piggyback
 an RSOO on the RENEW containing, e.g., the new AFTR_NAME option, and the D=
HCP server will send a REPLY containing the AFTR_NAME option.   So the=
re's no need to include that in the RECONFIGURE-REQUEST.   This is a m=
inor point--it would certainly do no _harm_
 to include the AFTR_NAME option in the RSOO on the RECONFIGURE-REQUEST.






[Med] That's make sense too. I change=
d "MUST" to "MAY" in Section 3.3: the point is to =
provide the dhcp server with more information to help the server wheth=
er a RECONFIGURE
 is needed. If for some reason, the server detects the same =
information has been already supplied to the client, it may decide to =
not generate a RECONFIGURE message.   






 






So of course if you make this change, you'd have to =
fix up section 3.2.






 






I would also change this, in section 3.2:=







 






If the server is configured to reject REC=
ONFIGURE-REQUEST, any received RECONFIGURE-REQUEST is silently dropped.




 








To this:






 






If the server is configured to reject REC=
ONFIGURE-REQUEST, the server MUST silently discard any RECONFIGURE-REQUEST =
it receives.




 








It might be good to consistently say "silently =
discard" instead of "discard" in that section.

[Med] I updated my local copy.  






 






Section 3.3 also mentions sending the RSOO, and, if =
you accept my argument above, should not.

[Med] Changed "MUST" to "MAY" for the reason =
mentioned above in my local copy.






 






In addition to the issues discussed in the Security =
Considerations section of RFC5007, you might also want to add this (possibl=
y to section 3.2, not to the Security Considerations section):





 






Because this message provides a mechanism for trigge=
ring the DHCP Reconfigure message, and the DHCP Reconfigure message can be =
used by an attacker to control the timing of a DHCP renewal, the DHCP serve=
r must have some mechanism for determining
 that the relay agent is a trusted entity.   RECONFIGURE-REQUEST messa=
ges originating from unknown relay agents MUST be silently dropped.

[Med] I updated Section 3.2 with the proposed text. Thanks.&=
nbsp;






 






Aside from this, the document looks good, and seems =
useful.   Are you proposing that the working group should adopt this w=
ork?

[Med] Yes. Thanks.   






 
--_000_90903C21C73202418A48BFBE80AEE5EB0E9A18xmbalnx06ciscocom_-- From mohamed.boucadair@orange.com Mon Aug 27 01:29:36 2012 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 F226021F847F for ; Mon, 27 Aug 2012 01:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3l+3r5QwiIZ for ; Mon, 27 Aug 2012 01:29:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB421F84BF for ; Mon, 27 Aug 2012 01:29:34 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F121F3B453B; Mon, 27 Aug 2012 10:29:32 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D125627C064; Mon, 27 Aug 2012 10:29:32 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 27 Aug 2012 10:29:09 +0200 From: To: "Gaurav Halwasia (ghalwasi)" , Ted Lemon Date: Mon, 27 Aug 2012 10:29:08 +0200 Thread-Topic: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) Thread-Index: Ac2B6QUqwYS2/P4sSIahdPn5lTXDIwABPhGAABLMSoAADm1sMABI9adwAACgFqAAHzWKkAAADVLgAAXmjqA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E55733D64@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5332AA39@PUEXCB1B.nanterre.francetelecom.fr> <264AF650-EB56-4C12-9A1D-F1A92FEACB39@nominum.com> <94C682931C08B048B7A8645303FDC9F36E5332AACB@PUEXCB1B.nanterre.francetelecom.fr> <90903C21C73202418A48BFBE80AEE5EB0E836A@xmb-aln-x06.cisco.com> <90903C21C73202418A48BFBE80AEE5EB0E8385@xmb-aln-x06.cisco.com> <94C682931C08B048B7A8645303FDC9F36E55733CA9@PUEXCB1B.nanterre.francetelecom.fr> <90903C21C73202418A48BFBE80AEE5EB0E9A18@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB0E9A18@xmb-aln-x06.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E55733D64PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.27.72415 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-boucadair-dhc-triggered-reconfigure) 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, 27 Aug 2012 08:29:36 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E55733D64PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Ok, thanks. FYI, I submitted an updated version integrating the comments received so fa= r. This version is available at: http://tools.ietf.org/html/draft-boucadair= -dhc-triggered-reconfigure-01. Cheers, Med ________________________________ De : Gaurav Halwasia (ghalwasi) [mailto:ghalwasi@cisco.com] Envoy=E9 : lundi 27 ao=FBt 2012 07:41 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon Cc : dhcwg@ietf.org Objet : RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bou= cadair-dhc-triggered-reconfigure) Hi Med, Thanks for taking care of my suggestions and comments. I am fine with these= changes. Thanks, Gaurav From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, August 27, 2012 11:08 AM To: Gaurav Halwasia (ghalwasi); Ted Lemon Cc: dhcwg@ietf.org Subject: RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bo= ucadair-dhc-triggered-reconfigure) Dear Gaurav, Please see inline. Cheers, Med ________________________________ De : Gaurav Halwasia (ghalwasi) [mailto:ghalwasi@cisco.com] Envoy=E9 : dimanche 26 ao=FBt 2012 16:48 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon Cc : dhcwg@ietf.org Objet : RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bou= cadair-dhc-triggered-reconfigure) Specifying the correct reference to RFC. Hi Med, I have few comments on this draft. 1.) I think just restricting this proposed capability to RSOO is not a good= idea. I can think of use cases in which relay agent might want to trigger = RECONFIGURE in non-RSOO scenarios as well. (Infact I am working on a I.D wh= ich is work in progress which proposes similar capability in DHCPv4). Proba= bly you can refer RSOO as the use case for this draft instead of restrictin= g this for only RSOO scenario. This is also inline with the comments from T= ed on the other email thread on not including RSOO in the RECONFIG-REQUEST= message. [Med] In my local copy, including RSOO is now optional: "an RA MAY include = RSOO option". I also added a sentence to say this procedure can be applied = in non-RSO scenarios. Would you be fine with these changes? 2.) I also agree comment from Andre Kostur wherein Relay Agent MAY include = OPTION_RECONF_MSG option in the RECONFIGURE-REQUEST message to indicate wha= t do you want the client to send after receiving RECONFIGURE message. i.e R= enew/Info-Request. Infact there is a RFC which added capability to trigger = REBIND after receiving RECONFIGURE message. (Rebind Capability in DHCPv6 Re= configure Messages - RFC 6644). So it would certainly be useful to include = OPTION_RECONF_MSG on this message. [Med]Agreed. I updated my local copy accordingly. Thanks, Gaurav From: dhcwg-bounces@ietf.org [mailto:dhcwg-b= ounces@ietf.org] On Behalf Of moham= ed.boucadair@orange.com Sent: Friday, August 24, 2012 8:10 PM To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bo= ucadair-dhc-triggered-reconfigure) Dear Ted, Thank your for the review. Please see inline. Cheers, Med ________________________________ De : Ted Lemon [mailto:Ted.Lemon@nominum.com] Envoy=E9 : vendredi 24 ao=FBt 2012 15:44 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : dhcwg@ietf.org Objet : Re: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents (draft-bou= cadair-dhc-triggered-reconfigure) On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange.com wrote: Comments and suggestions are more than welcome. In section 2, you propose that the reconfigure-request include an RSOO, but= this is actually not necessary; what will happen is that the RECONFIGURE-R= EQUEST will trigger a RECONFIGURE, the client will then send a RENEW, the r= elay will piggyback an RSOO on the RENEW containing, e.g., the new AFTR_NAM= E option, and the DHCP server will send a REPLY containing the AFTR_NAME op= tion. So there's no need to include that in the RECONFIGURE-REQUEST. Th= is is a minor point--it would certainly do no _harm_ to include the AFTR_NA= ME option in the RSOO on the RECONFIGURE-REQUEST. [Med] That's make sense too. I changed "MUST" to "MAY" in Section 3.3: the = point is to provide the dhcp server with more information to help the serve= r whether a RECONFIGURE is needed. If for some reason, the server detects t= he same information has been already supplied to the client, it may decide = to not generate a RECONFIGURE message. So of course if you make this change, you'd have to fix up section 3.2. I would also change this, in section 3.2: If the server is configured to reject RECONFIGURE-REQUEST, any received REC= ONFIGURE-REQUEST is silently dropped. To this: If the server is configured to reject RECONFIGURE-REQUEST, the server MUST = silently discard any RECONFIGURE-REQUEST it receives. It might be good to consistently say "silently discard" instead of "discard= " in that section. [Med] I updated my local copy. Section 3.3 also mentions sending the RSOO, and, if you accept my argument = above, should not. [Med] Changed "MUST" to "MAY" for the reason mentioned above in my local co= py. In addition to the issues discussed in the Security Considerations section = of RFC5007, you might also want to add this (possibly to section 3.2, not t= o the Security Considerations section): Because this message provides a mechanism for triggering the DHCP Reconfigu= re message, and the DHCP Reconfigure message can be used by an attacker to = control the timing of a DHCP renewal, the DHCP server must have some mechan= ism for determining that the relay agent is a trusted entity. RECONFIGURE= -REQUEST messages originating from unknown relay agents MUST be silently dr= opped. [Med] I updated Section 3.2 with the proposed text. Thanks. Aside from this, the document looks good, and seems useful. Are you propo= sing that the working group should adopt this work? [Med] Yes. Thanks. --_000_94C682931C08B048B7A8645303FDC9F36E55733D64PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Re-,
 
Ok, thanks.
 
FYI, I submitted an updated version integrati= ng the=20 comments received so far. This version is available at: http://tools.ietf.org/html/draft-boucadair-dhc-triggered-reconfigure-= 01.
 
Cheers,
Med

De : Gaurav Halwasia (ghalwasi)= =20 [mailto:ghalwasi@cisco.com]
Envoy=E9 : lundi 27 ao=FBt 20= 12=20 07:41
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted=20 Lemon
Cc : dhcwg@ietf.org
Objet : RE: [dhcw= g]=20 RECONFIGURE Triggered by DHCPv6 Relay Agents=20 (draft-boucadair-dhc-triggered-reconfigure)

Hi=20 Med,

&= nbsp;

Thanks= for=20 taking care of my suggestions and comments. I am fine with these=20 changes.

&= nbsp;

Thanks= ,

Gaurav=

From:=20 mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20
Sent: Monday, August 27, 2012 11:08 AM
To: Gaurav=20 Halwasia (ghalwasi); Ted Lemon
Cc: dhcwg@ietf.org
Subject= :=20 RE: [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents=20 (draft-boucadair-dhc-triggered-reconfigure)

 

Dear=20 Gaurav,
 
Please see inline.=20
 
Cheers,
Med

 

De : Gaurav=20 Halwasia (ghalwasi) [mailto:ghalwasi@cisco.com]= =20
Envoy=E9 : dimanche 26 ao=FBt 2012 16:48
=C0 = ;:=20 BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon
Cc : dhcwg@ietf.org
Objet : RE:=20 [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents=20 (draft-boucadair-dhc-triggered-reconfigure)

Specifying=20 the correct reference to RFC.

 

Hi Med,

 

I have few comments on this draft.

 

1.) I think just restricting this proposed capa= bility=20 to RSOO is not a good idea. I can think of use cases in which relay age= nt=20 might want to trigger RECONFIGURE in non-RSOO scenarios as well. (Infac= t I=20 am working on a I.D which is work in progress which proposes similar=20 capability in DHCPv4). Probably you can refer RSOO as the use case for = this=20 draft instead of restricting this for only RSOO scenario. This is also= =20 inline with the comments from Ted on the other email thread on not incl= uding=20  RSOO in the RECONFIG-REQUEST message.  
[Med= ] In=20 my local copy, including RSOO is now optional: "an RA MAY include = RSOO=20 option". I also added a sentence to say this procedure can be applied i= n=20 non-RSO scenarios. Would you be fine with these=20 changes? 

 

2.) I also agree comment fr=
om Andre Kostur wherein Relay Agent MAY include OPTION_RECONF_MSG option in=
 the RECONFIGURE-REQUEST message to indicate what do you want the client to=
 send after receiving RECONFIGURE message. i.e Renew/Info-Request. Infact t=
here is a RFC which added capability to tri=
gger REBIND after receiving RE=
CONFIGURE message. (Rebind Capability in DHCPv6 Reconfigure Messages =96 RF=
C 6644). So it would certainly be useful to include OPTION_RECONF_MSG on th=
is message.

[Med= ]Agreed.=20 I updated my local copy accordingly.  

 

Thanks,

Gaurav

 

 

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@i= etf.org]=20 On Behalf Of mohamed.boucadair@orange.c= om
Sent:=20 Friday, August 24, 2012 8:10 PM
To: Ted Lemon
Cc: <= A=20 href=3D"mailto:dhcwg@ietf.org">dhcwg@ietf.org
Subject: Re= :=20 [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents=20 (draft-boucadair-dhc-triggered-reconfigure)

=

 

Dear= =20 Ted,

 

Than= k your=20 for the review.

 

Plea= se see=20 inline.

 

Chee= rs,

Med<= /SPAN>

 

De : Ted=20 Lemon [mailto:Ted.Lemon@nomi= num.com]=20
Envoy=E9 : vendredi 24 ao=FBt 2012 15:44
=C0&nb= sp;:=20 BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : dhcwg@ietf.org
Objet :<= /B> Re:=20 [dhcwg] RECONFIGURE Triggered by DHCPv6 Relay Agents=20 (draft-boucadair-dhc-triggered-reconfigure)

On Aug 24, 2012, at 7:49 AM, mohamed.boucadair@orange= .com=20 wrote:

= Comments=20 and suggestions are more than welcome. 

 

In section 2, you propose that the reconfigure-r= equest=20 include an RSOO, but this is actually not necessary; what will happen= is=20 that the RECONFIGURE-REQUEST will trigger a RECONFIGURE, the client w= ill=20 then send a RENEW, the relay will piggyback an RSOO on the RENEW=20 containing, e.g., the new AFTR_NAME option, and the DHCP server will = send=20 a REPLY containing the AFTR_NAME option.   So there's no need to= =20 include that in the RECONFIGURE-REQUEST.   This is a minor point= --it=20 would certainly do no _harm_ to include the AFTR_NAME option in the R= SOO=20 on the RECONFIGURE-REQUEST.

[M= ed] That's=20 make sense too. I changed "MUST" to "MAY" in Section 3.3: t= he=20 point is to provide the dhcp server with more information to hel= p the=20 server whether a RECONFIGURE is needed. If for some reason,= the=20 server detects the same information has been already supplied&nb= sp;to=20 the client, it may decide to not generate a RECONFIGURE message.=20   

 

So of course if you make this change, you'd have= to fix=20 up section 3.2.

 

I would also change this, in section=20 3.2:

 

If the server is configured t=
o reject RECONFIGURE-REQUEST, any received RECONFIGURE-REQUEST is silently =
dropped.

 

To this:

 

If the server is configured t=
o reject RECONFIGURE-REQUEST, the server MUST silently discard any RECONFIG=
URE-REQUEST it receives.

 

It might be good to consistently say "silently d= iscard"=20 instead of "discard" in that section.
[M= ed] I=20 updated my local copy.  

 

Section 3.3 also mentions sending the RSOO, and,= if you=20 accept my argument above, should not.
[M= ed] Changed=20 "MUST" to "MAY" for the reason mentioned above in my local=20 copy.

 

In addition to the issues discussed in the Secur= ity=20 Considerations section of RFC5007, you might also want to add this=20 (possibly to section 3.2, not to the Security Considerations=20 section):

 

Because this message provides a mechanism for=20 triggering the DHCP Reconfigure message, and the DHCP Reconfigure mes= sage=20 can be used by an attacker to control the timing of a DHCP renewal, t= he=20 DHCP server must have some mechanism for determining that the relay a= gent=20 is a trusted entity.   RECONFIGURE-REQUEST messages originating = from=20 unknown relay agents MUST be silently dropped.
[M= ed] I=20 updated Section 3.2 with the proposed text.=20 Thanks. 

 

Aside from this, the document looks good, and se= ems=20 useful.   Are you proposing that the working group should adopt = this=20 work?
[M= ed] Yes. Thanks.=20   

 

--_000_94C682931C08B048B7A8645303FDC9F36E55733D64PUEXCB1Bnante_-- From leaf.y.yeh@huawei.com Mon Aug 27 01:55:05 2012 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 364A321F85A5 for ; Mon, 27 Aug 2012 01:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLq6QuiJEbDt for ; Mon, 27 Aug 2012 01:55:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1C321F855D for ; Mon, 27 Aug 2012 01:55:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id APJ00695; Mon, 27 Aug 2012 00:55:04 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Aug 2012 01:51:56 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Aug 2012 01:51:55 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Mon, 27 Aug 2012 16:51:52 +0800 From: Leaf yeh To: dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt Thread-Index: AQHNdvWqSDMOAnuzpUmlatl1eCUEGJdX0gXAgBWNlcA= Date: Mon, 27 Aug 2012 08:51:52 +0000 Message-ID: References: <4D779082-B182-4728-9534-39456573682E@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4EA3B4@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.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-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: Mon, 27 Aug 2012 08:55:05 -0000 +1 Bernie - Also, while relaying the packet seems like a fine idea, it might b= e useful to indicate what the relay should use for a peer-address in the Re= lay-Forw message. It is all 0's? (Normally the client's link local address = would be stored there.) If the unspecified IPv6 address (::) is used also as the 'peer-address' in = the Relay-Reply message, then it will be regarded that this message targets= to the relay itself, and no need to forward to other one, right? One more question for the 'link-address' of the Relay-Forward message: it i= s also the unspecified IPv6 address, right? Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Monday, August 13, 2012 10:36 PM To: Ted Lemon; dhc WG Cc: ot@cisco.com Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt I am OK with advancing this. A few nits: - In section 1: The source tunnel end-point often need more configuration data for I think need should be needs here. - In section 3, "CE" and "BR" are not defined and should be the first time = used (or perhaps a terminology section is appropriate). Also, while relaying the packet seems like a fine idea, it might be useful = to indicate what the relay should use for a peer-address in the Relay-Forw = message. It is all 0's? (Normally the client's link local address would be = stored there.) - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, August 10, 2012 8:43 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt The authors of this draft have requested a working group last call. The d= raft explains how DHCP clients operate in an environment where the interfac= e being configured doesn't support multicast (e.g., 6RD). If this is a ma= tter of interest to you, please review the draft and send comments to the l= ist. If you are in favor of advancing the draft, please say so on the list; if n= obody supports it, it won't advance. If you oppose advancing it, please a= lso say so. We will determine consensus on August 24. _______________________________________________ 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 From leaf.y.yeh@huawei.com Tue Aug 28 06:22:42 2012 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 5240621F8497 for ; Tue, 28 Aug 2012 06:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN0KFGyu4OhQ for ; Tue, 28 Aug 2012 06:22:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 56D6321F8466 for ; Tue, 28 Aug 2012 06:22:39 -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.5-GA FastPath queued) with ESMTP id AJC22855; Tue, 28 Aug 2012 13:22:38 +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.1.323.3; Tue, 28 Aug 2012 14:21:57 +0100 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 28 Aug 2012 21:22:09 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Tue, 28 Aug 2012 21:22:04 +0800 From: Leaf yeh To: Tomek Mrugalski Thread-Topic: Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Thread-Index: AQHNgiXnOAnjjw7Zjk+PytbTkNCew5duyIKQ Date: Tue, 28 Aug 2012 13:22:03 +0000 Message-ID: References: <5037C726.2070406@gmail.com> In-Reply-To: <5037C726.2070406@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dhcwg Subject: Re: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 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, 28 Aug 2012 13:22:42 -0000 SGkgVG9tZWssDQoNCllvdXIgY29tbWVudCBsb29rcyBhbHdheXMgdGhvcm91Z2guIEkgd2lsbCBm aW5kIG1vcmUgdGltZSB0byByZXZpZXcgYWxsIHRoZSBiZWxvdyBjb21tZW50cyBmb3IgdGhlIHVw ZGF0ZSBvZiBkcmFmdCAoT1BUSU9OX1BSRUZJWF9QT09MKSB0byB2ZXIuLTA5Lg0KDQpUaGUgZm9s bG93aW5nIGFyZSBteSBmZWVkYmFjayB0byBzb21lIG9mIHlvdXIgY29tbWVudHMgb24gdGhlIHRl eHQgb2YgdGhlIGRyYWZ0Og0KDQpUb21layAtIE11bHRpcGxlIHByZWZpeCBwb29scyBzZWVtIHRv IGJlIGFsbG93ZWQgKHNlY3Rpb24gNiwgcGFyYWdyYXBoIDcNCiAgc3VnZ2VzdHMgdGhhdCkuIEl0 IG1heSBiZSB1c2VmdWwgdG8gbm90ZSB0aGF0IG11bHRpcGxlIHByZWZpeCBwb29scw0KICBtdXN0 IG5vdCBvdmVybGFwLg0KDQoxLiBBY2NlcHRlZC4gVGhlIHJlcGxhY2VkIHRleHQgaW4gU2VjdGlv biA2IHdpbGwgYmUgIk5vdGUgdGhhdCB0aGVzZSBwcmVmaXggcG9vbHMgZG9lcyBub3Qgb3Zlcmxh eSwgdGhlIGRlbGVnYXRlZCBwcmVmaXggaXMgb25seSBmcm9tIG9uZSBwcmVmaXggcG9vbC4iDQoN Cg0KVG9tZWsgLSBUaGVyZSBhcmUgbWFueSBub3JtYXRpdmUgbG9va2luZyB3b3JkcyAobXVzdCwg c2hhbGwgZXRjLikgdGhhdCBhcmUNCiAgbm90IGNhcGl0YWxpemVkLg0KDQoyLiBBY2NlcHRlZC4g SW4gZmFjdCwgSSB3aWxsIGNhcGl0YWxpemUgYWxsIG9mIHRoZSAnbXVzdCwgc2hvdWxkIGFuZCBt YXknIGluIHRoZSBkcmFmdC4NCg0KDQpUb21layAtIEluIGl0cyBjdXJyZW50IGZvcm0gaXQgYWxs b3dzDQogIHNlcnZlciB0byBtYWtlIHN0cmFuZ2UgdGhpbmdzIGxpa2UgbWFrZSB0aGUgcG9vbCBh Y3RpdmUgd2hlbg0KICByZXNwb25kaW5nIHRvIFJFTEVBU0Ugb3Igc2F5aW5nIHRoYXQgdGhlIHBv b2wgaXMgcmVsZWFzZWQgd2hlbg0KICBhc3NpZ25pbmcgYSBwcmVmaXggaW4gcmVzcG9uc2UgdG8g UkVRVUVTVC4NCg0KWWVzLCB3aGVuIHRoZSBhZG1pbmlzdHJhdG9yIG9mIHRoZSBzZXJ2ZXIgdHVy biBvbiB0aGUgc2V0dGluZyB0byBzdXBwb3J0IHJvdXRlIGFnZ3JlZ2F0aW9uIG9uIHRoZSByZWxh eSwgdGhlIHNlcnZlciBtYXkgYWRkIHRoZSBhZ2dyZWdhdGlvbiByb3V0ZSB0aHJvdWdoIHRoZSBP UFRJT05fUFJFRklYX1BPT0wgaW4gdGhlIFJFTEFZLVJFUEwgbWVzc2FnZSBvZiB0aGUgUkVQTFkg dG8gdGhlIFJFTEVBU0Ugd2hlbiB0aGUgcmVsZWFzZWQgUEQgcHJlZml4IGlzIG5vdCB0aGUgbGFz dCBQRCBwcmVmaXggaW4gdGhlIHBvb2w7IHdoZW4gdGhlIGFkbWluaXN0cmF0b3Igb2YgdGhlIHNl cnZlciB0dXJuIG9mZiB0aGUgc2V0dGluZyB0byBzdXBwb3J0IHJvdXRlIGFnZ3JlZ2F0aW9uIG9u IHRoZSByZWxheSwgdGhlIHNlcnZlciBtYXkgd2l0aGRyYXcgdGhlIGFnZ3JlZ2F0aW9uIHJvdXRl IGluIHJlc3BvbnNlIHRvIFJFUVVFU1Qgb2YgUEQuIA0KDQoNClRvbWVrIC0gVGhhdCBkcmFmdCB3 YXMgd3JpdHRlbiBpbiBCQkYgbmV0d29ya3MgaW4gbWluZCwgYnV0IGl0IGNhbiBiZSB1c2VkDQog IGluIGEgZ2VuZXJhbCBjYXNlIGFzIHdlbGwuIEEgc3RhdGVtZW50IHRvIHBvaW50IHRoYXQgb3V0 IHNob3VsZCBiZQ0KICBhZGRlZC4NCg0KSSBiZWxpZXZlIHRoZSBkcmFmdCAoT1BUSU9OX1BSRUZJ WF9QT09MKSBoYXMgYWxyZWFkeSB1c2VkIHRoZSBsYW5ndWFnZSBvZiBJRVRGLCBqdXN0IHJlZmVy cmVkIHRvIEJCRiBUUi0xNzcgaW4gdGhlIGludHJvZHVjdGlvbiwgaXQgbWF5IGVtcGhhc2l6ZSB0 aGUgY2FzZSB3aGVuIHRoZSBQRSByb3V0ZXIgYWN0cyBhcyBESENQdjYgcmVsYXkuDQoNCg0KVG9t ZWsgLSBTZWN0aW9uIDE6IFRoaXMgaXMgcmVhbGx5IGEgbml0LXBpY2sgc3R5bGUgY29tbWVudCAg IlRoZSBESENQdjYNCiAgcHJvdG9jb2wiLiBJIGFsd2F5cyBoYXZlIHByb2JsZW0gaG93IHRvIHdy aXRlIGl0LiBBZGRpbmcgcHJvdG9jb2wNCiAgYWZ0ZXIgREhDUCBpcyByZWR1bmRhbnQsIGFzIFAg aW4gREhDUCBzdGFuZHMgZm9yIHByb3RvY29sLiBPbiB0aGUNCiAgb3RoZXIgaGFuZCwgcmVtb3Zp bmcgInByb3RvY29sIiB3b3VsZCBtYWtlIGl0IGxlc3MgcmVhZGFibGUgYnkgcGVvcGxlDQogIHdo byBkb24ndCBrbm93IHdoYXQgREhDUCBhY3JvbnltIHN0YW5kcyBmb3IuIEkgdGhpbmsgaXQgcHJv YmFibHkNCiAgc2hvdWxkIHN0YXkgYXMgaXQgaXMuDQoNCkl0IGNvdWxkIGJlIGVpdGhlciBhcyB5 b3Ugd2FudC4NCg0KDQpUb21layAtIFNlY3Rpb24gMSwgc2Vjb25kIHBhcmFncmFwaC4gWW91IG1l bnRpb25kIFJScyB3aXRob3V0IGRlZmluaW5nIHRoYXQNCiAgYWNyb255bS4gQWx0aG91Z2ggaXQg aXMgbGF0ZXIgZXhwbGFpbmVkIGluIHNlY3Rpb24gMiwgaXQgd291bGQgYmUgZ29vZA0KICB0byBy ZXBsYWNlIGl0cyBmaXJzdCB1c2Ugd2l0aCAiUmVxdWVzdGluZyBSb3V0ZXIgKFJSKSIuDQoNClRo ZSAxc3QgcGFyYWdyYXBoIGhhcyB0aGUgdGV4dCBvZiAnLi4uIHRoZSBSZXF1ZXN0aW5nIFJvdXRl cnMgKFJSKSBhY3RpbmcgYXMgdGhlIERIQ1B2NiBDbGllbnRzJy4NCg0KDQpUb21layAtIFNlY3Rp b24gMS4gRmlyc3QgcGFyYWdyYXBoIG9uIHBhZ2UgNC4gIkJ1bGsgTGVhc2VxdWVyeSBbUkZDNTQ2 MF0NCiAgc3BlY2lmaWVzIGEgbWVjaGFuaXNtIGZvciBidWxrIHRyYW5zZmVyIG9mIHRoZSBiaW5k aW5nIGRhdGEgb2YgZWFjaA0KICBkZWxlZ2F0ZWQgcHJlZml4IGZyb20gdGhlIHNlcnZlciB0byB0 aGUgcmVxdWVzdG9yIChpLmUuLCBhIERIQ1B2Ng0KICByZWxheSBhZ2VudCkiLiBXaGlsZSByZXF1 ZXN0b3IgaXMgdHlwaWNhbGx5IHRoZSByZWxheSBhZ2VudCwgaXQNCiAgZG9lc24ndCBoYXZlIHRv IGJlLiBJdCBtYXkgYmUgYSBzZXBhcmF0ZSBlbnRpdHkgYXMgd2VsbC4gSSB3b3VsZA0KICByZXBs YWNlICJpLmUuIiB3aXRoICJ0eXBpY2FsbHkiLg0KDQozLiBBY2NlcHRlZC4gVGhlIHRleHQgd2ls bCB0dXJuIHRvIGJlICcuLi4sIHR5cGljYWxseSBhIERIQ1B2NiByZWxheSBhZ2VudCwuLi4nLg0K DQoNClRvbWVrIC0gU2VjdGlvbiAxLCB0aGUgbGFzdCBwYXJhZ3JhcGguICJUaGUgYXV0b21hdGlj IG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluDQogIHRoaXMgZG9jdW1lbnQgZGVwZW5kcyIuIEl0IHNo b3VsZCBiZSAibWVjaGFuaXNtIGRlcGVuZHMiIG9yDQogICJtZWNoYW5pc21zIGRlcGVuZCIuDQoN CjQuIFRoYW5rcyBmb3IgeW91ciBjYXJlZnVsbmVzcy4gQWNjZXB0ZWQuDQoNCg0KVG9tZWsgLSBT ZWN0aW9uIDIsIFJlcXVlc3RvciBkZWZpbml0aW9uLiBSRkM1MDA3IGRlZmluZXMgcmVxdWVzdG9y IGFzIGEgbm90ZQ0KICB0aGF0IHNlbmRzIGxlYXNlcXVlcnkgbWVzc2FnZXMuIFdoaWxlIGl0IGlz IHR5cGljYWxseSBhIHJvdXRlciwgaXQNCiAgZG9lc24ndCBoYXZlIHRvIGJlIG9uZS4gUmVxdWVz dG9yIG1heSBiZSBhIHNlcGFyYXRlIHRvb2wgdGhhdCBjYW4gYmUNCiAgcnVuIG9uIGhvc3RzIG9y IHJvdXRlcnMgYWxpa2UuDQoNCjUuIEFjY2VwdGVkLiBUaGUgdGV4dCB3aWxsIHR1cm4gdG8gYmUg JyBSZXF1ZXN0b3I6IEEgbm9kZSBkZWZpbmVkIGluIFtSRkM1MDA3XSB0aGF0IGFjdHMgYXMgdGhl IGxlYXNlcXVlcnkgY2xpZW50LiAnDQoNCg0KVG9tZWsgLSBTZWN0aW9uIDQuIGlwdjYtcHJlZml4 IHNob3VsZCBiZSBvZiB2YXJpYWJsZSBsZW5ndGguIEluIG1vc3QgY2FzZXMgdGhlDQogIHByZWZp eCB1c2VkIGhlcmUgd2lsbCBiZSAvNTYgb3IgZXZlbiBzaG9ydGVyLiBUaGF0IHdpbGwgcmVzdWx0 IGluIGF0DQogIGxlYXN0IDkgYnl0ZXMgYmVpbmcgemVyb3MuIEJUVyBUaGlzIGFwcHJvYWNoIHdp bGwgYmUgcmVjb21tZW5kZWQgaW4NCiAgdGhlIG5leHQgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLWRo Yy1vcHRpb24tZ3VpZGVsaW5lcy4NCg0KNi4gQWNjZXB0ZWQuIFRoZSB0ZXh0IHdpbGwgdHVybiB0 byBiZSBhcyBmb2xsb3dzOg0KDQogICAnb3B0aW9uLWxlbmd0aDogIDIgKyBsZW5ndGggb2YgaXB2 Ni1wcmVmaXggKGluIE9jdGV0cykNCiAgIHBmeC1wb29sLWxlbjogICBMZW5ndGggZm9yIHRoZSBw cmVmaXggcG9vbCBpbiBiaXRzDQogICAuLi4NCiAgIGlwdjYtcHJlZml4OiAgICBJUHY2IHByZWZp eCBvZiB0aGUgcHJlZml4IHBvb2wsIHdoaWNoIGlzIHVwIHRvIDE2DQogICAgICAgICAgICAgICAg ICAgb2N0ZXRzIGluIGxlbmd0aC4gQml0cyBvdXRzaWRlcyBvZiB0aGUNCiAgICAgICAgICAgICAg ICAgICBwZngtcG9vbC1sZW4sIGlmIGluY2x1ZGVkLCBNVVNUIGJlIHplcm8uJw0KDQoNClRvbWVr IC0gU2VjdGlvbiA0LiBJdCBpcyBjdXN0b21hcnkgdG8gaW5jbHVkZSBsaXN0IG9mIG1lc3NhZ2Vz IHRoYXQgTUFZL01VU1QNCiAgTk9UIGluY2x1ZGUgdGhhdCBvcHRpb24uIFNvbWV0aGluZyBsaWtl ICJTZXJ2ZXIgTUFZIGluY2x1ZGUgdGhpcw0KICBvcHRpb24gaW4gUkVMQVktUkVQTCBpZiByZWxh eSBpbmNsdWRlZCBPUFRJT05fUFJFRklYX1BPT0wgaW4gT1JPDQogIG9wdGlvbiBpbiBSRUxBWS1G T1JXLiBJdCBNVVNUIE5PVCBhcHBlYXIgaW4gYW55IG1lc3NhZ2VzIHNlbnQgYnkNCiAgY2xpZW50 cy4gSXQgTUFZL01VU1QgTk9UIGFwcGVhciBpbiBMRUFTRVFVRVJZIG1lc3NhZ2UuIi4NCg0KNy4g QWNjZXB0ZWQuIFRoZSB0ZXh0IHdpbGwgdHVybiB0byBiZSAnIERIQ1B2NiBzZXJ2ZXIgTUFZIGlu Y2x1ZGUgdGhpcyBvcHRpb24gaW4gdGhlIFJFTEFZLUZPUlcgKDEyKSwgUkVMQVktUkVQTCAoMTMp LCBMRUFTRVFVRVJZLVJFUExZICgxNSkgYW5kIExFQVNFUVVFUlktREFUQSAoMTcpIG1lc3NhZ2Uu ICcNCg0KDQpUb21layAtIFNlY3Rpb24gNC4gIklmIHRoZSBhZG1pbmlzdHJhdGl2ZSBwb2xpY3kg b24gdGhlIHNlcnZlciBkb2VzIG5vdCBwZXJtaXQNCiAgdG8gc3VwcG9ydCByb3V0ZSBhZ2dyZWdh dGlvbiBvbiB0aGUgREhDUHY2IHJlbGF5IGFnZW50LCB0aGUgc3RhdHVzIG9mDQogIHRoZSBwcmVm aXggcG9vbCB3aWxsIGFsd2F5cyBiZSAnUmVsZWFzZWQnLiIgV291bGRuJ3QgaXQgYmUgYmV0dGVy IHRvDQogIGp1c3Qgbm90IGluY2x1ZGUgT1BUSU9OX1BSRUZJWF9QT09MPw0KDQpUaGUgc2VydmVy IG5lZWRzIGluY2x1ZGUgT1BUSU9OX1BSRUZJWF9QT09MIHBlciB0aGUgcmVxdWVzdCBpbiBPUk8g ZnJvbSB0aGUgcmVsYXkgdG8gd2l0aGRyYXcgdGhlIGFnZ3JlZ2F0aW9uIHJvdXRlLg0KDQoNClRv bWVrIC0gU2VjdGlvbiA1LCBzZWNvbmQgcGFyYWdyYXBoLiAiVGhlIHJlbGF5IGFnZW50IHNob3Vs ZCBpbmNsdWRlIHRoZQ0KICBJbnRlcmZhY2UgSUQgb3B0aW9uIi4gSXMgdGhpcyBub3JtYXRpdmUg bGFuZ3VhZ2U/IEkgdGhpbmsgaXQgaXMsIHNvIGl0DQogIHNob3VsZCBiZSAiU0hPVUxEIi4NCg0K U2FtZSBhcyB0aGUgb25lIGFib3ZlLiBBY2NlcHRlZC4NCg0KDQpUb21layAtIFNlY3Rpb24gNS4g Q29uc2lkZXIgdGhlIGZvbGxvd2luZyBzY2VuYXJpbzogVGhlcmUgYXJlIFggcmVxdWVzdGluZw0K ICByb3V0ZXJzIGJlaGluZCBhIHJlbGF5LiBTZXJ2ZXIgaXMgY29uZmlndXJlZCB0byBhbGxvdyBy b3V0ZQ0KICBhZ2dyZWdhdGlvbiwgc28gcG9vbCBvcHRpb24gaXMgc2VudC4gVGhlbiBhZG1pbmlz dHJhdG9yIGRlY2lkZXMgdG8NCiAgc3RvcCB1c2luZyBhZ2dyZWdhdGlvbiwgc28gaGUgdHVybnMg aXQgb2ZmLiBXaGVuIFgrMSBjbGllbnQgY29tZXMgaW4sDQogIHRoZSBzZXJ2ZXIgZG9lcyBub3Qg c2VuZCBQUkVGSVhfUE9PTCBhbnltb3JlLCBzbyBhY2NvcmRpbmcgdG8NCiAgcGFyYWdyYXBoIDQg aW4gc2VjdGlvbiA1LCByZWxheSBtdXN0IHdpdGhkcmF3IHRoZSBhc3NvY2lhdGVkDQogIHJvdXRl LiBIb3cgYXJlIHRoZSBmaXJzdCBYIGNsaWVudHMgcmVhY2hhYmxlPyBJIHN1cHBvc2UgdGhlIHJl bGF5DQogIG11c3Qga2VlcCByb3V0ZXMgdG8gdGhlbSBhbnl3YXkgYW5kIHRoZSBvbmUgcmVjZWl2 ZWQgaW4gUFJFRklYX1BPT0wgaXMNCiAgYW4gYWRkaXRpb25hbCBvbmUsIG5vdCBhIHJlcGxhY2Vt ZW50LCByaWdodD8NCg0KDQphLiBXaGVuIFgrMSBjbGllbnQgY29tZXMgaW4sIHRoZSBzZXJ2ZXIg c3RpbGwgc2VuZCBPUFRJT05fUFJFRklYX1BPT0wgcGVyIHRoZSBPUk8gZnJvbSB0aGUgcmVwbHkg dG8gd2l0aGRyYXcgdGhlIGFnZ3JlZ2F0aW9uIHJvdXRlLiBJZiB0aGUgcmVsYXkgbG9zZSB0aGUg bWVzc2FnZSBmcm9tIHRoZSBzZXJ2ZXIgYnkgYWNjaWRlbnQsIHRoZW4gaXQgY291bGQgdXNlIHRo ZSAnYWdpbmcnIChzZWxmLWhlYWxpbmcpIG1lY2hhbmlzbSB0byB3aXRoZHJhdyB0aGUgYWdncmVn YXRpb24gcm91dGUuDQpiLiBUaGUgZmlyc3QgWCBjbGllbnRzIGFyZSBzdGlsbCByZWFjaGFibGUg cGVyIHRoZSBQRCBwcm9jZXNzLCBiZWNhdXNlIHRoZSBQRSByb3V0ZXIgc3RpbGwgaGF2ZSB0aGUg c3BlY2lmaWVkIHJvdXRlIGZvciBlYWNoIGFjdGl2ZSBQRCBjdXN0b21lciBwcmVmaXguDQpjLiBZ ZXMsIHRoZSBhZ2dyZWdhdGlvbiByb3V0ZSBwZXIgdGhlIE9QVElPTl9QUkVGSVhfUE9PTCBpcyB0 aGUgYWRkaXRpb25hbCByb3V0ZSBlbnRyeSBpbiB0aGUgcm91dGluZyB0YWJsZSBvZiB0aGUgUEUg cm91dGVyLg0KDQoNClRvbWVrIC0gU2VjdGlvbiA2LCBwYXJhZ3JhcGggMi4gIkFmdGVyIHJlY2Vp dmluZyB0aGUgT3B0aW9uIFJlcXVlc3Qgb3B0aW9uDQogIChPUFRJT05fT1JPLCA2KSByZXF1ZXN0 aW5nIHRoZSBQcmVmaXggUG9vbCBvcHRpb24NCiAgKE9QVElPTl9QUkVGSVhfUE9PTCwgW1RCRF0p IGluIHRoZSByZWxheS0gZm9yd2FyZCBtZXNzYWdlcyBvZiB0aGUNCiAgUEQiLiBXaGF0IGRvZXMg UEQgbWVhbiBpbiB0aGlzIGNvbnRleHQ/IEkgdGhpbmsgeW91IG1lYW50DQogICJyZWxheS1mb3J3 YXJkIG1lc3NhZ2VzIHRoYXQgZW5jYXBzdWxhdGUgbWVzc2FnZXMgd2l0aCBJQV9QRA0KICBvcHRp b25zIi4gSXQncyBhd2Z1bGx5IGxvdCBvZiB3b3JkcywgYnV0IEknbSBub3Qgc3VyZSBob3cgdG8g c2F5IGl0DQogIHNpbXBsZXIuDQoNCjggLiBQRCBtZWFucyBESENQdjYgUHJlZml4IERlbGVnYXRp b24gKERIQ1B2Ni1QRCkgW1JGQzM2MzNdLiBJdCBpcyBkZWZpbml0ZWx5IG15IGZhdWx0IHRoYXQg eW91IGNhbid0IHJlYWQgaXQuIEhvdyBhYm91dCB0byBjaGFuZ2UgdGhlIHRleHQgdG8gYmUgJy4u LiBpbiB0aGUgcmVsYXktZm9yd2FyZCBtZXNzYWdlcyBvZiB0aGUgREhDUHY2LVBEJy4gQWNjZXB0 ZWQuDQoNCg0KVG9tZWsgLSBTZWN0aW9uIDYsIHBhcmFncmFwaCA2LiAiV2hlbiB0aGUgYWRtaW5p c3RyYXRvciBvZiB0aGUgc2VydmVyIGNoYW5nZXMNCiAgdGhlIHNldHRpbmcgbm90IHRvIHN1cHBv cnQgcm91dGUgYWdncmVnYXRpb24gb24gdGhlIHJlbGF5IGFnZW50IGZvcg0KICB0aGUgcGFydGlj dWxhciBwcmVmaXggcG9vbCwgdGhlIHN0YXR1cyBvZiB0aGUgcHJlZml4IHBvb2wgbWF5IGNoYW5n ZQ0KICBmcm9tICdBY3RpdmUnIHRvIGJlICdSZWxlYXNlZCcgaWYgYXQgbGVhc3Qgb25lIGRlbGVn YXRlZCBwcmVmaXgNCiAgd2l0aGluIHRoZSBwcmVmaXggcG9vbCBoYXMgdGhlIHZhbGlkIGxlYXNl LiIuIEkgdGhpbmsgb25jZQ0KICBhZG1pbmlzdHJhdG9yIGRpc2FibGVzIGl0LCB0aGUgc2VydmVy IHNob3VsZCBhbHdheXMgc2V0IHN0YXR1cyB0bw0KICByZWxlYXNlZC4gVGhlICJpZiBhdCBsZWFz dCBvbmUuLi4iIHBhcnQgaW4gbm90IG5lY2Vzc2FyeS4NCg0KVGhlIG9yaWdpbmFsIHRleHQgaGFz IHRoZSBtZWFuaW5nIHRoYXQgd2hlbiB0aGUgc2V2ZXIgaXMgc2V0IHRvIHN1cHBvcnQgdGhlIHJv dXRlIGFnZ3JlZ2F0aW9uIG9uIHRoZSByZWxheSwgdGhlIHN0YXR1cyBvZiB0aGUgcHJlZml4IHBv b2wgaXMgJ0FjdGl2ZScgaWYgYXQgbGVhc3Qgb25lIGRlbGVnYXRlZCBwcmVmaXggd2l0aGluIHRo ZSBwcmVmaXggcG9vbCBoYXMgdGhlIHZhbGlkIGxlYXNlLicgUmlnaHQ/DQoNCg0KVG9tZWsgLSBT ZWN0aW9uIDYsIHBhcmFncmFwaCA2LiBXaHkgZG9lcyB0aGUgc2VydmVyIGhhdmUgdG8gc2VuZCBS RUNPTkZJR1VSRT8NCiAgU28gdGhlIHJlbGF5IGNhbiByZS1sZWFybiBSUiBwcmVmaXhlcyBvbmNl IGFnZ3JlZ2F0aW9uIGhhcyBiZWVuDQogIGRpc2FibGVkPyBJdCBpcyByZWxhdGVkIHRvIG15IHF1 ZXN0aW9uIGFib3V0IFJSIHJlbWVtYmVyaW5nIChvciBub3QpDQogIHRoZSBzcGVjaWZpYyByb3V0 ZXMuIEFueXdheSwgaXQgd291bGQgYmUgbGVzcyBpbnRydXNpdmUgdG8gc2F5IHRoYXQNCiAgcmVs YXkgbXVzdCB1c2UgbGVhc2VxdWVyeSB0byBsZWFybiBleGlzdGluZyBkZWxlZ2F0aW9ucyB0aGFu IGZvcmNpbmcNCiAgYWxsIGNsaWVudHMgdG8gZG8gcmVjb25maWd1cmUsIGVzcGVjaWFsbHkgdGhh dCBmb3IgY2xpZW50cyBub3RoaW5nDQogIHdpbGwgY2hhbmdlLiBBbHNvLCBrZWVwIGluIG1pbmQg dGhhdCBSUnMgbWF5IG5vdCBzdXBwb3J0IHJlY29uZmlndXJlDQogIGFzIGl0IGlzIGFuIG9wdGlv bmFsIGZlYXR1cmUuDQoNCg0KYS4gVGhlIHNlcnZlciBzZW5kIHRoZSBSRUNPTkZJR1VSRSB3aGVu IHRoZSBzdGF0dXMgb2YgdGhlIHByZWZpeCBwb29sIGNoYW5nZWQgYWZ0ZXIgdGhlIGFkbWluaXN0 cmF0b3IncyBzZXR0aW5nLiBZZXMsIHRoZSByZWxheSBnZXQgdGhlIGNoYW5jZSB0byByZS1sZWFy biB0aGUgc3RhdHVzIG9mIHRoZSBwcmVmaXggcG9vbC4NCmIuIFRoZSBSUiBtaWdodCBub3QgYmUg cmVudW1iZXJlZC4NCmMuIFJFQ09ORklHVVJFIHNvdW5kcyAxIG9mIDMgY29uZmlndXJhdGlvbiBw cm9jZXNzZXMgZGVmaW5lZCBib3RoIGluIFJGQzMzMTUvMzYzMy4gSWYgdGhlIFJSIG1heSBub3Qg c3VwcG9ydCB0byBpbW1lZGlhdGVseSByZXNwb25zZSBSRUNPTkZJR1VSRSAodGhvdWdoIEkgY2Fu J3QgaW1hZ2UgaXQpLCB3ZSBzdGlsbCBjYW4gcmVseSBvbiB0aGUgcmVndWxhciBSRU5FVywgcmln aHQ/DQoNCg0KVG9tZWsgLSBTZWN0aW9uIDcuIFNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2hvdWxk IGFsc28gcmVmZXJlbmNlIHNlY3Rpb24gMTUgb2YNCiAgUkZDMzYzMy4NCg0KOSAuIEFjY2VwdGVk LiBUaGUgdGV4dCB3aWxsIHR1cm4gdG8gYmUgJ1NlY3VyaXR5IGlzc3VlcyByZWxhdGVkIERIQ1B2 NiBhcmUgZGVzY3JpYmVkIGluIHNlY3Rpb24gMjMgb2YgW1JGQzMzMTVdIGFuZCBzZWN0aW9uIDE1 IG9mIFtSRkMzNjMzXS4nDQoNCg0KVG9tZWsgLSBRdWVzdGlvbnM6DQoxLiBMZXQncyBhc3N1bWUg dGhlIFBFIHJvdXRlciBhbm5vdW5jZXMgMjAwMTpkYjg6MTo6LzQ4IHByZWZpeCB0aGF0IGlzDQpz cGxpdCBpbnRvIC81NiBwcmVmaXhlcy4gU29tZW9uZSB0cmllcyB0byByZWFjaCBhIGN1c3RvbWVy IHRoYXQgaXMNCmN1cnJlbnRseSBvZmZsaW5lLiBXaGF0IGlzIFBFIHN1cHBvc2VkIHRvIGRvIHdp dGggdGhvc2UgcGFja2V0cz8NClJlc3BvbmQgd2l0aCBJQ01QIHR5cGU9MSBjb2RlPTAgKG5vIHJv dXRlIHRvIGRlc3RpbmF0aW9uKT8NCg0KUEUgcm91dGVyIHdpbGwgYWN0IGFzIHRoZSBzYW1lIGFz IHRoZSB1c3VhbCBhZnRlciB0aGUgcGFja2V0IGFycml2ZSBpdCB3aGVuIHRoZSBjdXN0b21lciBu ZXR3b3JrIGlzIHVucmVhY2hhYmxlLg0KDQoNClRvbWVrIC0gUXVlc3Rpb25zOg0KMi4gUEUgaGFz IGEgMjAwMTpkYjg6MTo6LzQ4IHByZWZpeCBhbmQgdGhlcmUgYXJlIDIgcHJlZml4ZXMgZGVsZWdh dGVkDQp0byBjbGllbnRzOiAyMDAxOmRiODoxOjgwMDA6Oi82NCBhbmQgMjAwMTpkYjg6MTo4MDAx OjovNjQuIFRoZQ0KYWRtbmlzdHJhdGl2ZSBwb2xpY3kgZG9lcyBub3QgYWxsb3cgcm91dGUgYWdn cmVnYXRpb24sIHNvDQpPUFRJT05fUFJFRklYX1BPT0wgaGFzIHN0YXR1cyBzZXQgdG8gcmVsZWFz ZS4gSXMgUEUgYWxsb3dlZCB0bw0KYWdncmVnYXRlIGJvdGggcm91dGVzIGFueXdheSBhbmQgYW5u b3VuY2UgMjAwMTpkYjg6MTo4MDAwOjovNjM/DQpQZXJoYXBzIGFsbG93aW5nIHN1Y2ggYmVoYXZp b3VyIGNvdWxkIGJlIGRlZmluZWQgYXMgc3RhdHVzIGNvZGUgPSAyLiBJDQpkb24ndCBrbm93IGlm IGNvbnRyb2xsaW5nIHRoaXMgaXMgYSBnb29kIGlkZWEsIHNvIGZlZWwgZnJlZSB0byBpZ25vcmUN CnRoaXMgc3VnZ2VzdGlvbi4NCg0KSWYgYWRtaW5pc3RyYXRpdmUgcG9saWN5IGRvZXMgbm90IGFs bG93IHJvdXRlIGFnZ3JlZ2F0aW9uLCB0aGUgUEUgcm91dGVyIHdpbGwgYWN0IGFzIHRoZSBzYW1l IGFzIHRoZSB1c3VhbC4gSXQgd2lsbCBhbm5vdW5jZSAyMDAxOmRiODoxOjgwMDA6Oi82MyBpbiB0 aGlzIGNhc2UgaWYgdGhlIHJvdXRpbmcgcHJvdG9jb2wgaXMgZW5hYmxlZCBvbiBpdHMgbmV0d29y ay1mYWNpbmcgaW50ZXJmYWNlLiBJIGRvbid0IGJlbGlldmUgd2UgbmVlZCBtb3JlIHN0YXR1cyBj b2RlIGhlcmUuDQoNCg0KVGhlIG90aGVyIG9mIHlvdXIgY29tbWVudHMgd2lsbCBiZSByZXBsaWVk IHNvb24uDQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVhZg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBUb21layBNcnVnYWxza2kgW21haWx0bzp0b21hc3oubXJ1Z2Fsc2tpQGdt YWlsLmNvbV0gDQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDI1LCAyMDEyIDI6MjYgQU0NClRvOiBk aGN3Zw0KQ2M6IExlYWYgeWVoDQpTdWJqZWN0OiBDb21tZW50cyBvbiBkcmFmdC15ZWgtZGhjLWRo Y3B2Ni1wcmVmaXgtcG9vbC1vcHQtMDgNCg0KT24gMzAuMDcuMjAxMiAwMzozNSwgTGVhZiB5ZWgg d3JvdGU6DQo+IERlYXIgREhDIGZvbGtzLA0KPiANCj4gVGhlIGRyYWZ0ICh2ZXIuLTA4KSAmIHRo ZSBwcm9wb3NlZCAoT1BUSU9OX1BSRUZJWF9QT09MKSBvbiB0aGUNCj4gYWdlbmRhIG9mIElFVEY4 NCBESEMgc2Vzc2lvbiANCj4gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy84 NC9hZ2VuZGEvZGhjLyApLCBpcyB3YWl0aW5nIA0KPiBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1l bnRzLg0KSGksDQoNCllvdSd2ZSBhc2tlZCBmb3IgaXQsIHNvIGhlcmUgYXJlIG15IGNvbW1lbnRz LiBBbHRob3VnaCB0aGVyZSBhcmUgbWFueQ0KdGhpbmdzIG1lbnRpb25lZCBiZWxvdywgSSB0aGlu ayB0aGUgZHJhZnQgaXMgYSBnb29kIGlkZWEuIEl0IGlzIGluIGENCmdvb2Qgc2hhcGUgYW5kIEkg c3VwcG9ydCBpdC4gTm9uZSBvZiB0aGUgdGhpbmdzIG1lbnRpb25lZCBiZWxvdyBhcmUNCnNob3ct c3RvcHBlcnMsIGFuZCBtb3N0IGNhbiBiZSBlYXNpbHkgZml4ZWQuDQoNCkkgd2lsbCBzZW5kIG91 dCBzZXBhcmF0ZSBtYWlsIHRvIHJlc3BvbmQgdG8gYWRvcHRpb24gY2FsbC4NCg0KR2VuZXJpYyBj b21tZW50czoNCg0KLSBNdWx0aXBsZSBwcmVmaXggcG9vbHMgc2VlbSB0byBiZSBhbGxvd2VkIChz ZWN0aW9uIDYsIHBhcmFncmFwaCA3DQogIHN1Z2dlc3RzIHRoYXQpLiBJdCBtYXkgYmUgdXNlZnVs IHRvIG5vdGUgdGhhdCBtdWx0aXBsZSBwcmVmaXggcG9vbHMNCiAgbXVzdCBub3Qgb3ZlcmxhcC4N Cg0KLSBUaGVyZSBhcmUgbWFueSBub3JtYXRpdmUgbG9va2luZyB3b3JkcyAobXVzdCwgc2hhbGwg ZXRjLikgdGhhdCBhcmUNCiAgbm90IGNhcGl0YWxpemVkLg0KDQotIEhhdmUgeW91IGNvbnNpZGVy ZWQgZGVmaW5pbmcgbmV3IGxlYXNlcXVlcnkgcXVlcnkgdHlwZToNCiAgUVVFUllfQllfUFJFRklY X1BPT0w/IFNlcnZlciBjb3VsZCByZXR1cm4gYWxsIGxlYXNlcyB0aGF0DQogIGJlbG9uZyB0byBz cGVjaWZpZWQgcHJlZml4IHBvb2wuIEkgdGhpbmsgaXQgd291bGQgYmUgZWFzaWVyIHRvDQogIGlt cGxlbWVudCBvbmUgbmV3IHF1ZXJ5IHR5cGUgdGhhbiBtb2RpZnlpbmcgdGhlIGNvZGUgZm9yIGV4 aXN0aW5nIDMNCiAgcXVlcnkgdHlwZXMuDQoNCi0gU2luY2UgeW91ciBvcHRpb24gYWZmZWN0cyBo b3cgZXhpc3RpbmcgcXVlcnkgdHlwZXMgaW4gbGVhc2VxdWVyeQ0KICB3b3JrLCB0aGUgZnJvbnQg cGFnZSBvZiB0aGUgZHJhZnQgc2hvdWxkIGhhdmUgInVwZGF0ZXMgUkZDNTAwNywNCiAgNTQ2MCAo aWYgYXBwcm92ZWQpIiBjbGF1c2UuDQoNCi0gSSB0aGluayBJIGhhdmUgY29tbWVudGVkIG9uIHRo aXMgYmVmb3JlLCBidXQgSSBjYW4ndCBmaW5kIGl0IGFueXdoZXJlLA0KICBzbyBJJ2xsIHJlc3Rh dGUgbXkgY29uY2VybnMgYWdhaW4uIFRoaXMgaXMgYmFzaWNhbGx5IGEgc2lnbmFsbGluZw0KICBw cm90b2NvbCBvbiB0b3Agb2Ygbm9ybWFsIGV4Y2hhbmdlLiBJbiBpdHMgY3VycmVudCBmb3JtIGl0 IGFsbG93cw0KICBzZXJ2ZXIgdG8gbWFrZSBzdHJhbmdlIHRoaW5ncyBsaWtlIG1ha2UgdGhlIHBv b2wgYWN0aXZlIHdoZW4NCiAgcmVzcG9uZGluZyB0byBSRUxFQVNFIG9yIHNheWluZyB0aGF0IHRo ZSBwb29sIGlzIHJlbGVhc2VkIHdoZW4NCiAgYXNzaWduaW5nIGEgcHJlZml4IGluIHJlc3BvbnNl IHRvIFJFUVVFU1QuDQoNCi0gVGhhdCBkcmFmdCB3YXMgd3JpdHRlbiBpbiBCQkYgbmV0d29ya3Mg aW4gbWluZCwgYnV0IGl0IGNhbiBiZSB1c2VkDQogIGluIGEgZ2VuZXJhbCBjYXNlIGFzIHdlbGwu IEEgc3RhdGVtZW50IHRvIHBvaW50IHRoYXQgb3V0IHNob3VsZCBiZQ0KICBhZGRlZC4NCg0KQ29t bWVudHMgc3BlY2lmaWMgdG8gdGhlIHRleHQ6DQoNCi0gU2VjdGlvbiAxOiBUaGlzIGlzIHJlYWxs eSBhIG5pdC1waWNrIHN0eWxlIGNvbW1lbnQgICJUaGUgREhDUHY2DQogIHByb3RvY29sIi4gSSBh bHdheXMgaGF2ZSBwcm9ibGVtIGhvdyB0byB3cml0ZSBpdC4gQWRkaW5nIHByb3RvY29sDQogIGFm dGVyIERIQ1AgaXMgcmVkdW5kYW50LCBhcyBQIGluIERIQ1Agc3RhbmRzIGZvciBwcm90b2NvbC4g T24gdGhlDQogIG90aGVyIGhhbmQsIHJlbW92aW5nICJwcm90b2NvbCIgd291bGQgbWFrZSBpdCBs ZXNzIHJlYWRhYmxlIGJ5IHBlb3BsZQ0KICB3aG8gZG9uJ3Qga25vdyB3aGF0IERIQ1AgYWNyb255 bSBzdGFuZHMgZm9yLiBJIHRoaW5rIGl0IHByb2JhYmx5DQogIHNob3VsZCBzdGF5IGFzIGl0IGlz Lg0KDQotIFNlY3Rpb24gMSwgc2Vjb25kIHBhcmFncmFwaC4gWW91IG1lbnRpb25kIFJScyB3aXRo b3V0IGRlZmluaW5nIHRoYXQNCiAgYWNyb255bS4gQWx0aG91Z2ggaXQgaXMgbGF0ZXIgZXhwbGFp bmVkIGluIHNlY3Rpb24gMiwgaXQgd291bGQgYmUgZ29vZA0KICB0byByZXBsYWNlIGl0cyBmaXJz dCB1c2Ugd2l0aCAiUmVxdWVzdGluZyBSb3V0ZXIgKFJSKSIuDQoNCi0gU2VjdGlvbiAxLiBGaXJz dCBwYXJhZ3JhcGggb24gcGFnZSA0LiAiQnVsayBMZWFzZXF1ZXJ5IFtSRkM1NDYwXQ0KICBzcGVj aWZpZXMgYSBtZWNoYW5pc20gZm9yIGJ1bGsgdHJhbnNmZXIgb2YgdGhlIGJpbmRpbmcgZGF0YSBv ZiBlYWNoDQogIGRlbGVnYXRlZCBwcmVmaXggZnJvbSB0aGUgc2VydmVyIHRvIHRoZSByZXF1ZXN0 b3IgKGkuZS4sIGEgREhDUHY2DQogIHJlbGF5IGFnZW50KSIuIFdoaWxlIHJlcXVlc3RvciBpcyB0 eXBpY2FsbHkgdGhlIHJlbGF5IGFnZW50LCBpdA0KICBkb2Vzbid0IGhhdmUgdG8gYmUuIEl0IG1h eSBiZSBhIHNlcGFyYXRlIGVudGl0eSBhcyB3ZWxsLiBJIHdvdWxkDQogIHJlcGxhY2UgImkuZS4i IHdpdGggInR5cGljYWxseSIuDQoNCi0gU2VjdGlvbiAxLCB0aGUgbGFzdCBwYXJhZ3JhcGguICJU aGUgYXV0b21hdGljIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluDQogIHRoaXMgZG9jdW1lbnQgZGVw ZW5kcyIuIEl0IHNob3VsZCBiZSAibWVjaGFuaXNtIGRlcGVuZHMiIG9yDQogICJtZWNoYW5pc21z IGRlcGVuZCIuDQoNCi0gU2VjdGlvbiAyLCBSZXF1ZXN0b3IgZGVmaW5pdGlvbi4gUkZDNTAwNyBk ZWZpbmVzIHJlcXVlc3RvciBhcyBhIG5vdGUNCiAgdGhhdCBzZW5kcyBsZWFzZXF1ZXJ5IG1lc3Nh Z2VzLiBXaGlsZSBpdCBpcyB0eXBpY2FsbHkgYSByb3V0ZXIsIGl0DQogIGRvZXNuJ3QgaGF2ZSB0 byBiZSBvbmUuIFJlcXVlc3RvciBtYXkgYmUgYSBzZXBhcmF0ZSB0b29sIHRoYXQgY2FuIGJlDQog IHJ1biBvbiBob3N0cyBvciByb3V0ZXJzIGFsaWtlLg0KDQotIFNlY3Rpb24gNC4gaXB2Ni1wcmVm aXggc2hvdWxkIGJlIG9mIHZhcmlhYmxlIGxlbmd0aC4gSW4gbW9zdCBjYXNlcyB0aGUNCiAgcHJl Zml4IHVzZWQgaGVyZSB3aWxsIGJlIC81NiBvciBldmVuIHNob3J0ZXIuIFRoYXQgd2lsbCByZXN1 bHQgaW4gYXQNCiAgbGVhc3QgOSBieXRlcyBiZWluZyB6ZXJvcy4gQlRXIFRoaXMgYXBwcm9hY2gg d2lsbCBiZSByZWNvbW1lbmRlZCBpbg0KICB0aGUgbmV4dCB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYt ZGhjLW9wdGlvbi1ndWlkZWxpbmVzLg0KDQotIFNlY3Rpb24gNC4gSXQgaXMgY3VzdG9tYXJ5IHRv IGluY2x1ZGUgbGlzdCBvZiBtZXNzYWdlcyB0aGF0IE1BWS9NVVNUDQogIE5PVCBpbmNsdWRlIHRo YXQgb3B0aW9uLiBTb21ldGhpbmcgbGlrZSAiU2VydmVyIE1BWSBpbmNsdWRlIHRoaXMNCiAgb3B0 aW9uIGluIFJFTEFZLVJFUEwgaWYgcmVsYXkgaW5jbHVkZWQgT1BUSU9OX1BSRUZJWF9QT09MIGlu IE9STw0KICBvcHRpb24gaW4gUkVMQVktRk9SVy4gSXQgTVVTVCBOT1QgYXBwZWFyIGluIGFueSBt ZXNzYWdlcyBzZW50IGJ5DQogIGNsaWVudHMuIEl0IE1BWS9NVVNUIE5PVCBhcHBlYXIgaW4gTEVB U0VRVUVSWSBtZXNzYWdlLiIuDQoNCi0gU2VjdGlvbiA0LiAiSWYgdGhlIGFkbWluaXN0cmF0aXZl IHBvbGljeSBvbiB0aGUgc2VydmVyIGRvZXMgbm90IHBlcm1pdA0KICB0byBzdXBwb3J0IHJvdXRl IGFnZ3JlZ2F0aW9uIG9uIHRoZSBESENQdjYgcmVsYXkgYWdlbnQsIHRoZSBzdGF0dXMgb2YNCiAg dGhlIHByZWZpeCBwb29sIHdpbGwgYWx3YXlzIGJlICdSZWxlYXNlZCcuIiBXb3VsZG4ndCBpdCBi ZSBiZXR0ZXIgdG8NCiAganVzdCBub3QgaW5jbHVkZSBPUFRJT05fUFJFRklYX1BPT0w/DQoNCi0g U2VjdGlvbiA1LCBzZWNvbmQgcGFyYWdyYXBoLiAiVGhlIHJlbGF5IGFnZW50IHNob3VsZCBpbmNs dWRlIHRoZQ0KICBJbnRlcmZhY2UgSUQgb3B0aW9uIi4gSXMgdGhpcyBub3JtYXRpdmUgbGFuZ3Vh Z2U/IEkgdGhpbmsgaXQgaXMsIHNvIGl0DQogIHNob3VsZCBiZSAiU0hPVUxEIi4NCg0KLSBTZWN0 aW9uIDUuIENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86IFRoZXJlIGFyZSBYIHJlcXVl c3RpbmcNCiAgcm91dGVycyBiZWhpbmQgYSByZWxheS4gU2VydmVyIGlzIGNvbmZpZ3VyZWQgdG8g YWxsb3cgcm91dGUNCiAgYWdncmVnYXRpb24sIHNvIHBvb2wgb3B0aW9uIGlzIHNlbnQuIFRoZW4g YWRtaW5pc3RyYXRvciBkZWNpZGVzIHRvDQogIHN0b3AgdXNpbmcgYWdncmVnYXRpb24sIHNvIGhl IHR1cm5zIGl0IG9mZi4gV2hlbiBYKzEgY2xpZW50IGNvbWVzIGluLA0KICB0aGUgc2VydmVyIGRv ZXMgbm90IHNlbmQgUFJFRklYX1BPT0wgYW55bW9yZSwgc28gYWNjb3JkaW5nIHRvDQogIHBhcmFn cmFwaCA0IGluIHNlY3Rpb24gNSwgcmVsYXkgbXVzdCB3aXRoZHJhdyB0aGUgYXNzb2NpYXRlZA0K ICByb3V0ZS4gSG93IGFyZSB0aGUgZmlyc3QgWCBjbGllbnRzIHJlYWNoYWJsZT8gSSBzdXBwb3Nl IHRoZSByZWxheQ0KICBtdXN0IGtlZXAgcm91dGVzIHRvIHRoZW0gYW55d2F5IGFuZCB0aGUgb25l IHJlY2VpdmVkIGluIFBSRUZJWF9QT09MIGlzDQogIGFuIGFkZGl0aW9uYWwgb25lLCBub3QgYSBy ZXBsYWNlbWVudCwgcmlnaHQ/DQoNCi0gU2VjdGlvbiA1LiBUaGUgbGFzdCBwYXJhZ3JhcGggYWJv dXQgbGVhc2VxdWVyeSBzaG91bGQgcHJvYmFibHkgYmUNCiAgbW92ZWQgdG8gYSBzZXBhcmF0ZSBz ZWN0aW9uICJMZWFzZXF1ZXJ5IHJlcXVlc3RvciBiZWhhdmlvciIuDQoNCi0gU2VjdGlvbiA2LCBw YXJhZ3JhcGggMi4gIkFmdGVyIHJlY2VpdmluZyB0aGUgT3B0aW9uIFJlcXVlc3Qgb3B0aW9uDQog IChPUFRJT05fT1JPLCA2KSByZXF1ZXN0aW5nIHRoZSBQcmVmaXggUG9vbCBvcHRpb24NCiAgKE9Q VElPTl9QUkVGSVhfUE9PTCwgW1RCRF0pIGluIHRoZSByZWxheS0gZm9yd2FyZCBtZXNzYWdlcyBv ZiB0aGUNCiAgUEQiLiBXaGF0IGRvZXMgUEQgbWVhbiBpbiB0aGlzIGNvbnRleHQ/IEkgdGhpbmsg eW91IG1lYW50DQogICJyZWxheS1mb3J3YXJkIG1lc3NhZ2VzIHRoYXQgZW5jYXBzdWxhdGUgbWVz c2FnZXMgd2l0aCBJQV9QRA0KICBvcHRpb25zIi4gSXQncyBhd2Z1bGx5IGxvdCBvZiB3b3Jkcywg YnV0IEknbSBub3Qgc3VyZSBob3cgdG8gc2F5IGl0DQogIHNpbXBsZXIuDQoNCi0gU2VjdGlvbiA2 LCBwYXJhZ3JhcGggNi4gIldoZW4gdGhlIGFkbWluaXN0cmF0b3Igb2YgdGhlIHNlcnZlciBjaGFu Z2VzDQogIHRoZSBzZXR0aW5nIG5vdCB0byBzdXBwb3J0IHJvdXRlIGFnZ3JlZ2F0aW9uIG9uIHRo ZSByZWxheSBhZ2VudCBmb3INCiAgdGhlIHBhcnRpY3VsYXIgcHJlZml4IHBvb2wsIHRoZSBzdGF0 dXMgb2YgdGhlIHByZWZpeCBwb29sIG1heSBjaGFuZ2UNCiAgZnJvbSAnQWN0aXZlJyB0byBiZSAn UmVsZWFzZWQnIGlmIGF0IGxlYXN0IG9uZSBkZWxlZ2F0ZWQgcHJlZml4DQogIHdpdGhpbiB0aGUg cHJlZml4IHBvb2wgaGFzIHRoZSB2YWxpZCBsZWFzZS4iLiBJIHRoaW5rIG9uY2UNCiAgYWRtaW5p c3RyYXRvciBkaXNhYmxlcyBpdCwgdGhlIHNlcnZlciBzaG91bGQgYWx3YXlzIHNldCBzdGF0dXMg dG8NCiAgcmVsZWFzZWQuIFRoZSAiaWYgYXQgbGVhc3Qgb25lLi4uIiBwYXJ0IGluIG5vdCBuZWNl c3NhcnkuDQoNCi0gU2VjdGlvbiA2LCBwYXJhZ3JhcGggNi4gV2h5IGRvZXMgdGhlIHNlcnZlciBo YXZlIHRvIHNlbmQgUkVDT05GSUdVUkU/DQogIFNvIHRoZSByZWxheSBjYW4gcmUtbGVhcm4gUlIg cHJlZml4ZXMgb25jZSBhZ2dyZWdhdGlvbiBoYXMgYmVlbg0KICBkaXNhYmxlZD8gSXQgaXMgcmVs YXRlZCB0byBteSBxdWVzdGlvbiBhYm91dCBSUiByZW1lbWJlcmluZyAob3Igbm90KQ0KICB0aGUg c3BlY2lmaWMgcm91dGVzLiBBbnl3YXksIGl0IHdvdWxkIGJlIGxlc3MgaW50cnVzaXZlIHRvIHNh eSB0aGF0DQogIHJlbGF5IG11c3QgdXNlIGxlYXNlcXVlcnkgdG8gbGVhcm4gZXhpc3RpbmcgZGVs ZWdhdGlvbnMgdGhhbiBmb3JjaW5nDQogIGFsbCBjbGllbnRzIHRvIGRvIHJlY29uZmlndXJlLCBl c3BlY2lhbGx5IHRoYXQgZm9yIGNsaWVudHMgbm90aGluZw0KICB3aWxsIGNoYW5nZS4gQWxzbywg a2VlcCBpbiBtaW5kIHRoYXQgUlJzIG1heSBub3Qgc3VwcG9ydCByZWNvbmZpZ3VyZQ0KICBhcyBp dCBpcyBhbiBvcHRpb25hbCBmZWF0dXJlLg0KDQotIFNlY3Rpb24gNiwgbGFzdCAyIHBhcmFncmFw aHMuIEkgd291bGQgbW92ZSBkaXNjdXNzaW9uIGFib3V0IGxlYXNlcXVlcnkNCiAgdG8gYSBzZXBh cmF0ZSBzdWItc2VjdGlvbi4NCg0KLSBTZWN0aW9uIDYsIGxhc3QgcGFyYWdyYXBoLiBXaHkgcmVw ZWF0aW5nIHByZWZpeCBwb29sIGluIGV2ZXJ5DQogIGNsaWVudC1kYXRhIG9wdGlvbj8gSXQgd2ls bCBhbGwgY29udGFpbiB0aGUgc2FtZSB2YWx1ZS4gSXQgd291bGQgYmUNCiAgbW9yZSByZWFzb25h YmxlIHRvIHNlbmQgaXQgYmFjayBvbmx5IG9uZSBvciBldmVuIG5vdCBzZW5kIGl0IGF0IGFsbA0K ICBpZiByZXF1ZXN0b3Igc2VudCBwcmVmaXggcG9vbCBvcHRpb24uIElmIHJlcXVlc3RvciBkaWQg dGhhdCwgYXJlIHRoZXJlDQogIGFueSBjYXNlcyB3aGVyZSBzZXJ2ZXIgY291bGQgc2VuZCBiYWNr IHRoZSBwcmVmaXggcG9vbCBvcHRpb24gd2l0aA0KICBkaWZmZXJlbnQgdmFsdWVzIHRoYW4gdGhl IHJlcXVlc3RvciBhc2tlZCBmb3I/IEkgZG9uJ3QgdGhpbmsgc28uDQoNCi0gU2VjdGlvbiA3LiBT ZWN1cml0eSBjb25zaWRlcmF0aW9uIHNob3VsZCBhbHNvIHJlZmVyZW5jZSBzZWN0aW9uIDE1IG9m DQogIFJGQzM2MzMuDQoNClF1ZXN0aW9uczoNCjEuIExldCdzIGFzc3VtZSB0aGUgUEUgcm91dGVy IGFubm91bmNlcyAyMDAxOmRiODoxOjovNDggcHJlZml4IHRoYXQgaXMNCnNwbGl0IGludG8gLzU2 IHByZWZpeGVzLiBTb21lb25lIHRyaWVzIHRvIHJlYWNoIGEgY3VzdG9tZXIgdGhhdCBpcw0KY3Vy cmVudGx5IG9mZmxpbmUuIFdoYXQgaXMgUEUgc3VwcG9zZWQgdG8gZG8gd2l0aCB0aG9zZSBwYWNr ZXRzPw0KUmVzcG9uZCB3aXRoIElDTVAgdHlwZT0xIGNvZGU9MCAobm8gcm91dGUgdG8gZGVzdGlu YXRpb24pPw0KDQoyLiBQRSBoYXMgYSAyMDAxOmRiODoxOjovNDggcHJlZml4IGFuZCB0aGVyZSBh cmUgMiBwcmVmaXhlcyBkZWxlZ2F0ZWQNCnRvIGNsaWVudHM6IDIwMDE6ZGI4OjE6ODAwMDo6LzY0 IGFuZCAyMDAxOmRiODoxOjgwMDE6Oi82NC4gVGhlDQphZG1uaXN0cmF0aXZlIHBvbGljeSBkb2Vz IG5vdCBhbGxvdyByb3V0ZSBhZ2dyZWdhdGlvbiwgc28NCk9QVElPTl9QUkVGSVhfUE9PTCBoYXMg c3RhdHVzIHNldCB0byByZWxlYXNlLiBJcyBQRSBhbGxvd2VkIHRvDQphZ2dyZWdhdGUgYm90aCBy b3V0ZXMgYW55d2F5IGFuZCBhbm5vdW5jZSAyMDAxOmRiODoxOjgwMDA6Oi82Mz8NCg0KUGVyaGFw cyBhbGxvd2luZyBzdWNoIGJlaGF2aW91ciBjb3VsZCBiZSBkZWZpbmVkIGFzIHN0YXR1cyBjb2Rl ID0gMi4gSQ0KZG9uJ3Qga25vdyBpZiBjb250cm9sbGluZyB0aGlzIGlzIGEgZ29vZCBpZGVhLCBz byBmZWVsIGZyZWUgdG8gaWdub3JlDQp0aGlzIHN1Z2dlc3Rpb24uDQoNCk9rLCB0aGF0J3MgaXQu IFNvcnJ5IGZvciBzZW5kaW5nIHN1Y2ggbG9uZyBhbmQgYm9yaW5nIG1haWwuIEkgaG9wZSB5b3UN CmZpbmQgYXQgbGVhc3Qgc29tZSBvZiB0aG9zZSBjb21tZW50cyB1c2VmdWwuIEFnYWluLCBkZXNw aXRlIG51bWVyb3VzDQpjb21tZW50cywgSSByZWFsbHkgc3VwcG9ydCBpdC4NCg0KVG9tZWsNCg0K From leaf.yeh.sdo@gmail.com Tue Aug 28 08:53:32 2012 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 0B71A21F856D for ; Tue, 28 Aug 2012 08:53:31 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpqnjXLg+iKE for ; Tue, 28 Aug 2012 08:53:28 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF4BB21F852C for ; Tue, 28 Aug 2012 08:52:59 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9471809pbb.31 for ; Tue, 28 Aug 2012 08:52:59 -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:x-mailer :thread-index:content-language; bh=jLs2IA52aViPpRZubfWmv60DNb1rk8FPZbdOx7Z7cU8=; b=AIhZPmxScPHnnUkewLqtBMFsdRqGCxvs6wFXbIAbBF4UUgNxHGXVcNK5o1f6TLP9lb 4PxlpKtCyfIhd30SKy44CwYOk4LsNT4Y/Vg2P8XqDRJrJoxXhCdEsmKokwsU8SVMEt+U kWxKluRghmZBI8ExHublCLQ2TvGLgjeMwfuOT8hJId3qGVN7QRCMUzDkq4UrtPGsQKOD bR/bmkK2s6HrImFpffyEZLD+7ei6L7kK/Pd3PnOn1sPYLev/1QoTxt0cUQdfRR5mMw0V DGzRKwHhy7QaXSeopUlbF1vJiGcT2WOd3zpyQ+tVcZl+gREIyIPdaRnSOAqr5s6RWqbJ 1d6Q== Received: by 10.66.74.100 with SMTP id s4mr38601683pav.27.1346169179337; Tue, 28 Aug 2012 08:52:59 -0700 (PDT) Received: from lst9242355d22a ([218.18.217.124]) by mx.google.com with ESMTPS id ol3sm227670pbb.42.2012.08.28.08.52.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 08:52:58 -0700 (PDT) From: "Leaf Yeh" To: "'Leaf yeh'" , "'Tomek Mrugalski'" References: <5037C726.2070406@gmail.com> In-Reply-To: Date: Tue, 28 Aug 2012 23:52:54 +0800 Message-ID: <503ce95a.6383440a.27ef.1719@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: AQHNgiXnOAnjjw7Zjk+PytbTkNCew5duyIKQgACbQJA= Content-Language: zh-cn Cc: 'dhcwg' Subject: Re: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 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, 28 Aug 2012 15:53:32 -0000 Updated - 7. Accepted. The text will turn to be 'DHCPv6 relay agent MAY include this option in RELAY-FORW (12) message. DHCPv6 server MAY include this option in the RELAY-REPL (13), LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) message. ' Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Leaf yeh Sent: Tuesday, August 28, 2012 9:22 PM To: Tomek Mrugalski Cc: dhcwg Subject: Re: [dhcwg] Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 Hi Tomek, Your comment looks always thorough. I will find more time to review all the below comments for the update of draft (OPTION_PREFIX_POOL) to ver.-09. The following are my feedback to some of your comments on the text of the draft: Tomek - Multiple prefix pools seem to be allowed (section 6, paragraph 7 suggests that). It may be useful to note that multiple prefix pools must not overlap. 1. Accepted. The replaced text in Section 6 will be "Note that these prefix pools does not overlay, the delegated prefix is only from one prefix pool." Tomek - There are many normative looking words (must, shall etc.) that are not capitalized. 2. Accepted. In fact, I will capitalize all of the 'must, should and may' in the draft. Tomek - In its current form it allows server to make strange things like make the pool active when responding to RELEASE or saying that the pool is released when assigning a prefix in response to REQUEST. Yes, when the administrator of the server turn on the setting to support route aggregation on the relay, the server may add the aggregation route through the OPTION_PREFIX_POOL in the RELAY-REPL message of the REPLY to the RELEASE when the released PD prefix is not the last PD prefix in the pool; when the administrator of the server turn off the setting to support route aggregation on the relay, the server may withdraw the aggregation route in response to REQUEST of PD. Tomek - That draft was written in BBF networks in mind, but it can be used in a general case as well. A statement to point that out should be added. I believe the draft (OPTION_PREFIX_POOL) has already used the language of IETF, just referred to BBF TR-177 in the introduction, it may emphasize the case when the PE router acts as DHCPv6 relay. Tomek - Section 1: This is really a nit-pick style comment "The DHCPv6 protocol". I always have problem how to write it. Adding protocol after DHCP is redundant, as P in DHCP stands for protocol. On the other hand, removing "protocol" would make it less readable by people who don't know what DHCP acronym stands for. I think it probably should stay as it is. It could be either as you want. Tomek - Section 1, second paragraph. You mentiond RRs without defining that acronym. Although it is later explained in section 2, it would be good to replace its first use with "Requesting Router (RR)". The 1st paragraph has the text of '... the Requesting Routers (RR) acting as the DHCPv6 Clients'. Tomek - Section 1. First paragraph on page 4. "Bulk Leasequery [RFC5460] specifies a mechanism for bulk transfer of the binding data of each delegated prefix from the server to the requestor (i.e., a DHCPv6 relay agent)". While requestor is typically the relay agent, it doesn't have to be. It may be a separate entity as well. I would replace "i.e." with "typically". 3. Accepted. The text will turn to be '..., typically a DHCPv6 relay agent,...'. Tomek - Section 1, the last paragraph. "The automatic mechanisms described in this document depends". It should be "mechanism depends" or "mechanisms depend". 4. Thanks for your carefulness. Accepted. Tomek - Section 2, Requestor definition. RFC5007 defines requestor as a note that sends leasequery messages. While it is typically a router, it doesn't have to be one. Requestor may be a separate tool that can be run on hosts or routers alike. 5. Accepted. The text will turn to be ' Requestor: A node defined in [RFC5007] that acts as the leasequery client. ' Tomek - Section 4. ipv6-prefix should be of variable length. In most cases the prefix used here will be /56 or even shorter. That will result in at least 9 bytes being zeros. BTW This approach will be recommended in the next version of draft-ietf-dhc-option-guidelines. 6. Accepted. The text will turn to be as follows: 'option-length: 2 + length of ipv6-prefix (in Octets) pfx-pool-len: Length for the prefix pool in bits ... ipv6-prefix: IPv6 prefix of the prefix pool, which is up to 16 octets in length. Bits outsides of the pfx-pool-len, if included, MUST be zero.' Tomek - Section 4. It is customary to include list of messages that MAY/MUST NOT include that option. Something like "Server MAY include this option in RELAY-REPL if relay included OPTION_PREFIX_POOL in ORO option in RELAY-FORW. It MUST NOT appear in any messages sent by clients. It MAY/MUST NOT appear in LEASEQUERY message.". 7. Accepted. The text will turn to be ' DHCPv6 server MAY include this option in the RELAY-FORW (12), RELAY-REPL (13), LEASEQUERY-REPLY (15) and LEASEQUERY-DATA (17) message. ' Tomek - Section 4. "If the administrative policy on the server does not permit to support route aggregation on the DHCPv6 relay agent, the status of the prefix pool will always be 'Released'." Wouldn't it be better to just not include OPTION_PREFIX_POOL? The server needs include OPTION_PREFIX_POOL per the request in ORO from the relay to withdraw the aggregation route. Tomek - Section 5, second paragraph. "The relay agent should include the Interface ID option". Is this normative language? I think it is, so it should be "SHOULD". Same as the one above. Accepted. Tomek - Section 5. Consider the following scenario: There are X requesting routers behind a relay. Server is configured to allow route aggregation, so pool option is sent. Then administrator decides to stop using aggregation, so he turns it off. When X+1 client comes in, the server does not send PREFIX_POOL anymore, so according to paragraph 4 in section 5, relay must withdraw the associated route. How are the first X clients reachable? I suppose the relay must keep routes to them anyway and the one received in PREFIX_POOL is an additional one, not a replacement, right? a. When X+1 client comes in, the server still send OPTION_PREFIX_POOL per the ORO from the reply to withdraw the aggregation route. If the relay lose the message from the server by accident, then it could use the 'aging' (self-healing) mechanism to withdraw the aggregation route. b. The first X clients are still reachable per the PD process, because the PE router still have the specified route for each active PD customer prefix. c. Yes, the aggregation route per the OPTION_PREFIX_POOL is the additional route entry in the routing table of the PE router. Tomek - Section 6, paragraph 2. "After receiving the Option Request option (OPTION_ORO, 6) requesting the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay- forward messages of the PD". What does PD mean in this context? I think you meant "relay-forward messages that encapsulate messages with IA_PD options". It's awfully lot of words, but I'm not sure how to say it simpler. 8 . PD means DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633]. It is definitely my fault that you can't read it. How about to change the text to be '... in the relay-forward messages of the DHCPv6-PD'. Accepted. Tomek - Section 6, paragraph 6. "When the administrator of the server changes the setting not to support route aggregation on the relay agent for the particular prefix pool, the status of the prefix pool may change from 'Active' to be 'Released' if at least one delegated prefix within the prefix pool has the valid lease.". I think once administrator disables it, the server should always set status to released. The "if at least one..." part in not necessary. The original text has the meaning that when the sever is set to support the route aggregation on the relay, the status of the prefix pool is 'Active' if at least one delegated prefix within the prefix pool has the valid lease.' Right? Tomek - Section 6, paragraph 6. Why does the server have to send RECONFIGURE? So the relay can re-learn RR prefixes once aggregation has been disabled? It is related to my question about RR remembering (or not) the specific routes. Anyway, it would be less intrusive to say that relay must use leasequery to learn existing delegations than forcing all clients to do reconfigure, especially that for clients nothing will change. Also, keep in mind that RRs may not support reconfigure as it is an optional feature. a. The server send the RECONFIGURE when the status of the prefix pool changed after the administrator's setting. Yes, the relay get the chance to re-learn the status of the prefix pool. b. The RR does not have to be renumbered. c. RECONFIGURE sounds 1 of 3 main configuration processes defined both in RFC3315/3633. If the RR may not support to immediately response RECONFIGURE (though I can't image it), we still can rely on the regular RENEW, right? Tomek - Section 7. Security consideration should also reference section 15 of RFC3633. 9 . Accepted. The text will turn to be 'Security issues related DHCPv6 are described in section 23 of [RFC3315] and section 15 of [RFC3633].' Tomek - Questions: 1. Let's assume the PE router announces 2001:db8:1::/48 prefix that is split into /56 prefixes. Someone tries to reach a customer that is currently offline. What is PE supposed to do with those packets? Respond with ICMP type=1 code=0 (no route to destination)? PE router will act as the same as the usual after the packet arrive it when the customer network is unreachable. Tomek - Questions: 2. PE has a 2001:db8:1::/48 prefix and there are 2 prefixes delegated to clients: 2001:db8:1:8000::/64 and 2001:db8:1:8001::/64. The admnistrative policy does not allow route aggregation, so OPTION_PREFIX_POOL has status set to release. Is PE allowed to aggregate both routes anyway and announce 2001:db8:1:8000::/63? Perhaps allowing such behaviour could be defined as status code = 2. I don't know if controlling this is a good idea, so feel free to ignore this suggestion. If administrative policy does not allow route aggregation, the PE router will act as the same as the usual. It will announce 2001:db8:1:8000::/63 in this case if the routing protocol is enabled on its network-facing interface. I don't believe we need more status code here. The other of your comments will be replied soon. Best Regards, Leaf -----Original Message----- From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com] Sent: Saturday, August 25, 2012 2:26 AM To: dhcwg Cc: Leaf yeh Subject: Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 On 30.07.2012 03:35, Leaf yeh wrote: > Dear DHC folks, > > The draft (ver.-08) & the proposed (OPTION_PREFIX_POOL) on the agenda > of IETF84 DHC session > (https://datatracker.ietf.org/meeting/84/agenda/dhc/ ), is waiting for > your review and comments. Hi, You've asked for it, so here are my comments. Although there are many things mentioned below, I think the draft is a good idea. It is in a good shape and I support it. None of the things mentioned below are show-stoppers, and most can be easily fixed. I will send out separate mail to respond to adoption call. Generic comments: - Multiple prefix pools seem to be allowed (section 6, paragraph 7 suggests that). It may be useful to note that multiple prefix pools must not overlap. - There are many normative looking words (must, shall etc.) that are not capitalized. - Have you considered defining new leasequery query type: QUERY_BY_PREFIX_POOL? Server could return all leases that belong to specified prefix pool. I think it would be easier to implement one new query type than modifying the code for existing 3 query types. - Since your option affects how existing query types in leasequery work, the front page of the draft should have "updates RFC5007, 5460 (if approved)" clause. - I think I have commented on this before, but I can't find it anywhere, so I'll restate my concerns again. This is basically a signalling protocol on top of normal exchange. In its current form it allows server to make strange things like make the pool active when responding to RELEASE or saying that the pool is released when assigning a prefix in response to REQUEST. - That draft was written in BBF networks in mind, but it can be used in a general case as well. A statement to point that out should be added. Comments specific to the text: - Section 1: This is really a nit-pick style comment "The DHCPv6 protocol". I always have problem how to write it. Adding protocol after DHCP is redundant, as P in DHCP stands for protocol. On the other hand, removing "protocol" would make it less readable by people who don't know what DHCP acronym stands for. I think it probably should stay as it is. - Section 1, second paragraph. You mentiond RRs without defining that acronym. Although it is later explained in section 2, it would be good to replace its first use with "Requesting Router (RR)". - Section 1. First paragraph on page 4. "Bulk Leasequery [RFC5460] specifies a mechanism for bulk transfer of the binding data of each delegated prefix from the server to the requestor (i.e., a DHCPv6 relay agent)". While requestor is typically the relay agent, it doesn't have to be. It may be a separate entity as well. I would replace "i.e." with "typically". - Section 1, the last paragraph. "The automatic mechanisms described in this document depends". It should be "mechanism depends" or "mechanisms depend". - Section 2, Requestor definition. RFC5007 defines requestor as a note that sends leasequery messages. While it is typically a router, it doesn't have to be one. Requestor may be a separate tool that can be run on hosts or routers alike. - Section 4. ipv6-prefix should be of variable length. In most cases the prefix used here will be /56 or even shorter. That will result in at least 9 bytes being zeros. BTW This approach will be recommended in the next version of draft-ietf-dhc-option-guidelines. - Section 4. It is customary to include list of messages that MAY/MUST NOT include that option. Something like "Server MAY include this option in RELAY-REPL if relay included OPTION_PREFIX_POOL in ORO option in RELAY-FORW. It MUST NOT appear in any messages sent by clients. It MAY/MUST NOT appear in LEASEQUERY message.". - Section 4. "If the administrative policy on the server does not permit to support route aggregation on the DHCPv6 relay agent, the status of the prefix pool will always be 'Released'." Wouldn't it be better to just not include OPTION_PREFIX_POOL? - Section 5, second paragraph. "The relay agent should include the Interface ID option". Is this normative language? I think it is, so it should be "SHOULD". - Section 5. Consider the following scenario: There are X requesting routers behind a relay. Server is configured to allow route aggregation, so pool option is sent. Then administrator decides to stop using aggregation, so he turns it off. When X+1 client comes in, the server does not send PREFIX_POOL anymore, so according to paragraph 4 in section 5, relay must withdraw the associated route. How are the first X clients reachable? I suppose the relay must keep routes to them anyway and the one received in PREFIX_POOL is an additional one, not a replacement, right? - Section 5. The last paragraph about leasequery should probably be moved to a separate section "Leasequery requestor behavior". - Section 6, paragraph 2. "After receiving the Option Request option (OPTION_ORO, 6) requesting the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay- forward messages of the PD". What does PD mean in this context? I think you meant "relay-forward messages that encapsulate messages with IA_PD options". It's awfully lot of words, but I'm not sure how to say it simpler. - Section 6, paragraph 6. "When the administrator of the server changes the setting not to support route aggregation on the relay agent for the particular prefix pool, the status of the prefix pool may change from 'Active' to be 'Released' if at least one delegated prefix within the prefix pool has the valid lease.". I think once administrator disables it, the server should always set status to released. The "if at least one..." part in not necessary. - Section 6, paragraph 6. Why does the server have to send RECONFIGURE? So the relay can re-learn RR prefixes once aggregation has been disabled? It is related to my question about RR remembering (or not) the specific routes. Anyway, it would be less intrusive to say that relay must use leasequery to learn existing delegations than forcing all clients to do reconfigure, especially that for clients nothing will change. Also, keep in mind that RRs may not support reconfigure as it is an optional feature. - Section 6, last 2 paragraphs. I would move discussion about leasequery to a separate sub-section. - Section 6, last paragraph. Why repeating prefix pool in every client-data option? It will all contain the same value. It would be more reasonable to send it back only one or even not send it at all if requestor sent prefix pool option. If requestor did that, are there any cases where server could send back the prefix pool option with different values than the requestor asked for? I don't think so. - Section 7. Security consideration should also reference section 15 of RFC3633. Questions: 1. Let's assume the PE router announces 2001:db8:1::/48 prefix that is split into /56 prefixes. Someone tries to reach a customer that is currently offline. What is PE supposed to do with those packets? Respond with ICMP type=1 code=0 (no route to destination)? 2. PE has a 2001:db8:1::/48 prefix and there are 2 prefixes delegated to clients: 2001:db8:1:8000::/64 and 2001:db8:1:8001::/64. The admnistrative policy does not allow route aggregation, so OPTION_PREFIX_POOL has status set to release. Is PE allowed to aggregate both routes anyway and announce 2001:db8:1:8000::/63? Perhaps allowing such behaviour could be defined as status code = 2. I don't know if controlling this is a good idea, so feel free to ignore this suggestion. Ok, that's it. Sorry for sending such long and boring mail. I hope you find at least some of those comments useful. Again, despite numerous comments, I really support it. Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From akostur@incognito.com Tue Aug 28 09:39:38 2012 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 ACCE221F859C for ; Tue, 28 Aug 2012 09:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeYbYHOQ+1NV for ; Tue, 28 Aug 2012 09:39:38 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with SMTP id 76F7C21F8598 for ; Tue, 28 Aug 2012 09:39:33 -0700 (PDT) Received: from mail-iy0-f178.google.com ([209.85.210.178]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKUDz0RbUeoWrauBp5BHezd1LBiuaJcoAj@postini.com; Tue, 28 Aug 2012 09:39:33 PDT Received: by iaeh11 with SMTP id h11so13943231iae.23 for ; Tue, 28 Aug 2012 09:39:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=+NvuAyI2U0agCc0vdVxuzm043EFpxXo2OoZL/6KyZds=; b=V/y3HYWBh9YUwqC5dn4j2AlzWs6WxXhEmjUSMiUDqrtDAzLd6Y/zXF1gJ3ZZpLkQpD i1yZE2iQ1WXkm62ejMr9077mOOIBF1N/R+kS0CAfdFmZFIR2D6cBkUKLHyOd8DGA3P7H h5dMKFzWO5Id28wQ2GVg3V8pUiMizVHm5p/1O1m7DwhZLvX1j7p6sJqKolmwZsJ8W5A+ GYiwCrZydNf8gveaIooODC/R1z/MhAG8QYzGqlDWXZpPGHi2vX/hQnpsAO/MjfZkcTUR DYGLHCBqdzbDkKsrS70v+TYEjcoIquVQJzPM4qxHfp61KdE11EI8u4FswSVehIY+HeVF yx7w== MIME-Version: 1.0 Received: by 10.43.117.129 with SMTP id fm1mr7160277icc.1.1346171972766; Tue, 28 Aug 2012 09:39:32 -0700 (PDT) Received: by 10.64.63.169 with HTTP; Tue, 28 Aug 2012 09:39:32 -0700 (PDT) Date: Tue, 28 Aug 2012 09:39:32 -0700 Message-ID: From: Andre Kostur To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm3mfifm+63zXuKPDu9jzEztCYQoWWZr1rtS22pxDG6+pPxl2kakY6WXJd6me6wbuL0kqqS Subject: [dhcwg] Load Balancing for DHCPv6 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, 28 Aug 2012 16:39:38 -0000 Dear all: I have submitted a new I-D updating RFC 3074 to apply to DHCPv6. The text is available at: http://www.ietf.org/internet-drafts/draft-kostur-dhc-loadbv6-00.txt Comments and suggestions welcome. I am looking to have the WG take this on as a work item. -- Andre Kostur From volz@cisco.com Tue Aug 28 22:10:32 2012 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 9D82611E809C for ; Tue, 28 Aug 2012 22:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cma0T4lVd1uu for ; Tue, 28 Aug 2012 22:10:31 -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 BD1A611E8097 for ; Tue, 28 Aug 2012 22:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1080; q=dns/txt; s=iport; t=1346217026; x=1347426626; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rP+S/bE1NL90ZdvsJQ9+xY/kG4qUoQWpMnfWiRjPgpY=; b=l7zJgj3/Tx9uYGdxZHrhWBELPLpeHyDm/gLpX+EID1/ksm1YMue1yx2N qfIb3V56Zxv+/MBOttpaEdUZR2aRe3p2AaYTofSyWHK1rNR13sr8n+zGQ SOW9jce7mc3+x32LA1TSSsXOYH48rIHki0Lt+1MWMDzlS7e1E/BMCJSXj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKyiPVCtJXHB/2dsb2JhbABFun6BB4IgAQEBBAEBAQ8BJzQXBAIBCA4DBAEBCxQJBycLFAkIAgQBEggBGYdrC5wJoE6LCIV5YAOkBIFngmM X-IronPort-AV: E=Sophos;i="4.80,332,1344211200"; d="scan'208";a="113251202" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 29 Aug 2012 05:10:26 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7T5APYJ016083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Aug 2012 05:10:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Wed, 29 Aug 2012 00:10:25 -0500 From: "Bernie Volz (volz)" To: Andre Kostur , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNhTu/UoFdx/X410eNxzRZgWx7TpdwPQBQ Date: Wed, 29 Aug 2012 05:10:24 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@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.89.13.162] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19146.004 x-tm-as-result: No--31.658900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] Load Balancing for DHCPv6 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, 29 Aug 2012 05:10:32 -0000 Looks fine to me ... you beat me to doing this draft. One thought I had, especially regarding the DUID-UUID, was to drop the firs= t two octets (DUID-Type) from the hashing as that allows coverage of the fu= ll UUID. Also, the DUID-Type field hardly seems worth hashing - as there's = unlikely to be much, if any, variability in that data (at best the values w= ould be 00-01, 00-02, 00-03, or 00-04 today). - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of A= ndre Kostur Sent: Tuesday, August 28, 2012 12:40 PM To: dhcwg@ietf.org Subject: [dhcwg] Load Balancing for DHCPv6 Dear all: I have submitted a new I-D updating RFC 3074 to apply to DHCPv6. The text is available at: http://www.ietf.org/internet-drafts/draft-kostur-dhc-loadbv6-00.txt Comments and suggestions welcome. I am looking to have the WG take this on as a work item. -- Andre Kostur _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From akostur@incognito.com Wed Aug 29 07:53:16 2012 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 93CDC21F867B for ; Wed, 29 Aug 2012 07:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iegBHo8qZLvz for ; Wed, 29 Aug 2012 07:53:14 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id 44BA021F867A for ; Wed, 29 Aug 2012 07:53:13 -0700 (PDT) Received: from mail-qc0-f172.google.com ([209.85.216.172]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKUD4s2bhu//T8cRUlSaDK0syCKvbarBua@postini.com; Wed, 29 Aug 2012 07:53:14 PDT Received: by qcac10 with SMTP id c10so488111qca.31 for ; Wed, 29 Aug 2012 07:53:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=iJPlmXADKSKyedW/LbUieXsvjGX1nf6lyRuMrbHua88=; b=R+PBNO3R1Pr2XtEmEy9X01q17gxBW+XLlp1HB+20g2amt+d5gJVPcMLUW2k5QzLTiY QpAUTtiNTer/lZiH3TyA6po64nQG53FB9FvuamOOaMZCyu3+zhpCBAuX29kf0xejpj6V ZxAVIQhHFavnoeIxDfr96ilt5nSwBo+9DoBl6VOweEImKK85w31rdXd60+ILEeoZ2UTr 80GxsCoBNun/gMKFwjt+gDHcz48ZyYzYJZIlIIuKaLgZ7niWtLTXPSc2dFd55db8jF/i HnSAgqwYDPigIMBPW8TiUBwq32FP2qHszJyj0Y6Kj0tD+Ms/2KL/sM200xwwDXilfHUb DQrw== MIME-Version: 1.0 Received: by 10.224.214.67 with SMTP id gz3mr4065108qab.70.1346251992807; Wed, 29 Aug 2012 07:53:12 -0700 (PDT) Received: by 10.229.32.4 with HTTP; Wed, 29 Aug 2012 07:53:12 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> Date: Wed, 29 Aug 2012 07:53:12 -0700 Message-ID: From: Andre Kostur To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=20cf300fb319cf394704c868b777 X-Gm-Message-State: ALoCoQk2hmRkL0K9uwY5Dzgk143VR1DPQOCdRdug6h4eOpJdF3GFNSYOQ67oPG/is4pBw0pfsZ0W Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Load Balancing for DHCPv6 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, 29 Aug 2012 14:53:16 -0000 --20cf300fb319cf394704c868b777 Content-Type: text/plain; charset=ISO-8859-1 Regarding DUIDs, what I do wonder about is DUID-EN. How many devices out there actually use it (I have not encountered any as yet), and if they do, how variable are the first 10-12 bytes of the data that the vendor is choosing? We could still skip the DUID type, but the enterprise ID will stil have some variability across the entire population (I suppose unless the DHCP servers are deployed in an entirely homogenous network). On Tue, Aug 28, 2012 at 10:10 PM, Bernie Volz (volz) wrote: > Looks fine to me ... you beat me to doing this draft. > > One thought I had, especially regarding the DUID-UUID, was to drop the > first two octets (DUID-Type) from the hashing as that allows coverage of > the full UUID. Also, the DUID-Type field hardly seems worth hashing - as > there's unlikely to be much, if any, variability in that data (at best the > values would be 00-01, 00-02, 00-03, or 00-04 today). > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Andre Kostur > Sent: Tuesday, August 28, 2012 12:40 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Load Balancing for DHCPv6 > > Dear all: > > I have submitted a new I-D updating RFC 3074 to apply to DHCPv6. > > The text is available at: > http://www.ietf.org/internet-drafts/draft-kostur-dhc-loadbv6-00.txt > > Comments and suggestions welcome. I am looking to have the WG take > this on as a work item. > > -- > Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- *Andre Kostur* Senior Product Design Engineer *P:* 604-678-2864 *E:* akostur@incognito.com *Toll-Free:* 1-800-877-1856 *F:* 604-678-2864 *VoIP:* sip:864@sip.incognito.com [image: Incognito Software Inc.] --20cf300fb319cf394704c868b777 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Regarding DUIDs, what I do wonder about is DUID-EN. =A0How= many devices out there actually use it (I have not encountered any as yet)= , and if they do, how variable are the first 10-12 bytes of the data that t= he vendor is choosing? =A0 We could still skip the DUID type, but the enter= prise ID will stil have some variability across the entire population (I su= ppose unless the DHCP servers are deployed in an entirely homogenous networ= k).


On Tue, Aug 28, 2012 at 10:10 PM, Bernie= Volz (volz) <volz@cisco.com> wrote:
Looks fine to me ... you beat me to doing this draft.

One thought I had, especially regarding the DUID-UUID, was to drop the firs= t two octets (DUID-Type) from the hashing as that allows coverage of the fu= ll UUID. Also, the DUID-Type field hardly seems worth hashing - as there= 9;s unlikely to be much, if any, variability in that data (at best the valu= es would be 00-01, 00-02, 00-03, or 00-04 today).

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org] On Behalf Of Andre Kostur
Sent: Tuesday, August 28, 2012 12:40 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Load Balancing for DHCPv6

Dear all:

I have submitted a new I-D updating RFC 3074 to apply to DHCPv6.

The text is available at:
http://www.ietf.org/internet-drafts/draft-kostur-dhc= -loadbv6-00.txt

Comments and suggestions welcome. =A0 I am looking to have the WG take
this on as a work item.

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



--
Andre Kostur =
Senior Product Design Engineer
P: 604-678-2864
E: akostur@incognito.com
Toll-Free: 1-800= -877-1856

F: 604-678-2864
VoIP: = sip:864@sip.incognito.com

3D"Incognito


--20cf300fb319cf394704c868b777-- From Ted.Lemon@nominum.com Wed Aug 29 08:19:48 2012 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 8F0E521F86DC for ; Wed, 29 Aug 2012 08:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVQXC024gSvo for ; Wed, 29 Aug 2012 08:19:48 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C33F521F86DA for ; Wed, 29 Aug 2012 08:19:47 -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 DSNKUD4zE9mkhAhHUJHty0SCg/sHdthYWUKE@postini.com; Wed, 29 Aug 2012 08:19: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 9BE08128005 for ; Wed, 29 Aug 2012 08:19:46 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 93481190060; Wed, 29 Aug 2012 08:19: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.02.0247.003; Wed, 29 Aug 2012 08:19:46 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNhTu7gFlX/ZntC0OFRh8xVQ/AAZdwtBEAgACi1QCAAAcoAA== Date: Wed, 29 Aug 2012 15:19:45 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.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: multipart/alternative; boundary="_000_DF93BDD1BBB94607995CC6244C56A5A5nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Load Balancing for DHCPv6 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, 29 Aug 2012 15:19:48 -0000 --_000_DF93BDD1BBB94607995CC6244C56A5A5nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Aug 29, 2012, at 7:53 AM, Andre Kostur > wrote: Regarding DUIDs, what I do wonder about is DUID-EN. How many devices out t= here actually use it (I have not encountered any as yet), and if they do, h= ow variable are the first 10-12 bytes of the data that the vendor is choosi= ng? We could still skip the DUID type, but the enterprise ID will stil ha= ve some variability across the entire population (I suppose unless the DHCP= servers are deployed in an entirely homogenous network). We're likely only getting one bit out of this hash, so I don't think this i= s really an issue=97a pair of plaintexts that match in the first 12 bytes a= nd differ in the last two will still be likely to produce a different resul= t, just as if the plaintext were only two bytes. --_000_DF93BDD1BBB94607995CC6244C56A5A5nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8FCF7EF26C7493479DFF8E9EE1EFFBCA@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 29, 2012, at 7:53 AM, Andre Kostur <akostur@incognito.com> wrote:
Regarding DUIDs, what I do wonder about is DUID-EN.  How many devices out there= actually use it (I have not encountered any as yet), and if they do, how v= ariable are the first 10-12 bytes of the data that the vendor is choosing? =   We could still skip the DUID type, but the enterprise ID will stil have some variability across the entire po= pulation (I suppose unless the DHCP servers are deployed in an entirely hom= ogenous network).

We're likely only getting one bit out of this hash, so I don't think t= his is really an issue=97a pair of plaintexts that match in the first 12 by= tes and differ in the last two will still be likely to produce a different = result, just as if the plaintext were only two bytes.

--_000_DF93BDD1BBB94607995CC6244C56A5A5nominumcom_-- From Ted.Lemon@nominum.com Wed Aug 29 08:19:49 2012 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 2323321F86DA for ; Wed, 29 Aug 2012 08:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxwUg2HJIyF9 for ; Wed, 29 Aug 2012 08:19:48 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1059A21F86DB for ; Wed, 29 Aug 2012 08:19:48 -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 DSNKUD4zE9mkhAhHUJHty0SCg/sHdthYWUKE@postini.com; Wed, 29 Aug 2012 08:19: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 82B5E108002 for ; Wed, 29 Aug 2012 08:19:46 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 76D2419005C; Wed, 29 Aug 2012 08:19: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.02.0247.003; Wed, 29 Aug 2012 08:19:46 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNhTu7gFlX/ZntC0OFRh8xVQ/AAZdwtBEAgACpJYA= Date: Wed, 29 Aug 2012 15:19:45 +0000 Message-ID: <68B364DA-5566-41B1-B275-92D3D0834459@nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@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: multipart/alternative; boundary="_000_68B364DA556641B1B27592D3D0834459nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] Load Balancing for DHCPv6 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, 29 Aug 2012 15:19:49 -0000 --_000_68B364DA556641B1B27592D3D0834459nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Aug 28, 2012, at 10:10 PM, Bernie Volz (volz) > wrote: One thought I had, especially regarding the DUID-UUID, was to drop the firs= t two octets (DUID-Type) from the hashing as that allows coverage of the fu= ll UUID. Also, the DUID-Type field hardly seems worth hashing - as there's = unlikely to be much, if any, variability in that data (at best the values w= ould be 00-01, 00-02, 00-03, or 00-04 today). In principle, hashing the DUID type would distinguish between two DUIDs tha= t only differed by type. But I agree with you that it's not likely to be = important=97this is just a hash. --_000_68B364DA556641B1B27592D3D0834459nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 28, 2012, at 10:10 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
One thought I had, especially regarding the DUID-UUID, was to drop the first t= wo octets (DUID-Type) from the hashing as that allows coverage of the full = UUID. Also, the DUID-Type field hardly seems worth hashing - as there's unl= ikely to be much, if any, variability in that data (at best the values would be 00-01, 00-02, 00-03, or 00-04 to= day).

In principle, hashing the DUID type would distinguish between two DUID= s that only differed by type.   But I agree with you that it's not lik= ely to be important=97this is just a hash.

--_000_68B364DA556641B1B27592D3D0834459nominumcom_-- From bs7652@att.com Wed Aug 29 09:45:34 2012 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 C220421F86BE for ; Wed, 29 Aug 2012 09:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EymytQCYuFz7 for ; Wed, 29 Aug 2012 09:45:34 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 21FA921F86BB for ; Wed, 29 Aug 2012 09:45:34 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id e274e305.2aaaec439940.957396.00-583.2666839.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 29 Aug 2012 16:45:34 +0000 (UTC) X-MXL-Hash: 503e472e2dedfda7-df3d80ffd3f58374af4103c8d1cfaada3dd785dd Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id b274e305.0.957383.00-277.2666786.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 29 Aug 2012 16:45:32 +0000 (UTC) X-MXL-Hash: 503e472c7377904b-0ad47f5681e35d8600f1d74d54e0618b01c0c84f Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7TGjUDu008961; Wed, 29 Aug 2012 12:45:31 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7TGjLWk008884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 12:45:26 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint03.pst.cso.att.com (RSA Interceptor); Wed, 29 Aug 2012 12:45:08 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0318.001; Wed, 29 Aug 2012 12:45:08 -0400 From: "STARK, BARBARA H" To: Andre Kostur , "Bernie Volz (volz)" Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNhT5EiI+5/y90ykuhIHu+/3QPD5dwgcIAgACi1QD//9qJsA== Date: Wed, 29 Aug 2012 16:45:07 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.175.102] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=FsSYsVXGSqEA:10 a=QS7FF5Nt4JQA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=MwPsRqSNKFcA:1] X-AnalysisOut: [0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=mYPrF8hoAAAA:8 a=l0U4ng9] X-AnalysisOut: [AP9zcZbsDY-oA:9 a=wPNLvfGTeEIA:10] Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Load Balancing for DHCPv6 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, 29 Aug 2012 16:45:34 -0000 > Regarding DUIDs, what I do wonder about is DUID-EN. =A0How many devices o= ut there actually use it=20 > (I have not encountered any as yet), and if they do, how variable are the= first 10-12 bytes of the data=20 > that the vendor is choosing? =A0 We could still skip the DUID type, but t= he enterprise ID will stil have some > variability across the entire population (I suppose unless the DHCP serve= rs are deployed in an entirely homogenous network). Broadband Forum requires use of DUID-EN for "Residential Gateways" that wis= h to meet its TR-124 specification. http://www.broadband-forum.org/technical/download/TR-124_Issue-3.pdf Barbara From akostur@incognito.com Wed Aug 29 09:57:47 2012 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 EBEBD21F8595 for ; Wed, 29 Aug 2012 09:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9hKSiYl8x66 for ; Wed, 29 Aug 2012 09:57:47 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id EA58721F84D8 for ; Wed, 29 Aug 2012 09:57:46 -0700 (PDT) Received: from mail-iy0-f172.google.com ([209.85.210.172]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKUD5KCqOs0g8scvmXt+ow1VQ7ROTLnd5e@postini.com; Wed, 29 Aug 2012 09:57:47 PDT Received: by iabz21 with SMTP id z21so1703003iab.31 for ; Wed, 29 Aug 2012 09:57:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+8gNNKO4hraXg+SkcH0fQyovO2rahwdchvxDdrTnBc4=; b=lxv1IWy8Cr85+WAJSgaNNsjxi7jUAy3v1d/XBToZmrdJhlO56+/065HrM1ATeXqNlI 4m+yXOVmVuLUt3rN/AtfMizY+nQwJOx4DxpJVWN/7o1PhKlNTv/QLjxNJiujNFgxeZOD zicV2pRUfQ1DMv6R3/MWBzyrZ22abr3xcVw/ozAM3VMCgw0AHi3pOkE+CZ9jcq3/mBqg dWvyxPf38+UiPDCYgEYYC49FuGmFmlePBUJqOHryJa37OVIXF6W8K/EJ9l9iWG6gz7+I 5qp3RP216FlSXCiUcWGHFP/aMzF1LT05TaGrolPIepyS4c1ntePaGWMKRv7MBasGeJOZ ZmUw== MIME-Version: 1.0 Received: by 10.50.156.133 with SMTP id we5mr17965938igb.62.1346259466070; Wed, 29 Aug 2012 09:57:46 -0700 (PDT) Received: by 10.64.63.169 with HTTP; Wed, 29 Aug 2012 09:57:46 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Wed, 29 Aug 2012 09:57:46 -0700 Message-ID: From: Andre Kostur To: "STARK, BARBARA H" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnwU5E4kV1TkfM3RmtucS+l08KI0L0dtg7nRIM+9NAqzrOu3vW6JnkgR865C2XJfPppXe08 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Load Balancing for DHCPv6 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, 29 Aug 2012 16:57:48 -0000 On Wed, Aug 29, 2012 at 9:45 AM, STARK, BARBARA H wrote: > Broadband Forum requires use of DUID-EN for "Residential Gateways" that wish to meet its TR-124 specification. > http://www.broadband-forum.org/technical/download/TR-124_Issue-3.pdf Say, this discussion is happening because of the 16-byte limitation. Does anybody recall why the original load balancing had the 16 byte restriction? -- Andre Kostur From Ted.Lemon@nominum.com Wed Aug 29 10:02:44 2012 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 B459921F84BF for ; Wed, 29 Aug 2012 10:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi-0-j1SKOjV for ; Wed, 29 Aug 2012 10:02:44 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id D473F21F84B2 for ; Wed, 29 Aug 2012 10:02:43 -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 DSNKUD5LMyDkkHSKeQxFfMCfUQejNS9/S7nv@postini.com; Wed, 29 Aug 2012 10:02:43 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 B4DF81B82D0 for ; Wed, 29 Aug 2012 10:02:42 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 A4E7F19005C; Wed, 29 Aug 2012 10:02:42 -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.02.0247.003; Wed, 29 Aug 2012 10:02:42 -0700 From: Ted Lemon To: Andre Kostur Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNhTu7gFlX/ZntC0OFRh8xVQ/AAZdwtBEAgACi1QCAAB9FgIAAA4kAgAABYIA= Date: Wed, 29 Aug 2012 17:02:41 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.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: multipart/alternative; boundary="_000_CDDB9016BE11489A93610172D96A464Cnominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Load Balancing for DHCPv6 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, 29 Aug 2012 17:02:44 -0000 --_000_CDDB9016BE11489A93610172D96A464Cnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 29, 2012, at 9:57 AM, Andre Kostur > wrote: Does anybody recall why the original load balancing had the 16 byte restriction? Nope. It might be worth visiting the question of whether the hash algorit= hm is the right one. --_000_CDDB9016BE11489A93610172D96A464Cnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <57513E79D6E809479164E4307A333AA3@nominum.com> Content-Transfer-Encoding: quoted-printable
On Aug 29, 2012, at 9:57 AM, Andre Kostur <akostur@incognito.com> wrote:
Does anybody recall why the original load balancing had the 16 byte
restriction?

Nope.   It might be worth visiting the question of whether the ha= sh algorithm is the right one.

--_000_CDDB9016BE11489A93610172D96A464Cnominumcom_-- From volz@cisco.com Wed Aug 29 10:11:37 2012 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 95C4F21F857A for ; Wed, 29 Aug 2012 10:11:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca+5hYEF0diN for ; Wed, 29 Aug 2012 10:11: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 A19F621F8578 for ; Wed, 29 Aug 2012 10:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=5433; q=dns/txt; s=iport; t=1346260296; x=1347469896; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=VKC9YCP1PY6DutP73O3Dg52hte8oc1rLCQ6L7koU+uY=; b=kJhyEKO2GadLnupviuXUVRpciCCCcNqm7ic4IXkjEc/eVFUMkuDpnXd8 qH2+UpyIlzL6fPh1xv4Bq2QT/h3/aiA/06bI5Y9XhJYJWYZ1B1JtmxY7T T0qXZeEbMHTgRs5vqvmvSwwagvhklpArKuS0DIUbg9jwYnnDwjQkC2N5E 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAVNPlCtJXG8/2dsb2JhbABFgkq4KYEHgiABAgQSAWYSAQgRAwECKDkUCQgCBAENBSKHa5tMoDWLCBQBhkQDlVaOLoFngmOBWAE X-IronPort-AV: E=Sophos;i="4.80,335,1344211200"; d="scan'208,217";a="116473957" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 29 Aug 2012 17:11:36 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7THBan8008119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Aug 2012 17:11:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Wed, 29 Aug 2012 12:11:35 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Andre Kostur Thread-Topic: [dhcwg] Load Balancing for DHCPv6 Thread-Index: AQHNhTu/UoFdx/X410eNxzRZgWx7TpdwPQBQgAD4XwCAAB9FgIAAA4kAgAABYID//79rAA== Date: Wed, 29 Aug 2012 17:11:34 +0000 Message-ID: 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: [161.44.65.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19146.006 x-tm-as-result: No--24.853000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC63C4E41BF7volzciscocom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Load Balancing for DHCPv6 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, 29 Aug 2012 17:11:37 -0000 --_000_CC63C4E41BF7volzciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the reason for the limit was: * Most v4 identifiers were short * Longer identifiers incur more processing cost (though that is likely = a minor issue) * As Ted has pointed out, it is likely only 1 or perhaps 2 bits that en= d up being 'useful' But, I do agree that the best is just to remove this restriction in the new= v6 draft and say that the entire DUID is hashed (the DUID is limited to 12= 8 bytes but hopefully few, if any, use anything that long). - Bernie From: Ted Lemon > Date: Wednesday, August 29, 2012 1:02 PM To: Andre Kostur > Cc: "STARK, BARBARA H" >, "dhcwg@ietf= .org" >, Cisco= Employee > Subject: Re: [dhcwg] Load Balancing for DHCPv6 On Aug 29, 2012, at 9:57 AM, Andre Kostur > wrote: Does anybody recall why the original load balancing had the 16 byte restriction? Nope. It might be worth visiting the question of whether the hash algorit= hm is the right one. --_000_CC63C4E41BF7volzciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <84A3840B19BB0D418EBF255B73E29234@cisco.com> Content-Transfer-Encoding: quoted-printable
I think the reason for the limit was:
  • Most v4 identifiers were short
  • Longer identifiers incur more pr= ocessing cost (though that is likely a minor issue)
  • As Ted has poin= ted out, it is likely only 1 or perhaps 2 bits that end up being 'useful'
But, I do agree that the best is just to remove this restriction in th= e new v6 draft and say that the entire DUID is hashed (the DUID is limited = to 128 bytes but hopefully few, if any, use anything that long).

- Bernie

From: Ted Lemon <Ted.Lemon@nominum.com>
Date: Wednesday, August 29, 2012 1:= 02 PM
To: Andre Kostur <akostur@incognito.com>
Cc: "STARK, BARBARA H" &l= t;bs7652@att.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, Cisco Employee <volz@cisco.com>
Subject: Re: [dhcwg] Load Balancing= for DHCPv6

On Aug 29, 2012, at 9:57 AM, Andre Kostur <akostur@incognito.com> wrote:
Does anybody recall why the original load balancing had the 16 byte
restriction?

Nope.   It might be worth visiting the question of whether the ha= sh algorithm is the right one.

 --_000_CC63C4E41BF7volzciscocom_-- From internet-drafts@ietf.org Wed Aug 29 20:17:41 2012 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 E5CC921E8045; Wed, 29 Aug 2012 20:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2IJ6MPXs3s2; Wed, 29 Aug 2012 20:17:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A13A21E8043; Wed, 29 Aug 2012 20:17:41 -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.34 Message-ID: <20120830031741.12899.30759.idtracker@ietfa.amsl.com> Date: Wed, 29 Aug 2012 20:17:41 -0700 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-host-gen-id-04.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, 30 Aug 2012 03:17: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 : Prefix Assignment in DHCPv6 Author(s) : Sheng Jiang Frank Xia Behcet Sarikaya Filename : draft-ietf-dhc-host-gen-id-04.txt Pages : 11 Date : 2012-08-29 Abstract: This document introduces a generic host-oriented prefix assignment mechanism using DHCPv6. In this new address configuration procedure, the prefix is assigned from a DHCPv6 server to hosts through DHCPv6 message exchanging while the interface identifiers are independently generated by the hosts. It enables both integral address assignment and self-generated addresses in one single mechanism, DHCPv6. It also enables stateless address configuration without RA attendance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-host-gen-id There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-host-gen-id-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-host-gen-id-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jiangsheng@huawei.com Wed Aug 29 20:25:50 2012 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 5F9AF21F84DA for ; Wed, 29 Aug 2012 20:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26lmgyheln4y for ; Wed, 29 Aug 2012 20:25:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CE88621F84C4 for ; Wed, 29 Aug 2012 20:25:48 -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.5-GA FastPath queued) with ESMTP id AKC02726; Thu, 30 Aug 2012 03:25:47 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 30 Aug 2012 04:25:17 +0100 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 30 Aug 2012 04:25:47 +0100 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.47]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Thu, 30 Aug 2012 11:25:42 +0800 From: Sheng Jiang To: "Bernie Volz (volz)" , Andre Kostur Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-host-gen-id-04.txt Thread-Index: AQHNhl4KGicgghMuQUGJgS33r3w9F5dxsO4A Date: Thu, 30 Aug 2012 03:25:42 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F26434@szxeml545-mbx.china.huawei.com> References: <20120830031741.12899.30759.idtracker@ietfa.amsl.com> In-Reply-To: <20120830031741.12899.30759.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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-host-gen-id-04.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, 30 Aug 2012 03:25:50 -0000 VGhlIGF1dGhvcnMgaGF2ZSB1cGRhdGVkIHRoaXMgZHJhZnQgYWNjb3JkaW5nIHRvIHRoZSBsYXRl c3QgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbCBsaXN0Lg0KDQpUaGUgYXV0aG9ycyBiZWxpZXZlIHRo YXQgYWxsIHJlY2VpdmVkIGNvbW1lbnRzIGhhdmUgYmVlbiBwcm9wZXJseSBhZGRyZXNzZWQgaW4g dGhpcyB2ZXJzaW9uLg0KDQpZb3VyIHJldmlldyBhbmQgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVk Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYNCj5PZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj5TZW50OiBU aHVyc2RheSwgQXVndXN0IDMwLCAyMDEyIDExOjE4IEFNDQo+VG86IGktZC1hbm5vdW5jZUBpZXRm Lm9yZw0KPkNjOiBkaGN3Z0BpZXRmLm9yZw0KPlN1YmplY3Q6IFtkaGN3Z10gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1kaGMtaG9zdC1nZW4taWQtMDQudHh0DQo+DQo+DQo+QSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVj dG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBEeW5hbWljIEhvc3Qg Q29uZmlndXJhdGlvbiBXb3JraW5nIEdyb3VwDQo+b2YgdGhlIElFVEYuDQo+DQo+CVRpdGxlICAg ICAgICAgICA6IFByZWZpeCBBc3NpZ25tZW50IGluIERIQ1B2Ng0KPglBdXRob3IocykgICAgICAg OiBTaGVuZyBKaWFuZw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgRnJhbmsgWGlhDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICBCZWhjZXQgU2FyaWtheWENCj4JRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1kaGMtaG9zdC1nZW4taWQtMDQudHh0DQo+CVBhZ2VzICAgICAgICAgICA6 IDExDQo+CURhdGUgICAgICAgICAgICA6IDIwMTItMDgtMjkNCj4NCj5BYnN0cmFjdDoNCj4gICBU aGlzIGRvY3VtZW50IGludHJvZHVjZXMgYSBnZW5lcmljIGhvc3Qtb3JpZW50ZWQgcHJlZml4IGFz c2lnbm1lbnQNCj4gICBtZWNoYW5pc20gdXNpbmcgREhDUHY2LiAgSW4gdGhpcyBuZXcgYWRkcmVz cyBjb25maWd1cmF0aW9uIHByb2NlZHVyZSwNCj4gICB0aGUgcHJlZml4IGlzIGFzc2lnbmVkIGZy b20gYSBESENQdjYgc2VydmVyIHRvIGhvc3RzIHRocm91Z2ggREhDUHY2DQo+ICAgbWVzc2FnZSBl eGNoYW5naW5nIHdoaWxlIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmllcnMgYXJlIGluZGVwZW5kZW50 bHkNCj4gICBnZW5lcmF0ZWQgYnkgdGhlIGhvc3RzLiAgSXQgZW5hYmxlcyBib3RoIGludGVncmFs IGFkZHJlc3MgYXNzaWdubWVudA0KPiAgIGFuZCBzZWxmLWdlbmVyYXRlZCBhZGRyZXNzZXMgaW4g b25lIHNpbmdsZSBtZWNoYW5pc20sIERIQ1B2Ni4gIEl0DQo+ICAgYWxzbyBlbmFibGVzIHN0YXRl bGVzcyBhZGRyZXNzIGNvbmZpZ3VyYXRpb24gd2l0aG91dCBSQSBhdHRlbmRhbmNlLg0KPg0KPg0K PlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGhjLWhvc3QtZ2VuLWlk DQo+DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtaG9zdC1nZW4taWQtMDQNCj4N Cj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kaGMtaG9zdC1nZW4taWQt MDQNCj4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmRoY3dnIG1haWxp bmcgbGlzdA0KPmRoY3dnQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kaGN3Zw0K