From nobody Tue Apr 1 07:23:01 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3091A079F for ; Tue, 1 Apr 2014 07:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZDZgR4oH7o3 for ; Tue, 1 Apr 2014 07:22:56 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id A77111A06DB for ; Tue, 1 Apr 2014 07:22:56 -0700 (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 61B7E1B83F3 for ; Tue, 1 Apr 2014 07:22:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 48C1E190043; Tue, 1 Apr 2014 07:22:53 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 07:22:46 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F544848AE@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 1 Apr 2014 10:22:43 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <657EBF08-AD6C-4E76-AF8B-DADF707B6720@nominum.com> References: <20140401074050.4622.92489.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F544848AE@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Vawlspr6EAQ_7_8vKU611Metyzk Cc: DHC WG , "draft-ietf-pcp-dhcp@tools.ietf.org" , "pcp-chairs@tools.ietf.org" Subject: Re: [dhcwg] New Version Notification - draft-ietf-pcp-dhcp-10.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:22:59 -0000 On Apr 1, 2014, at 3:47 AM, = wrote: > * the recommendations from the dhc wg to change the format of the = dhcov4 option and to use distinct names for each option. Bernie reviewed = the updated text before publication.=20 > * the genarea review. > * the suggestion from IANA to include some missing information in the = IANA section. You seem to have missed the gen-art review request to add a reference = for IPv6-encoded IPv4 addresses. Unfortunately there is one other problem which was present in the = previous draft but which I did not notice until I was reviewing your = changes just now: you specify new behavior for the DHCP server. The = relevant paragraph is this one from section 5: The DHCP server MAY be configurable with one or multiple Fully Qualified Domain Names (FQDNs) of the PCP server(s). In such case, the DHCP server MUST resolve these FQDNs into one or a list of IP addresses. If multiple FQDNs are configured to the DHCP server, the DHCP server MUST include multiple lists of PCP server IP addresses in the PCP server option (encoded as multiple OPTION_V6_PCP_SERVER or in the same OPTION_V4_PCP_SERVER); each of them carries one or a list of IP addresses that resulted from the FQDN resolution. DHCPv4 servers supporting PCP server option MUST resolve any configured FQDNs into IPv4 addresses while DHCPv6 servers may resolve any configured FQDNs into IPv6 and/or IPv4 addresses. If an IPv4 address is retrieved by the DHCPv6 server, the corresponding IPv4-mapped IPv6 address is included in OPTION_V6_PCP_SERVER. If both IPv4 and IPv6 addresses are retrieved by the DHCPv6 server, these addresses are included in the same OPTION_V6_PCP_SERVER (IPv4 addresses are represented as IPv4-mapped IPv6 addresses). The problem is that you have specified that the way the DHCP server = differentiates between two PCP servers is through the FQDN, but the DHCP = protocol specifications do not specify how DHCP servers are configured; = by doing so here you are making a very significant change. An additional problem is that current DHCPv6 servers can be expected to = query only AAAA records when resolving FQDNs. This isn't going to work = for you, but the specification needs to be done carefully to avoid = creating trouble in the future. What you should say is probably something like this: Precisely how DHCP servers are configured to separate lists of IP addresses according to which PCP server they address is out of scope for this document. However, DHCP servers MUST NOT treat IP addresses returned from a single FQDN lookup as belonging to more than one PCP server. DHCPv6 servers that implement this option and that can populate the option by resolving FQDNs will need a mechanism for indicating whether to query for A records or only AAAA records. When a query returns A records, the IP addresses in those records are returned in the DHCP response as IPv4-mapped IPv6 addresses. Since this option requires support for IPv4-mapped IPv6 addresses, a DHCP server implementation will not be complete if it does not query for A records and represent any that are returned as IPv4-mapped IPv6 addresses in DHCP responses. This behavior is neither required nor suggested for DHCPv6 options in general: it is specific to OPTION_V6_PCP_SERVER. The mechanism whereby DHCPv6 implementations provide this functionality is beyond the = scope of this document. This still adds two requirements that weren't present in the base spec, = but I think it's necessary to accomplish what you want. The = non-splitting requirement should already be the way DHCP servers = operate. The v4-mapped requirement is new functionality, but you can't = specify in detail how it works without needlessly constraining = implementations. By stating what is required rather than specifically = how to do it, I think you can sidestep that problem. I'm sorry for adding yet another complication=97the reason this is hard = is because you are using a feature of the DHCP server that nobody has = ever used before, and adding a new feature as well. Arguably these are = DHCP protocol extensions, and should have been done in DHC working group = and then presented to you as a tool upon which you could base your = option definition specification. But at this point it's too late to go = that route, so I am not going to suggest that we do so. Hopefully the = text you've added here can be folded into 3315bis, so that future = specifications that want to do the same thing have better tools at their = disposal for accomplishing it. Of course, I am curious whether the DHC working group agrees with my = proposal. Comments? From nobody Tue Apr 1 07:41:32 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0FD1A07CA for ; Tue, 1 Apr 2014 07:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGcHFsr6N5UM for ; Tue, 1 Apr 2014 07:41: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 222851A0858 for ; Tue, 1 Apr 2014 07:41:27 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C3F2618C1C7; Tue, 1 Apr 2014 16:41:22 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A229A35C06A; Tue, 1 Apr 2014 16:41:22 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 1 Apr 2014 16:41:22 +0200 From: To: Ted Lemon Date: Tue, 1 Apr 2014 16:41:20 +0200 Thread-Topic: New Version Notification - draft-ietf-pcp-dhcp-10.txt Thread-Index: Ac9NteCJkwrfkiOCRzG+Umorln2AjgAAFdkw Message-ID: <94C682931C08B048B7A8645303FDC9F36F54484AFA@PUEXCB1B.nanterre.francetelecom.fr> References: <20140401074050.4622.92489.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F544848AE@PUEXCB1B.nanterre.francetelecom.fr> <657EBF08-AD6C-4E76-AF8B-DADF707B6720@nominum.com> In-Reply-To: <657EBF08-AD6C-4E76-AF8B-DADF707B6720@nominum.com> 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: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.1.70017 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/ka60djxx5CqJWgTt8pM50wYWo68 Cc: DHC WG , "draft-ietf-pcp-dhcp@tools.ietf.org" , "pcp-chairs@tools.ietf.org" Subject: Re: [dhcwg] New Version Notification - draft-ietf-pcp-dhcp-10.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:41:29 -0000 HI Ted, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:ted.lemon@nominum.com] >Envoy=E9=A0: mardi 1 avril 2014 16:23 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: pcp-chairs@tools.ietf.org; draft-ietf-pcp-dhcp@tools.ietf.org; DHC = WG >Objet=A0: Re: New Version Notification - draft-ietf-pcp-dhcp-10.txt > >On Apr 1, 2014, at 3:47 AM, > wrote: >> * the recommendations from the dhc wg to change the format of the dhcov4 >option and to use distinct names for each option. Bernie reviewed the >updated text before publication. >> * the genarea review. >> * the suggestion from IANA to include some missing information in the >IANA section. > >You seem to have missed the gen-art review request to add a reference for >IPv6-encoded IPv4 addresses. [Med] I didn't missed this one. A reference to mapped IPv4 addresses is alr= eady cited in Section 3.1 " IPv4-mapped IPv6 addresses (Section 2.5.5.2 of = [RFC4291])". No need to cite it again in Section 3.2. > >Unfortunately there is one other problem which was present in the previous >draft but which I did not notice until I was reviewing your changes just >now: you specify new behavior for the DHCP server. The relevant paragrap= h >is this one from section 5: [Med] This text was added when we abandoned to return a name to the client.= One of the argument received at that time is that servers can resolve the = name and return the results to the clients. The text is specific about the = behavior of the name resolution because there are cases where client is onl= y IPv6 while the PCP server is IPv4 (see the example of DS-lite cited in th= e draft). > > The DHCP server MAY be configurable with one or multiple Fully > Qualified Domain Names (FQDNs) of the PCP server(s). In such case, > the DHCP server MUST resolve these FQDNs into one or a list of IP > addresses. If multiple FQDNs are configured to the DHCP server, the > DHCP server MUST include multiple lists of PCP server IP addresses in > the PCP server option (encoded as multiple OPTION_V6_PCP_SERVER or in > the same OPTION_V4_PCP_SERVER); each of them carries one or a list of > IP addresses that resulted from the FQDN resolution. DHCPv4 servers > supporting PCP server option MUST resolve any configured FQDNs into > IPv4 addresses while DHCPv6 servers may resolve any configured FQDNs > into IPv6 and/or IPv4 addresses. If an IPv4 address is retrieved by > the DHCPv6 server, the corresponding IPv4-mapped IPv6 address is > included in OPTION_V6_PCP_SERVER. If both IPv4 and IPv6 addresses > are retrieved by the DHCPv6 server, these addresses are included in > the same OPTION_V6_PCP_SERVER (IPv4 addresses are represented as > IPv4-mapped IPv6 addresses). > >The problem is that you have specified that the way the DHCP server >differentiates between two PCP servers is through the FQDN, but the DHCP >protocol specifications do not specify how DHCP servers are configured; by >doing so here you are making a very significant change. [Med] Yes, that text was added because there is no dhc document that specif= ies how name resolutions is done and whether AAAA and/or A queries are to b= e achieved, etc. As I said above, this is a side effect of returning an add= ress to the client instead of a name. > >An additional problem is that current DHCPv6 servers can be expected to >query only AAAA records when resolving FQDNs. This isn't going to work >for you, but the specification needs to be done carefully to avoid creatin= g >trouble in the future. > >What you should say is probably something like this: > > Precisely how DHCP servers are configured to separate lists of > IP addresses according to which PCP server they address is out > of scope for this document. However, DHCP servers MUST NOT > treat IP addresses returned from a single FQDN lookup as belonging > to more than one PCP server. > > DHCPv6 servers that implement this option and that can populate > the option by resolving FQDNs will need a mechanism for indicating > whether to query for A records or only AAAA records. When a query > returns A records, the IP addresses in those records are returned > in the DHCP response as IPv4-mapped IPv6 addresses. > > Since this option requires support for IPv4-mapped IPv6 addresses, > a DHCP server implementation will not be complete if it does not > query for A records and represent any that are returned as > IPv4-mapped IPv6 addresses in DHCP responses. This behavior is > neither required nor suggested for DHCPv6 options in general: it is > specific to OPTION_V6_PCP_SERVER. The mechanism whereby > DHCPv6 implementations provide this functionality is beyond the scope > of this document. [Med] This text seems OK to me. I have only one minor comment is that this = is not specific to OPTION_V6_PCP_SERVER but can apply each time we need to = provide a list of IP addresses to a dual-stack host connected via an IPv6-o= nly connectivity using an encapsulation mode. I' suggest to remove the sent= ence starting with " This behavior is ...". > >This still adds two requirements that weren't present in the base spec, bu= t >I think it's necessary to accomplish what you want. The non-splitting >requirement should already be the way DHCP servers operate. The v4-mappe= d >requirement is new functionality, but you can't specify in detail how it >works without needlessly constraining implementations. By stating what i= s >required rather than specifically how to do it, I think you can sidestep >that problem. > >I'm sorry for adding yet another complication-the reason this is hard is >because you are using a feature of the DHCP server that nobody has ever >used before, and adding a new feature as well. Arguably these are DHCP >protocol extensions, and should have been done in DHC working group and >then presented to you as a tool upon which you could base your option >definition specification. But at this point it's too late to go that >route, so I am not going to suggest that we do so. Hopefully the text >you've added here can be folded into 3315bis, so that future specification= s >that want to do the same thing have better tools at their disposal for >accomplishing it. [Med] This works for me. > >Of course, I am curious whether the DHC working group agrees with my >proposal. Comments? From nobody Tue Apr 1 07:45:34 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1349B1A086E for ; Tue, 1 Apr 2014 07:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9cN3Qhe54xV for ; Tue, 1 Apr 2014 07:45:31 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id AF7791A0858 for ; Tue, 1 Apr 2014 07:45:31 -0700 (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 7BD361B83EE for ; Tue, 1 Apr 2014 07:45:28 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 750AB190043; Tue, 1 Apr 2014 07:45:28 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 07:45:28 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F54484AFA@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 1 Apr 2014 10:45:26 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140401074050.4622.92489.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F544848AE@PUEXCB1B.nanterre.francetelecom.fr> <657EBF08-AD6C-4E76-AF8B-DADF707B6720@nominum.com> <94C682931C08B048B7A8645303FDC9F36F54484AFA@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/CYGkJQLK-39rJKYfAwN41OqDLnI Cc: DHC WG , "draft-ietf-pcp-dhcp@tools.ietf.org" , "pcp-chairs@tools.ietf.org" Subject: Re: [dhcwg] New Version Notification - draft-ietf-pcp-dhcp-10.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:45:33 -0000 On Apr 1, 2014, at 10:41 AM, = wrote: > [Med] This text seems OK to me. I have only one minor comment is that = this is not specific to OPTION_V6_PCP_SERVER but can apply each time we = need to provide a list of IP addresses to a dual-stack host connected = via an IPv6-only connectivity using an encapsulation mode. I' suggest to = remove the sentence starting with " This behavior is ...". What I am specifically trying to avoid is DHCPv6 servers simply doing A = queries for all FQDN resolutions and returning IPv4-mapped IPv6 = addresses in all cases. This would be disastrous. If some future = option requires this functionality, it should refer either to this = specification, or to 3315bis, assuming that 3315bis documents this = capability. But it absolutely cannot be enabled by default on all = DHCPv6 options. From nobody Tue Apr 1 07:49:42 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9111A06F4 for ; Tue, 1 Apr 2014 07:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-sVsApcdU8a for ; Tue, 1 Apr 2014 07:49:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DACFC1A06C0 for ; Tue, 1 Apr 2014 07:49:38 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id CA76422C243; Tue, 1 Apr 2014 16:49:34 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AD8F4238081; Tue, 1 Apr 2014 16:49:34 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 1 Apr 2014 16:49:34 +0200 From: To: Ted Lemon Date: Tue, 1 Apr 2014 16:49:32 +0200 Thread-Topic: New Version Notification - draft-ietf-pcp-dhcp-10.txt Thread-Index: Ac9NuQeKN7jmedqXS0a33bLy9d2/sgAAIX8w Message-ID: <94C682931C08B048B7A8645303FDC9F36F54484B06@PUEXCB1B.nanterre.francetelecom.fr> References: <20140401074050.4622.92489.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F544848AE@PUEXCB1B.nanterre.francetelecom.fr> <657EBF08-AD6C-4E76-AF8B-DADF707B6720@nominum.com> <94C682931C08B048B7A8645303FDC9F36F54484AFA@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: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.1.70017 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/qSVeJWUUV0FkYzF30PlrC7IUCr8 Cc: DHC WG , "draft-ietf-pcp-dhcp@tools.ietf.org" , "pcp-chairs@tools.ietf.org" Subject: Re: [dhcwg] New Version Notification - draft-ietf-pcp-dhcp-10.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:49:40 -0000 That's make sense too.=20 Thanks. Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:ted.lemon@nominum.com] >Envoy=E9=A0: mardi 1 avril 2014 16:45 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: pcp-chairs@tools.ietf.org; draft-ietf-pcp-dhcp@tools.ietf.org; DHC = WG >Objet=A0: Re: New Version Notification - draft-ietf-pcp-dhcp-10.txt > >On Apr 1, 2014, at 10:41 AM, > wrote: >> [Med] This text seems OK to me. I have only one minor comment is that >this is not specific to OPTION_V6_PCP_SERVER but can apply each time we >need to provide a list of IP addresses to a dual-stack host connected via >an IPv6-only connectivity using an encapsulation mode. I' suggest to remov= e >the sentence starting with " This behavior is ...". > >What I am specifically trying to avoid is DHCPv6 servers simply doing A >queries for all FQDN resolutions and returning IPv4-mapped IPv6 addresses >in all cases. This would be disastrous. If some future option requires >this functionality, it should refer either to this specification, or to >3315bis, assuming that 3315bis documents this capability. But it >absolutely cannot be enabled by default on all DHCPv6 options. From nobody Tue Apr 1 18:57:30 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E951A0069 for ; Tue, 1 Apr 2014 18:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiloWMkeJSO9 for ; Tue, 1 Apr 2014 18:57:24 -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 410811A006C for ; Tue, 1 Apr 2014 18:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9743; q=dns/txt; s=iport; t=1396403841; x=1397613441; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=iO7zV1jMhMQLrV1T5qEtOK0fLB7wymS1TlULELVC1tc=; b=jCno0fUHJMD5igcd4OUYr86ck+E0Y5My0f9jhc4l9ve5xA7uegVW+Nlg /z5KCZCoaB7U+cniJjHQ5yLnkhEyMHg3TIQzG4aEON1wcbbA7P5u0lPff TtYICGL9C+e3I8VuRj838PcWc1VbxL1f8bVy3cO01skN9G0Dq1ju7RP1X g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUGAPxtO1OtJA2L/2dsb2JhbABZgkJEO1e6bIh0gR8WdIIlAQEBBB0QQRsCAQgRBAEBCx0HMhQJCAEBBBMIAYdwDdAxF44cAwEBHjcBgySBFASaCZEGgXGBP4FyOQ X-IronPort-AV: E=Sophos;i="4.97,777,1389744000"; d="scan'208,217";a="314460780" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP; 02 Apr 2014 01:57:01 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s321v0pK017650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Apr 2014 01:57:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.5]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 20:57:00 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WG Adoption Call - draft-csf-dhc-dynamic-shared-v4allocation-00 - respond by March 30 Thread-Index: Ac8+WOG/Hl25fndcS2C7mXK3YH4FWwPvbKZw Date: Wed, 2 Apr 2014 01:56:59 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AF90F61@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AF08718@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AF08718@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.144] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AF90F61xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/NMle9RtjhluOEcaUYFCOXb0kWoA Subject: Re: [dhcwg] WG Adoption Call - draft-csf-dhc-dynamic-shared-v4allocation-00 - respond by March 30 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 01:57:26 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AF90F61xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WG will adopt this draft given the response on the mailing list and at = the London IETF meeting. Our AD agreed it was appropriate for the DHC WG. The authors are requested to republish the document as draft-ietf-dhc-dynam= ic-shared-v4allocation. - Bernie (& Tomek) From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Wednesday, March 12, 2014 9:11 PM To: dhcwg@ietf.org Subject: [dhcwg] WG Adoption Call - draft-csf-dhc-dynamic-shared-v4allocati= on-00 - respond by March 30 Hi all: A call for adoption is being initiated following up from the London IETF-89= DHC WG session to determine whether there is WG consensus to adopt draft-c= sf-dhc-dynamic-shared-v4allocation-00 as a DHC WG item. Please state whethe= r or not you are in favor of the adoption by replying to this mail. If you = are not in favor, please also state your objections in your response. This = adoption call will complete on March 30, 2014. The HTML version of the document can be viewed at http://tools.ietf.org/htm= l/draft-csf-dhc-dynamic-shared-v4allocation-00. You can view the presentati= on from the London IETF at http://www.ietf.org/proceedings/89/slides/slides= -89-dhc-6.pptx. If there is consensus to adopt as a WG document, we will confer with Ted Le= mon (AD) to determine if we can get it on the charter as there is presently= no direct charter item to cover it. Regards, Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1AF90F61xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WG will adopt this= draft given the response on the mailing list and at the London IETF meetin= g. Our AD agreed it was appropriate for the DHC WG.

 

The authors are reques= ted to republish the document as draft-ietf-dhc-dynamic-shared-v4allocation= .

 

-&nb= sp;         Bernie (& = Tomek)

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, March 12, 2014 9:11 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Adoption Call - draft-csf-dhc-dynamic-shared-v4a= llocation-00 - respond by March 30

 

Hi all:

 

A call for adoption is being initiated following = up from the London IETF-89 DHC WG session to determine whether there is WG = consensus to adopt draft-csf-dhc-dynamic-shared-v4allocation-00 as a DHC WG= item. Please state whether or not you are in favor of the adoption by replying to this mail. If you are not = in favor, please also state your objections in your response. This adoption= call will complete on March 30, 2014.

 

The HTML version of the document can be viewed at= http://tools.ietf.org/html/draft-csf-dhc-dynamic-shared-v4allocation-00= . You can view the presentation from the London IETF at = http://www.ietf.org/proceedings/89/slides/slides-89-dhc-6.pptx.

 

If there is consensus to adopt as a WG document, = we will confer with Ted Lemon (AD) to determine if we can get it on the cha= rter as there is presently no direct charter item to cover it.

 

Regards,

Tomek & Bernie

 

--_000_489D13FBFA9B3E41812EA89F188F018E1AF90F61xmbrcdx04ciscoc_-- From nobody Thu Apr 3 02:28:09 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAF81A008E for ; Thu, 3 Apr 2014 02:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9dnMGOctd5z for ; Thu, 3 Apr 2014 02:28:03 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id EF9D61A00DB for ; Thu, 3 Apr 2014 02:27:57 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id uo5so1565925pbc.38 for ; Thu, 03 Apr 2014 02:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=n5DWTdTZ61bO+y6F67Ztrf1s6kywxGV26CX5ZYosefw=; b=uRgWM0zWs3M9/XeW7sXZPEAX1DaIp+5mwJ5KhdHHsR5aD6fXgCdRjdamekO+CKZ5lj lnwaY7nLpT9ucuoSXxlF+N440AJYQYD1HtCPYWZN4zOd9NHcYFfksa0vxgvjq+Cifelu rWRnp9qskxBzI8nsYzXHXsZ34LAZTKaYHO1stFEXM35OCHAbUZ62rJJ0h1lSlj299kTh o8AtLbEGahWOqFlKtCb6TOtWDrh5YDLwFy42WWALd02hRsDZp2ypIrP0tONHCKMcQMl7 5pTrY/d3tAj/2BoTAB++DAF23ivaGD+7dXB9l9jrzO2wHyjPGJ3tc4yttjHPUX45ozMh h5HA== X-Received: by 10.68.113.5 with SMTP id iu5mr6142731pbb.60.1396517273908; Thu, 03 Apr 2014 02:27:53 -0700 (PDT) Received: from sunqideair.lan ([166.111.68.231]) by mx.google.com with ESMTPSA id qh2sm22612114pab.13.2014.04.03.02.27.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 02:27:53 -0700 (PDT) From: Qi Sun Content-Type: multipart/alternative; boundary="Apple-Mail=_018E8CD6-E2D1-40AC-BC54-EF5FDE963B10" Date: Thu, 3 Apr 2014 17:27:47 +0800 Message-Id: <0608491B-C35F-4145-BD3D-A3D766A5A3E4@gmail.com> To: "" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/94ibZGmTp_zC69z44JlMrBbYCME Cc: draft-ietf-dhc-sedhcpv6@tools.ietf.org Subject: [dhcwg] Review of draft-ietf-dhc-sedhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 09:28:08 -0000 --Apple-Mail=_018E8CD6-E2D1-40AC-BC54-EF5FDE963B10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all, I volunteered to review the document. Here are my comments (sorry if = some of them have been discussed). But most are editorial.=20 1. Technical 1) About the Signature Option a) Different description of Signature Option: Sec 5.3: "It protects the entire DHCPv6 header and options, except for = the Authentication Option.=94=20 Sec 6.1: "It protects the message header and the message payload and all = DHCPv6 options except for the Signature option itself and the = Authentication Option.=94 b) As is described above, Signature option does not protect itself = including the timestamp which will be used to judge the message's = validity. It means attackers can change the timestamp without destroying = the signature. So attackers changes the timestamp of message, then the = recipient will inspect the signature which is "correct" despite the = change of the timestamp. This might cause a replay attack. 2) Inequality on the bottom of Page 12 "TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz" What if RDnew < RDlast, maybe caused by a bad clock? In this case, the = inequality holds (so that the message is accepted) but there might be = something wrong. For the security reason, it would be better to drop the = message, IMHO. 2. Editorial 1) Section titles: Sec 3: Security Overview of DHCPv6 Sec 4: Secure DHCPv6 Overview They are kind of close at the first glance. Suggestion: s/Sec 4: Secure DHCPv6 Overview/Sec 4: Secure DHCPv6 Mechanism Overview/ 2) Add a section of Terminology There are some terms that are not well-known to the readers. It would be = clearer if a section of Terminology could define them before using. For example: CA; leap of faith mode; TSlast; RDlast; TSnew; RDnew; drift; etc. 3) Sec 3, 2nd paragraph (and followed paras) Unnecessary indentation 4) Sec 4, 3rd para In this document, we introduce a public key option, a certificate option and a signature options with a corresponding verification mechanism. s/a signature options/a signature option/ 5) Sec 4.1, bullet 1 A second option is defined to carry the certificate. s/A second option/Another option/ Note: =93A second option=94 reads like the two options are kind of = linked to each other. But from the description, the two options should = not appear at the same time. 6) Sec 5.1 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_Public_Key | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Public Key (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s/OPTION_Public_Key/OPTION_PK_PARAMETER/ 7) Sec 5.2 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_Certificate | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Public Key (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s/OPTION_Certificate/OPTION_CERT_PARAMETER/ 8) Sec 6.2, the last para A Relay-forward or Relay-reply message with any Public Key, Certificate or the Signature option is invilad. The message SHOULD be discarded silently. s/invilad/invalid/ Use MUST instead of SHOULD? 9) Sec 6.3, 1st para Actually, be definition in this document, relay agents MUST NOT add any secure DHCPv6 options. 10) Sec 6.4, bullet 2 o The time stamp in the last received and accepted DHCPv6 message.=20= This is called TSlast.=20 s/time stamp/timestamp/ 11) Sec 7, 3rd para The Secure DHCPv6 mechanism is based on the pre-condition that the recipient knows the public key of senders or the sender=92s = certificate can be verified through a trust CA. s/through a trust CA/through a trusted CA/ 12) Sec 7, Page 14 However, the two communciating nodes can be synchronized is out of scope of this work. s/the two/how the two/ s/communciating nodes/communicating nodes/ Best Regards, Qi=20= --Apple-Mail=_018E8CD6-E2D1-40AC-BC54-EF5FDE963B10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,

I volunteered to review the document. Here are my comments = (sorry if some of them have been discussed). But most are = editorial. 

1. Technical
1) About the = Signature Option
a) = Different description of Signature Option:
Sec 5.3: = "It protects the entire DHCPv6 header and options, except for the = Authentication Option.=E2=80=9D 
Sec 6.1: = "It protects the message header and the message payload and all DHCPv6 = options except for the Signature option itself and the Authentication = Option.=E2=80=9D

b) As is described above, Signature option = does not protect itself including the timestamp which will be used to = judge the message's validity. It means attackers can change the = timestamp without destroying the signature. So attackers changes the = timestamp of message, then the recipient will inspect the signature = which is "correct" despite the change of the timestamp. This might cause = a replay attack.

2) Inequality on the bottom of Page 12
"TSnew + = fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz"

What if RDnew < RDlast, maybe caused by a bad clock? In this = case, the inequality holds (so that the message is accepted) but there = might be something wrong. For the security reason, it would be better to = drop the message, IMHO.

2. Editorial
1) Section = titles:
Sec 3: = Security Overview of DHCPv6
Sec 4: = Secure DHCPv6 Overview
They are = kind of close at the first glance.
Suggestion:
s/Sec 4: = Secure DHCPv6 Overview/Sec 4: Secure DHCPv6 Mechanism Overview/

2) Add a section of Terminology
There are = some terms that are not well-known to the readers. It would be clearer = if a section of Terminology could define them before using.
For example:
CA; leap of = faith mode; TSlast; RDlast; TSnew; RDnew; drift; etc.

3) Sec 3, 2nd paragraph (and followed paras)
Unnecessary = indentation

4) Sec 4, 3rd para
  In = this document, we introduce a public key option, a certificate
  = option and a signature options with a corresponding verification
  = mechanism.
s/a = signature options/a signature option/

5) Sec 4.1, bullet 1
  A = second option is defined to carry the certificate.
s/A second = option/Another option/
Note: =E2=80=9C= A second option=E2=80=9D reads like the two options are kind of linked = to each other. But from the description, the two options should not = appear at the same time.

6) Sec 5.1
 0         &nbs= p;         = 1            &= nbsp;      = 2            &= nbsp;      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_Public_Key         = |         = option-len          &nbs= p; |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|          &nbs= p;            =             &n= bsp;           &nbs= p;            =    |
.          &nbs= p;     Public Key (variable = length)           &= nbsp;       .
.          &nbs= p;            =             &n= bsp;           &nbs= p;            =    .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
s/OPTION_Public_Key/OPTION_PK_PARAMETER/

7) Sec 5.2
 0         &nbs= p;         = 1            &= nbsp;      = 2            &= nbsp;      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_Certificate         = |         = option-len          &nbs= p; |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|          &nbs= p;            =             &n= bsp;           &nbs= p;            =    |
.          &nbs= p;     Public Key (variable = length)           &= nbsp;       .
.          &nbs= p;            =             &n= bsp;           &nbs= p;            =    .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
s/OPTION_Certificate/OPTION_CERT_PARAMETER/

8) Sec 6.2, the last para 
   A Relay-forward or =
Relay-reply message with any Public Key,
   Certificate or the Signature option is invilad.  The message SHOULD
   be discarded silently.
s/invilad/invalid/
Use MUST = instead of SHOULD?

9) Sec 6.3, 1st para 
   Actually, be =
definition in
   this document, relay agents MUST NOT add any secure DHCPv6 options.
10) Sec 6.4, bullet 2 
   o  The time stamp in =
the last received and accepted DHCPv6 message. 
      This is called =
TSlast.=20
s/time stamp/timestamp/

11) Sec 7, 3rd para 
   The Secure DHCPv6 =
mechanism is based on the pre-condition that the
   recipient knows the public key of senders or the sender=E2=80=99s =
certificate
   can be verified through a trust CA.
s/through a trust CA/through a trusted CA/


12) Sec 7, Page 14 
   However, the two =
communciating nodes can be synchronized is out of
   scope of this work.
s/the two/how the two/
s/communciating nodes/communicating nodes/

Best Regards,
Qi 
= --Apple-Mail=_018E8CD6-E2D1-40AC-BC54-EF5FDE963B10-- From nobody Fri Apr 4 04:08:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060101A040B for ; Fri, 4 Apr 2014 00:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5k78JO5Mi8HF for ; Fri, 4 Apr 2014 00:52:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1A51A0019 for ; Fri, 4 Apr 2014 00:52:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCS78430; Fri, 04 Apr 2014 07:52:29 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Apr 2014 08:51:40 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Apr 2014 08:52:28 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.206]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 4 Apr 2014 15:52:23 +0800 From: Sheng Jiang To: Qi Sun , "" Thread-Topic: Review of draft-ietf-dhc-sedhcpv6-01 Thread-Index: AQHPTx8YOJxAVW///0a/FAJpGv/Bz5sBFG2g Date: Fri, 4 Apr 2014 07:52:22 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE34B8A@nkgeml512-mbx.china.huawei.com> References: <0608491B-C35F-4145-BD3D-A3D766A5A3E4@gmail.com> In-Reply-To: <0608491B-C35F-4145-BD3D-A3D766A5A3E4@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AE34B8Ankgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/6K4VeTU31rHjrIrTEkTjA2FHdEY X-Mailman-Approved-At: Fri, 04 Apr 2014 04:08:26 -0700 Cc: "draft-ietf-dhc-sedhcpv6@tools.ietf.org" Subject: Re: [dhcwg] Review of draft-ietf-dhc-sedhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 07:52:41 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AE34B8Ankgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFFpLA0KDQpUaGFua3Mgc28gbXVjaCBmb3IgeW91ciBjYXJlZnVsbHkgcmV2aWV3LiBBbGwg ZWRpdG9yaWFsIGNvbW1lbnRzIHdpbGwgYmUgYXBwbGllZCBpbiB0aGUgbmV4dCB1cGRhdGUgaW4g YSBjb3VwbGUgb2Ygd2VlayB0aW1lLiBZb3VyIHRlY2huaWNhbCBjb21tZW50cyBhcmUgYWxzbyB2 YWxpZCwgdGhleSB3aWxsIGJlIGFwcGxpZWQgdG9vLg0KDQpTb21lIGV4cGxhbmF0aW9uIGZvciB0 ZWNobmljYWwgcG9pbnQgMSwgcmVnYXJkaW5nIHRvIHNpZ25hdHVyZSBvcHRpb24uICBJbiB0aGUg c2VjdGlvbiA1LjMsIHRoZSBzaWduYXR1cmUg4oCcY29uc3RydWN0ZWQgYnkgdXNpbmcgdGhlIHNl bmRlcidzIHByaXZhdGUga2V5IHByb3RlY3RzIHRoZSBmb2xsb3dpbmcgc2VxdWVuY2Ugb2Ygb2N0 ZXRzOg0KDQogICAgICAgICAgICAgICAxLiBUaGUgREhDUHY2IG1lc3NhZ2UgaGVhZGVyLg0KDQog ICAgICAgICAgICAgICAyLiBBbGwgREhDUHY2IG9wdGlvbnMgaW5jbHVkaW5nIHRoZSBTaWduYXR1 cmUNCiAgICAgICAgICAgICAgIG9wdGlvbiAoZmlsbCB0aGUgc2lnbmF0dXJlIGZpZWxkIHdpdGgg emVyb2VzKQ0KICAgICAgICAgICAgICAgZXhjZXB0IGZvciB0aGUgQXV0aGVudGljYXRpb24gT3B0 aW9uLuKAnQ0KDQpTbywgdGhlIHNpZ25hdHVyZSBvcHRpb24gaXRzZWxmLCBpbmNsdWRpbmcgdGlt ZXN0YW1wIGlzIGFjdHVhbGx5IHByb3RlY3RlZC4gQ2hhbmdpbmcgdGhlIHdyb25nIGRlc2NyaXB0 aW9uIGluIFNlY3Rpb24gNi4xIHdvdWxkIGJlIHN1ZmZpY2llbnQgdG8gYWRkcmVzcyB0aGlzIGNv bW1lbnQuDQoNClJlZ2FyZHMsDQoNClNoZW5nDQoNCkZyb206IFFpIFN1biBbbWFpbHRvOnN1bnFp LmNzbmV0LnRodUBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDMsIDIwMTQgNToy OCBQTQ0KVG86IDxkaGN3Z0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2NkB0 b29scy5pZXRmLm9yZzsgbGl1emlsb25nODI2NkAxNjMuY29tDQpTdWJqZWN0OiBSZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMDENCg0KSGkgYWxsLA0KDQpJIHZvbHVudGVlcmVkIHRv IHJldmlldyB0aGUgZG9jdW1lbnQuIEhlcmUgYXJlIG15IGNvbW1lbnRzIChzb3JyeSBpZiBzb21l IG9mIHRoZW0gaGF2ZSBiZWVuIGRpc2N1c3NlZCkuIEJ1dCBtb3N0IGFyZSBlZGl0b3JpYWwuDQoN CjEuIFRlY2huaWNhbA0KMSkgQWJvdXQgdGhlIFNpZ25hdHVyZSBPcHRpb24NCmEpIERpZmZlcmVu dCBkZXNjcmlwdGlvbiBvZiBTaWduYXR1cmUgT3B0aW9uOg0KU2VjIDUuMzogIkl0IHByb3RlY3Rz IHRoZSBlbnRpcmUgREhDUHY2IGhlYWRlciBhbmQgb3B0aW9ucywgZXhjZXB0IGZvciB0aGUgQXV0 aGVudGljYXRpb24gT3B0aW9uLuKAnQ0KU2VjIDYuMTogIkl0IHByb3RlY3RzIHRoZSBtZXNzYWdl IGhlYWRlciBhbmQgdGhlIG1lc3NhZ2UgcGF5bG9hZCBhbmQgYWxsIERIQ1B2NiBvcHRpb25zIGV4 Y2VwdCBmb3IgdGhlIFNpZ25hdHVyZSBvcHRpb24gaXRzZWxmIGFuZCB0aGUgQXV0aGVudGljYXRp b24gT3B0aW9uLuKAnQ0KDQpiKSBBcyBpcyBkZXNjcmliZWQgYWJvdmUsIFNpZ25hdHVyZSBvcHRp b24gZG9lcyBub3QgcHJvdGVjdCBpdHNlbGYgaW5jbHVkaW5nIHRoZSB0aW1lc3RhbXAgd2hpY2gg d2lsbCBiZSB1c2VkIHRvIGp1ZGdlIHRoZSBtZXNzYWdlJ3MgdmFsaWRpdHkuIEl0IG1lYW5zIGF0 dGFja2VycyBjYW4gY2hhbmdlIHRoZSB0aW1lc3RhbXAgd2l0aG91dCBkZXN0cm95aW5nIHRoZSBz aWduYXR1cmUuIFNvIGF0dGFja2VycyBjaGFuZ2VzIHRoZSB0aW1lc3RhbXAgb2YgbWVzc2FnZSwg dGhlbiB0aGUgcmVjaXBpZW50IHdpbGwgaW5zcGVjdCB0aGUgc2lnbmF0dXJlIHdoaWNoIGlzICJj b3JyZWN0IiBkZXNwaXRlIHRoZSBjaGFuZ2Ugb2YgdGhlIHRpbWVzdGFtcC4gVGhpcyBtaWdodCBj YXVzZSBhIHJlcGxheSBhdHRhY2suDQoNCjIpIEluZXF1YWxpdHkgb24gdGhlIGJvdHRvbSBvZiBQ YWdlIDEyDQoiVFNuZXcgKyBmdXp6ID4gVFNsYXN0ICsgKFJEbmV3IC0gUkRsYXN0KSB4ICgxIC0g ZHJpZnQpIC0gZnV6eiINCg0KV2hhdCBpZiBSRG5ldyA8IFJEbGFzdCwgbWF5YmUgY2F1c2VkIGJ5 IGEgYmFkIGNsb2NrPyBJbiB0aGlzIGNhc2UsIHRoZSBpbmVxdWFsaXR5IGhvbGRzIChzbyB0aGF0 IHRoZSBtZXNzYWdlIGlzIGFjY2VwdGVkKSBidXQgdGhlcmUgbWlnaHQgYmUgc29tZXRoaW5nIHdy b25nLiBGb3IgdGhlIHNlY3VyaXR5IHJlYXNvbiwgaXQgd291bGQgYmUgYmV0dGVyIHRvIGRyb3Ag dGhlIG1lc3NhZ2UsIElNSE8uDQoNCjIuIEVkaXRvcmlhbA0KMSkgU2VjdGlvbiB0aXRsZXM6DQpT ZWMgMzogU2VjdXJpdHkgT3ZlcnZpZXcgb2YgREhDUHY2DQpTZWMgNDogU2VjdXJlIERIQ1B2NiBP dmVydmlldw0KVGhleSBhcmUga2luZCBvZiBjbG9zZSBhdCB0aGUgZmlyc3QgZ2xhbmNlLg0KU3Vn Z2VzdGlvbjoNCnMvU2VjIDQ6IFNlY3VyZSBESENQdjYgT3ZlcnZpZXcvU2VjIDQ6IFNlY3VyZSBE SENQdjYgTWVjaGFuaXNtIE92ZXJ2aWV3Lw0KDQoyKSBBZGQgYSBzZWN0aW9uIG9mIFRlcm1pbm9s b2d5DQpUaGVyZSBhcmUgc29tZSB0ZXJtcyB0aGF0IGFyZSBub3Qgd2VsbC1rbm93biB0byB0aGUg cmVhZGVycy4gSXQgd291bGQgYmUgY2xlYXJlciBpZiBhIHNlY3Rpb24gb2YgVGVybWlub2xvZ3kg Y291bGQgZGVmaW5lIHRoZW0gYmVmb3JlIHVzaW5nLg0KRm9yIGV4YW1wbGU6DQpDQTsgbGVhcCBv ZiBmYWl0aCBtb2RlOyBUU2xhc3Q7IFJEbGFzdDsgVFNuZXc7IFJEbmV3OyBkcmlmdDsgZXRjLg0K DQozKSBTZWMgMywgMm5kIHBhcmFncmFwaCAoYW5kIGZvbGxvd2VkIHBhcmFzKQ0KVW5uZWNlc3Nh cnkgaW5kZW50YXRpb24NCg0KNCkgU2VjIDQsIDNyZCBwYXJhDQogIEluIHRoaXMgZG9jdW1lbnQs IHdlIGludHJvZHVjZSBhIHB1YmxpYyBrZXkgb3B0aW9uLCBhIGNlcnRpZmljYXRlDQogIG9wdGlv biBhbmQgYSBzaWduYXR1cmUgb3B0aW9ucyB3aXRoIGEgY29ycmVzcG9uZGluZyB2ZXJpZmljYXRp b24NCiAgbWVjaGFuaXNtLg0Kcy9hIHNpZ25hdHVyZSBvcHRpb25zL2Egc2lnbmF0dXJlIG9wdGlv bi8NCg0KNSkgU2VjIDQuMSwgYnVsbGV0IDENCiAgQSBzZWNvbmQgb3B0aW9uIGlzIGRlZmluZWQg dG8gY2FycnkgdGhlIGNlcnRpZmljYXRlLg0Kcy9BIHNlY29uZCBvcHRpb24vQW5vdGhlciBvcHRp b24vDQpOb3RlOiDigJxBIHNlY29uZCBvcHRpb27igJ0gcmVhZHMgbGlrZSB0aGUgdHdvIG9wdGlv bnMgYXJlIGtpbmQgb2YgbGlua2VkIHRvIGVhY2ggb3RoZXIuIEJ1dCBmcm9tIHRoZSBkZXNjcmlw dGlvbiwgdGhlIHR3byBvcHRpb25zIHNob3VsZCBub3QgYXBwZWFyIGF0IHRoZSBzYW1lIHRpbWUu DQoNCjYpIFNlYyA1LjENCiAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAg MiAgICAgICAgICAgICAgICAgICAzDQogMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgT1BUSU9OX1B1 YmxpY19LZXkgICAgICAgICB8ICAgICAgICAgb3B0aW9uLWxlbiAgICAgICAgICAgIHwNCistKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KLiAgICAgICAgICAgICAgICBQdWJsaWMgS2V5ICh2YXJpYWJsZSBsZW5n dGgpICAgICAgICAgICAgICAgICAgIC4NCi4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQorLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0Kcy9PUFRJT05fUHVi bGljX0tleS9PUFRJT05fUEtfUEFSQU1FVEVSLw0KDQo3KSBTZWMgNS4yDQogMCAgICAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KIDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQ0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCnwgICAgT1BUSU9OX0NlcnRpZmljYXRlICAgICAgICAgfCAgICAgICAgIG9w dGlvbi1sZW4gICAgICAgICAgICB8DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCi4gICAgICAgICAgICAg ICAgUHVibGljIEtleSAodmFyaWFibGUgbGVuZ3RoKSAgICAgICAgICAgICAgICAgICAuDQouICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLg0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCnMvT1BUSU9OX0NlcnRpZmljYXRlL09QVElPTl9DRVJUX1BBUkFNRVRF Ui8NCg0KOCkgU2VjIDYuMiwgdGhlIGxhc3QgcGFyYQ0KDQogICBBIFJlbGF5LWZvcndhcmQgb3Ig UmVsYXktcmVwbHkgbWVzc2FnZSB3aXRoIGFueSBQdWJsaWMgS2V5LA0KDQogICBDZXJ0aWZpY2F0 ZSBvciB0aGUgU2lnbmF0dXJlIG9wdGlvbiBpcyBpbnZpbGFkLiAgVGhlIG1lc3NhZ2UgU0hPVUxE DQoNCiAgIGJlIGRpc2NhcmRlZCBzaWxlbnRseS4NCnMvaW52aWxhZC9pbnZhbGlkLw0KVXNlIE1V U1QgaW5zdGVhZCBvZiBTSE9VTEQ/DQoNCjkpIFNlYyA2LjMsIDFzdCBwYXJhDQoNCiAgIEFjdHVh bGx5LCBiZSBkZWZpbml0aW9uIGluDQoNCiAgIHRoaXMgZG9jdW1lbnQsIHJlbGF5IGFnZW50cyBN VVNUIE5PVCBhZGQgYW55IHNlY3VyZSBESENQdjYgb3B0aW9ucy4NCjEwKSBTZWMgNi40LCBidWxs ZXQgMg0KDQogICBvICBUaGUgdGltZSBzdGFtcCBpbiB0aGUgbGFzdCByZWNlaXZlZCBhbmQgYWNj ZXB0ZWQgREhDUHY2IG1lc3NhZ2UuDQoNCiAgICAgIFRoaXMgaXMgY2FsbGVkIFRTbGFzdC4NCnMv dGltZSBzdGFtcC90aW1lc3RhbXAvDQoNCjExKSBTZWMgNywgM3JkIHBhcmENCg0KICAgVGhlIFNl Y3VyZSBESENQdjYgbWVjaGFuaXNtIGlzIGJhc2VkIG9uIHRoZSBwcmUtY29uZGl0aW9uIHRoYXQg dGhlDQoNCiAgIHJlY2lwaWVudCBrbm93cyB0aGUgcHVibGljIGtleSBvZiBzZW5kZXJzIG9yIHRo ZSBzZW5kZXLigJlzIGNlcnRpZmljYXRlDQoNCiAgIGNhbiBiZSB2ZXJpZmllZCB0aHJvdWdoIGEg dHJ1c3QgQ0EuDQpzL3Rocm91Z2ggYSB0cnVzdCBDQS90aHJvdWdoIGEgdHJ1c3RlZCBDQS8NCg0K DQoxMikgU2VjIDcsIFBhZ2UgMTQNCg0KICAgSG93ZXZlciwgdGhlIHR3byBjb21tdW5jaWF0aW5n IG5vZGVzIGNhbiBiZSBzeW5jaHJvbml6ZWQgaXMgb3V0IG9mDQoNCiAgIHNjb3BlIG9mIHRoaXMg d29yay4NCnMvdGhlIHR3by9ob3cgdGhlIHR3by8NCnMvY29tbXVuY2lhdGluZyBub2Rlcy9jb21t dW5pY2F0aW5nIG5vZGVzLw0KDQpCZXN0IFJlZ2FyZHMsDQpRaQ0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AE34B8Ankgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAz IDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRh aG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpz cGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC8 5byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksIFFpLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3Mgc28gbXVjaCBmb3IgeW91 ciBjYXJlZnVsbHkgcmV2aWV3LiBBbGwgZWRpdG9yaWFsIGNvbW1lbnRzIHdpbGwgYmUgYXBwbGll ZCBpbiB0aGUgbmV4dCB1cGRhdGUgaW4gYSBjb3VwbGUgb2Ygd2VlayB0aW1lLiBZb3VyIHRlY2hu aWNhbCBjb21tZW50cw0KIGFyZSBhbHNvIHZhbGlkLCB0aGV5IHdpbGwgYmUgYXBwbGllZCB0b28u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvbWUgZXhwbGFuYXRpb24gZm9y IHRlY2huaWNhbCBwb2ludCAxLCByZWdhcmRpbmcgdG8gc2lnbmF0dXJlIG9wdGlvbi4gJm5ic3A7 SW4gdGhlIHNlY3Rpb24gNS4zLCB0aGUgc2lnbmF0dXJlIOKAnGNvbnN0cnVjdGVkIGJ5IHVzaW5n IHRoZSBzZW5kZXIncyBwcml2YXRlDQoga2V5IHByb3RlY3RzIHRoZSBmb2xsb3dpbmcgc2VxdWVu Y2Ugb2Ygb2N0ZXRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMS4gVGhlIERIQ1B2NiBtZXNzYWdlIGhlYWRlci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDIuIEFsbCBESENQdjYgb3B0aW9ucyBpbmNsdWRpbmcgdGhlIFNpZ25hdHVyZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IG9wdGlvbiAoZmlsbCB0aGUgc2lnbmF0dXJlIGZpZWxkIHdpdGggemVyb2VzKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGV4Y2VwdCBmb3IgdGhlIEF1dGhlbnRpY2F0aW9uIE9wdGlvbi7igJ08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIHRoZSBzaWduYXR1cmUgb3B0aW9uIGl0c2Vs ZiwgaW5jbHVkaW5nIHRpbWVzdGFtcCBpcyBhY3R1YWxseSBwcm90ZWN0ZWQuIENoYW5naW5nIHRo ZSB3cm9uZyBkZXNjcmlwdGlvbiBpbiBTZWN0aW9uIDYuMSB3b3VsZCBiZSBzdWZmaWNpZW50IHRv DQogYWRkcmVzcyB0aGlzIGNvbW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNoZW5nPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFFpIFN1biBbbWFpbHRvOnN1bnFpLmNzbmV0LnRodUBn bWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDAzLCAyMDE0IDU6 MjggUE08YnI+DQo8Yj5Ubzo8L2I+ICZsdDtkaGN3Z0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8 L2I+IGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2QHRvb2xzLmlldGYub3JnOyBsaXV6aWxvbmc4MjY2 QDE2My5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmV2aWV3IG9mIGRyYWZ0LWlldGYtZGhjLXNl ZGhjcHY2LTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkhpIGFsbCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SSB2b2x1bnRlZXJlZCB0byByZXZpZXcgdGhlIGRvY3VtZW50LiBIZXJlIGFyZSBteSBjb21t ZW50cyAoc29ycnkgaWYgc29tZSBvZiB0aGVtIGhhdmUgYmVlbiBkaXNjdXNzZWQpLiBCdXQgbW9z dCBhcmUgZWRpdG9yaWFsLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4xLiBUZWNobmljYWwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4xKSBBYm91dCB0aGUgU2lnbmF0dXJlIE9wdGlvbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTMuNXB0Ij5hKSBEaWZmZXJlbnQgZGVzY3JpcHRpb24gb2YgU2lnbmF0 dXJlIE9wdGlvbjo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPlNlYyA1LjM6ICZxdW90O0l0 IHByb3RlY3RzIHRoZSBlbnRpcmUgREhDUHY2IGhlYWRlciBhbmQgb3B0aW9ucywgZXhjZXB0IGZv ciB0aGUgQXV0aGVudGljYXRpb24gT3B0aW9uLuKAnSZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTMuNXB0Ij5TZWMgNi4xOiAmcXVvdDtJdCBwcm90ZWN0cyB0aGUgbWVzc2FnZSBo ZWFkZXIgYW5kIHRoZSBtZXNzYWdlIHBheWxvYWQgYW5kIGFsbCBESENQdjYgb3B0aW9ucyBleGNl cHQgZm9yIHRoZSBTaWduYXR1cmUgb3B0aW9uIGl0c2VsZiBhbmQgdGhlIEF1dGhlbnRpY2F0aW9u IE9wdGlvbi7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQiPmIpIEFzIGlzIGRlc2NyaWJl ZCBhYm92ZSwgU2lnbmF0dXJlIG9wdGlvbiBkb2VzIG5vdCBwcm90ZWN0IGl0c2VsZiBpbmNsdWRp bmcgdGhlIHRpbWVzdGFtcCB3aGljaCB3aWxsIGJlIHVzZWQgdG8ganVkZ2UgdGhlIG1lc3NhZ2Un cyB2YWxpZGl0eS4gSXQgbWVhbnMgYXR0YWNrZXJzIGNhbiBjaGFuZ2UgdGhlIHRpbWVzdGFtcCB3 aXRob3V0DQogZGVzdHJveWluZyB0aGUgc2lnbmF0dXJlLiBTbyBhdHRhY2tlcnMgY2hhbmdlcyB0 aGUgdGltZXN0YW1wIG9mIG1lc3NhZ2UsIHRoZW4gdGhlIHJlY2lwaWVudCB3aWxsIGluc3BlY3Qg dGhlIHNpZ25hdHVyZSB3aGljaCBpcyAmcXVvdDtjb3JyZWN0JnF1b3Q7IGRlc3BpdGUgdGhlIGNo YW5nZSBvZiB0aGUgdGltZXN0YW1wLiBUaGlzIG1pZ2h0IGNhdXNlIGEgcmVwbGF5IGF0dGFjay48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yKSBJbmVxdWFsaXR5IG9uIHRoZSBib3R0 b20gb2YgUGFnZSAxMg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZxdW90O1RTbmV3ICYjNDM7IGZ1enogJmd0OyBUU2xhc3QgJiM0MzsgKFJEbmV3IC0gUkRsYXN0 KSB4ICgxIC0gZHJpZnQpIC0gZnV6eiZxdW90Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5XaGF0IGlmIFJEbmV3ICZsdDsgUkRsYXN0LCBtYXliZSBjYXVzZWQgYnkgYSBiYWQg Y2xvY2s/IEluIHRoaXMgY2FzZSwgdGhlIGluZXF1YWxpdHkgaG9sZHMgKHNvIHRoYXQgdGhlIG1l c3NhZ2UgaXMgYWNjZXB0ZWQpIGJ1dCB0aGVyZSBtaWdodCBiZSBzb21ldGhpbmcgd3JvbmcuIEZv cg0KIHRoZSBzZWN1cml0eSByZWFzb24sIGl0IHdvdWxkIGJlIGJldHRlciB0byBkcm9wIHRoZSBt ZXNzYWdlLCBJTUhPLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIuIEVkaXRv cmlhbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjEpIFNlY3Rp b24gdGl0bGVzOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNl YyAzOiBTZWN1cml0eSBPdmVydmlldyBvZiBESENQdjYNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZWMgNDogU2VjdXJlIERIQ1B2NiBPdmVydmlldw0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZXkgYXJlIGtpbmQgb2YgY2xv c2UgYXQgdGhlIGZpcnN0IGdsYW5jZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5TdWdnZXN0aW9uOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPnMvU2VjIDQ6IFNlY3VyZSBESENQdjYgT3ZlcnZpZXcvU2VjIDQ6IFNlY3VyZSBE SENQdjYgTWVjaGFuaXNtIE92ZXJ2aWV3Lw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4yKSBBZGQgYSBzZWN0aW9uIG9mIFRlcm1pbm9sb2d5DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlcmUgYXJlIHNvbWUgdGVybXMgdGhhdCBhcmUgbm90 IHdlbGwta25vd24gdG8gdGhlIHJlYWRlcnMuIEl0IHdvdWxkIGJlIGNsZWFyZXIgaWYgYSBzZWN0 aW9uIG9mIFRlcm1pbm9sb2d5IGNvdWxkIGRlZmluZSB0aGVtIGJlZm9yZSB1c2luZy4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgZXhhbXBsZToNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DQTsgbGVhcCBvZiBmYWl0aCBt b2RlOyBUU2xhc3Q7IFJEbGFzdDsgVFNuZXc7IFJEbmV3OyBkcmlmdDsgZXRjLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4zKSBTZWMgMywgMm5kIHBhcmFncmFwaCAoYW5kIGZv bGxvd2VkIHBhcmFzKQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlVubmVjZXNzYXJ5IGluZGVudGF0aW9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjQpIFNlYyA0LCAzcmQgcGFyYQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOyBJbiB0aGlzIGRvY3VtZW50LCB3ZSBpbnRyb2R1Y2UgYSBwdWJsaWMg a2V5IG9wdGlvbiwgYSBjZXJ0aWZpY2F0ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOyBvcHRpb24gYW5kIGEgc2lnbmF0dXJlIG9wdGlvbnMgd2l0aCBh IGNvcnJlc3BvbmRpbmcgdmVyaWZpY2F0aW9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7IG1lY2hhbmlzbS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5zL2Egc2lnbmF0dXJlIG9wdGlvbnMvYSBzaWduYXR1cmUgb3B0 aW9uLw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij41KSBTZWMgNC4xLCBidWxs ZXQgMQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyBB IHNlY29uZCBvcHRpb24gaXMgZGVmaW5lZCB0byBjYXJyeSB0aGUgY2VydGlmaWNhdGUuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cy9BIHNlY29uZCBvcHRpb24v QW5vdGhlciBvcHRpb24vDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Tm90ZTog4oCcQSBzZWNvbmQgb3B0aW9u4oCdIHJlYWRzIGxpa2UgdGhlIHR3byBvcHRpb25z IGFyZSBraW5kIG9mIGxpbmtlZCB0byBlYWNoIG90aGVyLiBCdXQgZnJvbSB0aGUgZGVzY3JpcHRp b24sIHRoZSB0d28gb3B0aW9ucyBzaG91bGQgbm90IGFwcGVhciBhdCB0aGUgc2FtZSB0aW1lLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij42KSBTZWMgNS4xDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7MCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBP UFRJT05fUHVibGljX0tleSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG9wdGlvbi1sZW4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQdWJsaWMgS2V5ICh2YXJpYWJsZSBsZW5ndGgpJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPnMvT1BUSU9OX1B1YmxpY19LZXkvT1BUSU9OX1BLX1BBUkFNRVRFUi8NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+NykgU2VjIDUuMg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDswIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOw0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnwmbmJzcDsmbmJzcDsmbmJzcDsgT1BUSU9OX0Nl cnRpZmljYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3B0aW9u LWxlbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFB1YmxpYyBLZXkgKHZhcmlhYmxlIGxlbmd0aCkmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+cy9PUFRJT05fQ2VydGlmaWNhdGUvT1BUSU9OX0NFUlRfUEFSQU1FVEVSLw0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij44KSBTZWMgNi4yLCB0aGUgbGFzdCBwYXJhDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyZuYnNwOyZuYnNwO0EgUmVsYXktZm9yd2Fy ZCBvciBSZWxheS1yZXBseSBtZXNzYWdlIHdpdGggYW55IFB1YmxpYyBLZXksPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7 Jm5ic3A7IENlcnRpZmljYXRlIG9yIHRoZSBTaWduYXR1cmUgb3B0aW9uIGlzIGludmlsYWQuJm5i c3A7IFRoZSBtZXNzYWdlIFNIT1VMRDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyZuYnNwOyBiZSBkaXNjYXJkZWQgc2ls ZW50bHkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5zL2ludmlsYWQvaW52YWxpZC8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Vc2UgTVVTVCBpbnN0ZWFkIG9mIFNIT1VMRD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+OSkgU2VjIDYuMywgMXN0IHBhcmENCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291 cmllciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7QWN0dWFsbHksIGJlIGRlZmluaXRpb24gaW48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4m bmJzcDsmbmJzcDsgdGhpcyBkb2N1bWVudCwgcmVsYXkgYWdlbnRzIE1VU1QgTk9UIGFkZCBhbnkg c2VjdXJlIERIQ1B2NiBvcHRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+MTApIFNlYyA2LjQsIGJ1bGxldCAyDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkNvdXJpZXIiPiZuYnNwOyZuYnNwOyZuYnNwO28mbmJzcDsgVGhlIHRpbWUgc3RhbXAgaW4gdGhl IGxhc3QgcmVjZWl2ZWQgYW5kIGFjY2VwdGVkIERIQ1B2NiBtZXNzYWdlLiA8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Ro aXMgaXMgY2FsbGVkIFRTbGFzdC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnMvdGltZSBzdGFtcC90 aW1lc3RhbXAvDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjExKSBTZWMgNywg M3JkIHBhcmENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhl IFNlY3VyZSBESENQdjYgbWVjaGFuaXNtIGlzIGJhc2VkIG9uIHRoZSBwcmUtY29uZGl0aW9uIHRo YXQgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6Q291cmllciI+Jm5ic3A7Jm5ic3A7IHJlY2lwaWVudCBrbm93cyB0aGUgcHVibGljIGtleSBv ZiBzZW5kZXJzIG9yIHRoZSBzZW5kZXLigJlzIGNlcnRpZmljYXRlPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7Jm5ic3A7 IGNhbiBiZSB2ZXJpZmllZCB0aHJvdWdoIGEgdHJ1c3QgQ0EuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zL3Rocm91Z2ggYSB0cnVzdCBDQS90aHJv dWdoIGEgdHJ1c3RlZCBDQS8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjEyKSBTZWMgNywg UGFnZSAxNA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj4mbmJzcDsmbmJzcDsmbmJzcDtIb3dl dmVyLCB0aGUgdHdvIGNvbW11bmNpYXRpbmcgbm9kZXMgY2FuIGJlIHN5bmNocm9uaXplZCBpcyBv dXQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpDb3VyaWVyIj4mbmJzcDsmbmJzcDsgc2NvcGUgb2YgdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cy90aGUgdHdvL2hvdyB0aGUg dHdvLw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnMvY29tbXVu Y2lhdGluZyBub2Rlcy9jb21tdW5pY2F0aW5nIG5vZGVzLw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5CZXN0IFJlZ2FyZHMsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+UWkmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5D36713D8A4E7348A7E10DF7437A4B923AE34B8Ankgeml512mbxchi_-- From nobody Fri Apr 4 04:08:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADF41A0442 for ; Fri, 4 Apr 2014 01:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSb_ex0IxseE for ; Fri, 4 Apr 2014 01:35:34 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 545891A0434 for ; Fri, 4 Apr 2014 01:35:31 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id kq14so3140724pab.37 for ; Fri, 04 Apr 2014 01:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=71Krb7eskxpZEEE6ZCSYmWZBWNrkaccSCbs4nnmlosk=; b=WZDb07nrRsV4Fc71O7zp4dj2XPNgjccedJ7fhF1GGsg4hirccdwf1oolw7psgzBuWA f1CpDvbDTkfInSSy3dDSjTGcOq5kLQvRAZ9haormoV/0w3AXOMuOoowGcrfBPwGfh139 9aeOVNwp2jhbJcDclDFhnLyJtOPPaqhUtULyvQbJzVIsGjmLRsALzoFBFGhRZPEaUdNP MC95sQWGry4U4vpzzDx0r2/pAmyB5+Ii9IHW/ZrNzcUCShw1WWSXIxITo/iaMRe0Jasa +nf9LRk4fL7Bl7WWswuq+14+Mdbc5/Tnsr+Z2W0sV0S3jOJ9Wh2NHDT8MBGlKWsZz9Kw qy3Q== X-Received: by 10.66.240.4 with SMTP id vw4mr13421093pac.26.1396600526909; Fri, 04 Apr 2014 01:35:26 -0700 (PDT) Received: from sunqideair.lan ([166.111.68.231]) by mx.google.com with ESMTPSA id yi3sm16189489pbb.51.2014.04.04.01.35.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Apr 2014 01:35:26 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C0096491-D0B2-4B73-AE2A-2AC994B51F15" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Qi Sun In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AE34B8A@nkgeml512-mbx.china.huawei.com> Date: Fri, 4 Apr 2014 16:35:17 +0800 Message-Id: <73511884-93B9-49E8-A21F-27124862B9E9@gmail.com> References: <0608491B-C35F-4145-BD3D-A3D766A5A3E4@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AE34B8A@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/-9Zz1JULWRGmUc58FjzlNIagIc8 X-Mailman-Approved-At: Fri, 04 Apr 2014 04:08:26 -0700 Cc: "" , "draft-ietf-dhc-sedhcpv6@tools.ietf.org" Subject: Re: [dhcwg] Review of draft-ietf-dhc-sedhcpv6-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 08:35:39 -0000 --Apple-Mail=_C0096491-D0B2-4B73-AE2A-2AC994B51F15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Sheng,=20 Yes, correcting description in Sec 6.1 is sufficient. Thanks! Best Regards, Qi On Apr 4, 2014, at 3:52 PM, Sheng Jiang wrote: > Hi, Qi, > =20 > Thanks so much for your carefully review. All editorial comments will = be applied in the next update in a couple of week time. Your technical = comments are also valid, they will be applied too. > =20 > Some explanation for technical point 1, regarding to signature option. = In the section 5.3, the signature =93constructed by using the sender's = private key protects the following sequence of octets: > =20 > 1. The DHCPv6 message header. > =20 > 2. All DHCPv6 options including the Signature > option (fill the signature field with zeroes) > except for the Authentication Option.=94 > =20 > So, the signature option itself, including timestamp is actually = protected. Changing the wrong description in Section 6.1 would be = sufficient to address this comment. > =20 > Regards, > =20 > Sheng > =20 > From: Qi Sun [mailto:sunqi.csnet.thu@gmail.com]=20 > Sent: Thursday, April 03, 2014 5:28 PM > To: > Cc: draft-ietf-dhc-sedhcpv6@tools.ietf.org; liuzilong8266@163.com > Subject: Review of draft-ietf-dhc-sedhcpv6-01 > =20 > Hi all, > =20 > I volunteered to review the document. Here are my comments (sorry if = some of them have been discussed). But most are editorial.=20 > =20 > 1. Technical > 1) About the Signature Option > a) Different description of Signature Option: > Sec 5.3: "It protects the entire DHCPv6 header and options, except for = the Authentication Option.=94=20 > Sec 6.1: "It protects the message header and the message payload and = all DHCPv6 options except for the Signature option itself and the = Authentication Option.=94 > =20 > b) As is described above, Signature option does not protect itself = including the timestamp which will be used to judge the message's = validity. It means attackers can change the timestamp without destroying = the signature. So attackers changes the timestamp of message, then the = recipient will inspect the signature which is "correct" despite the = change of the timestamp. This might cause a replay attack. > =20 > 2) Inequality on the bottom of Page 12 > "TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz" > =20 > What if RDnew < RDlast, maybe caused by a bad clock? In this case, the = inequality holds (so that the message is accepted) but there might be = something wrong. For the security reason, it would be better to drop the = message, IMHO. > =20 > 2. Editorial > 1) Section titles: > Sec 3: Security Overview of DHCPv6 > Sec 4: Secure DHCPv6 Overview > They are kind of close at the first glance. > Suggestion: > s/Sec 4: Secure DHCPv6 Overview/Sec 4: Secure DHCPv6 Mechanism = Overview/ > =20 > 2) Add a section of Terminology > There are some terms that are not well-known to the readers. It would = be clearer if a section of Terminology could define them before using. > For example: > CA; leap of faith mode; TSlast; RDlast; TSnew; RDnew; drift; etc. > =20 > 3) Sec 3, 2nd paragraph (and followed paras) > Unnecessary indentation > =20 > 4) Sec 4, 3rd para > In this document, we introduce a public key option, a certificate > option and a signature options with a corresponding verification > mechanism. > s/a signature options/a signature option/ > =20 > 5) Sec 4.1, bullet 1 > A second option is defined to carry the certificate. > s/A second option/Another option/ > Note: =93A second option=94 reads like the two options are kind of = linked to each other. But from the description, the two options should = not appear at the same time. > =20 > 6) Sec 5.1 > 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_Public_Key | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . Public Key (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > s/OPTION_Public_Key/OPTION_PK_PARAMETER/ > =20 > 7) Sec 5.2 > 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_Certificate | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . Public Key (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > s/OPTION_Certificate/OPTION_CERT_PARAMETER/ > =20 > 8) Sec 6.2, the last para > A Relay-forward or Relay-reply message with any Public Key, > Certificate or the Signature option is invilad. The message SHOULD > be discarded silently. > s/invilad/invalid/ > Use MUST instead of SHOULD? > =20 > 9) Sec 6.3, 1st para > Actually, be definition in > this document, relay agents MUST NOT add any secure DHCPv6 options. > 10) Sec 6.4, bullet 2 > o The time stamp in the last received and accepted DHCPv6 message.=20= > This is called TSlast.=20 > s/time stamp/timestamp/ > =20 > 11) Sec 7, 3rd para > The Secure DHCPv6 mechanism is based on the pre-condition that the > recipient knows the public key of senders or the sender=92s = certificate > can be verified through a trust CA. > s/through a trust CA/through a trusted CA/ > =20 > =20 > 12) Sec 7, Page 14 > However, the two communciating nodes can be synchronized is out of > scope of this work. > s/the two/how the two/ > s/communciating nodes/communicating nodes/ > =20 > Best Regards, > Qi=20 --Apple-Mail=_C0096491-D0B2-4B73-AE2A-2AC994B51F15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Sheng, 

Yes, correcting description in Sec 6.1 = is sufficient. Thanks!

Best = Regards,
Qi

On Apr 4, 2014, at 3:52 = PM, Sheng Jiang <jiangsheng@huawei.com> = wrote:

Hi, Qi,
 
Thanks so = much for your carefully review. All editorial comments will be applied = in the next update in a couple of week time. Your technical comments are = also valid, they will be applied too.
 
Some explanation for technical point 1, regarding to = signature option.  In the section 5.3, the signature =E2=80=9Cconstru= cted by using the sender's private key protects the following sequence = of octets:
 
           &= nbsp;   1. The DHCPv6 message = header.
 
           &= nbsp;   2. All DHCPv6 options including the = Signature
           &= nbsp;   option (fill the signature field with = zeroes)
           &= nbsp;   except for the Authentication = Option.=E2=80=9D
 
So, the = signature option itself, including timestamp is actually protected. = Changing the wrong description in Section 6.1 would be sufficient to = address this comment.
 
Regards,
 
Sheng
 
From: Qi Sun [mailto:sunqi.csnet.thu@gmail.com] 
Sent: Thursday, April 03, 2014 = 5:28 PM
To: <dhcwg@ietf.org>
Cc: draft-ietf-dhc-sedhcpv6@tools.ietf.org; liuzilong8266@163.com
Subject: Review of = draft-ietf-dhc-sedhcpv6-01
 
Hi = all,
 
I volunteered to review the document. Here are my comments = (sorry if some of them have been discussed). But most are = editorial. 
 
1. Technical
1) About the Signature = Option
a) Different description of = Signature Option:
Sec 5.3: "It protects the entire DHCPv6 header and options, = except for the Authentication Option.=E2=80=9D 
Sec 6.1: "It protects the = message header and the message payload and all DHCPv6 options except for = the Signature option itself and the Authentication = Option.=E2=80=9D
 
b) As is described above, Signature option does not protect = itself including the timestamp which will be used to judge the message's = validity. It means attackers can change the timestamp without destroying = the signature. So attackers changes the timestamp of message, then the = recipient will inspect the signature which is "correct" despite the = change of the timestamp. This might cause a replay attack.
 
2) Inequality on the bottom of Page = 12
"TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) = - fuzz"
 
What if RDnew < RDlast, maybe caused by a bad clock? In = this case, the inequality holds (so that the message is accepted) but = there might be something wrong. For the security reason, it would be = better to drop the message, IMHO.
 
2. = Editorial
1) Section titles:
Sec 3: Security Overview of = DHCPv6
Sec 4: Secure DHCPv6 = Overview
They are kind of close at the first = glance.
Suggestion:
s/Sec 4: Secure DHCPv6 Overview/Sec 4: = Secure DHCPv6 Mechanism Overview/
 
2) Add a section of = Terminology
There are some terms that are not well-known to the = readers. It would be clearer if a section of Terminology could define = them before using.
For example:
CA; leap of faith mode; TSlast; RDlast; = TSnew; RDnew; drift; etc.
 
3) Sec 3, 2nd paragraph (and followed = paras)
Unnecessary = indentation
 
4) Sec 4, 3rd para
  In this document, we introduce a = public key option, a certificate
  option and a signature options = with a corresponding verification
  = mechanism.
s/a signature options/a signature = option/
 
5) Sec 4.1, bullet 1
  A second option is defined to = carry the certificate.
s/A second option/Another = option/
Note: =E2=80=9CA second option=E2=80=9D reads like the two = options are kind of linked to each other. But from the description, the = two options should not appear at the same = time.
 
6) Sec 5.1
 0         =           = 1            &= nbsp;      = 2            &= nbsp;      = 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_Public_Key         = |         = option-len          &nbs= p; |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
|          =             &n= bsp;           &nbs= p;            =             &n= bsp;   |
.          =       Public Key (variable = length)           &= nbsp;       = .
.          =             &n= bsp;           &nbs= p;            =             &n= bsp;   .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
s/OPTION_Public_Key/OPTION_PK_PARAMETER/
 
7) Sec 5.2
 0         =           = 1            &= nbsp;      = 2            &= nbsp;      = 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_Certificate         = |         = option-len          &nbs= p; |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
|          =             &n= bsp;           &nbs= p;            =             &n= bsp;   |
.          =       Public Key (variable = length)           &= nbsp;       = .
.          =             &n= bsp;           &nbs= p;            =             &n= bsp;   .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
s/OPTION_Certificate/OPTION_CERT_PARAMETER/=
 
8) Sec 6.2, the last = para
   A =
Relay-forward or Relay-reply message with any Public =
Key,
   Certificate or the Signature option is =
invilad.  The message SHOULD
   be =
discarded silently.
s/invilad/invalid/
Use MUST instead of = SHOULD?
 
9) Sec 6.3, 1st para
   Actually, be definition =
in
   this document, relay agents MUST NOT add any =
secure DHCPv6 options.
10) Sec 6.4, bullet = 2
   o  The time stamp in the last received =
and accepted DHCPv6 message. 
      This is called =
TSlast. =
s/time = stamp/timestamp/
 
11) Sec 7, 3rd para
   The =
Secure DHCPv6 mechanism is based on the pre-condition that =
the
   recipient knows the public key of senders or the =
sender=E2=80=99s certificate
   can be =
verified through a trust CA.
s/through a trust CA/through a trusted = CA/
 
 
12) Sec 7, Page 14
   However, the two communciating nodes can be =
synchronized is out of
   scope of =
this work.
s/the two/how the = two/
s/communciating nodes/communicating = nodes/
 
Best Regards,
Qi 

= --Apple-Mail=_C0096491-D0B2-4B73-AE2A-2AC994B51F15-- From nobody Fri Apr 4 16:24:14 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD1E1A01FD; Fri, 4 Apr 2014 16:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg7YTq9ctAoP; Fri, 4 Apr 2014 16:24:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 402F71A012E; Fri, 4 Apr 2014 16:24:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140404232406.9815.60376.idtracker@ietfa.amsl.com> Date: Fri, 04 Apr 2014 16:24:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/fypaUyvk80lpMLyyX-cHic-dEiU Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dynamic-shared-v4allocation-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 23:24:11 -0000 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 : Dynamic Allocation of Shared IPv4 Addresses Authors : Yong Cui Qiong Sun Ian Farrer Yiu L. Lee Qi Sun Mohamed Boucadair Filename : draft-ietf-dhc-dynamic-shared-v4allocation-00.txt Pages : 13 Date : 2014-04-04 Abstract: This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple, active clients simultaneously, each client being differentiated by a unique set of transport source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included. Due to the nature of IP addresses sharing, some limitations to their applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dynamic-shared-v4allocation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dynamic-shared-v4allocation-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 6 21:25:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF51C1A0672 for ; Sun, 6 Apr 2014 21:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSz5uHwVmRwi for ; Sun, 6 Apr 2014 21:25:27 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B8CD11A0671 for ; Sun, 6 Apr 2014 21:25:27 -0700 (PDT) X-AuditID: c6180641-b7f638e000005a82-b5-534225c65c46 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 54.45.23170.6C522435; Mon, 7 Apr 2014 06:12:55 +0200 (CEST) Received: from [164.48.125.62] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.81) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 7 Apr 2014 00:25:17 -0400 Message-ID: <5342289F.5060801@ericsson.com> Date: Mon, 7 Apr 2014 00:25:03 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Bernie Volz (volz)" , "dhcwg@ietf.org" References: <489D13FBFA9B3E41812EA89F188F018E1AF7A8FE@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AF7A8FE@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZXLonUPe4qlOwQfNpDou7HS2MFstnaDow eUz5vZHVY8mSn0wBTFFcNimpOZllqUX6dglcGUsvn2UueM9ccXrfVuYGxn7mLkZODgkBE4k3 s56yQdhiEhfurQeyuTiEBI4ySuzYPI8FwtnCKLF56lVGkCpeAW2Jx//7mUBsFgEViZ1L34LF 2YAmbdj5GSwuKhAm0X5hJjNEvaDEyZlPWEBsEQEfiTsHX4NtExaIl1jeeBMsLgQU/7F+E1gv p4CvxPv/99m7GDk4mAXsJR5sLQMJMwvISzRvnc0MUa4psXXNd1aIoxUlXhz/yTSBUXAWkm2z ELpnIelewMi8ipGjtDi1LDfdyHATIzAgj0mwOe5gXPDJ8hCjNAeLkjjvl7fOQUIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYOZUFEte131W2mfI62P7mvegnEm/s1vIsfdVytrTg5i1/FW9G sdPrZ+tdWv/m6mxvru2uFrfEjx8Oe2C8bsepVrk71l8m7r0tcUogOXtxzrppp/jqFvlOZcjR SArU+bLvoNQb9huVcSKMJ8wVjpmxh2ez5vddutVr5b9SsKje7uNSk1ibDXqNSizFGYmGWsxF xYkAT9ksvBYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/i5TxFKQZ42wVD5moJfEbuikSr30 Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-04 - respond by April 13, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 04:25:33 -0000 Hi Bernie, On 03/29/2014 10:05 AM, Bernie Volz (volz) wrote: > (WG co-chair hat off) > > I do not feel the document is ready “as is”. Please see my comments at > http://www.ietf.org/mail-archive/web/dhcwg/current/msg15362.html. Thanks a lot for those comments. We will make the reply mandatory with three possible responses, and specify retransmission values. We will include the new text along with any other changes that result from comments during WGLC. Regards Suresh From nobody Sun Apr 6 21:26:06 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CE61A0672 for ; Sun, 6 Apr 2014 21:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id un78e3xtocbh for ; Sun, 6 Apr 2014 21:25:59 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 89E7A1A067A for ; Sun, 6 Apr 2014 21:25:56 -0700 (PDT) X-AuditID: c618062d-b7f948e000000b0c-ed-5342267b862c Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EC.55.02828.C7622435; Mon, 7 Apr 2014 06:15:56 +0200 (CEST) Received: from [164.48.125.62] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.81) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 7 Apr 2014 00:25:49 -0400 Message-ID: <534228C7.20601@ericsson.com> Date: Mon, 7 Apr 2014 00:25:43 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Marcin Siodelski , "Bernie Volz (volz)" , "dhcwg@ietf.org" References: <489D13FBFA9B3E41812EA89F188F018E1AF7A8D9@xmb-rcd-x04.cisco.com> <533A5C2F.2070908@gmail.com> In-Reply-To: <533A5C2F.2070908@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZXLonULdGzSnY4ECPiMXdjhZGi4aHf1ks ls/QdGD2mPJ7I6vHzll32T2WLPnJFMAcxWWTkpqTWZZapG+XwJVx6dIlpoL5KhW/e+8xNjA+ keli5OSQEDCRWHp3NRuELSZx4d56IJuLQ0jgKKPEw00NzBDOFkaJ84c6GUGqeAU0JT6sesba xcjBwSKgIjGhtwYkzAY0aMPOz0wgtqhAmET7hZnMEOWCEidnPmEBsUUEyiVeXDkEFhcWiJdY 3ngTLC4kkClxdP55sF5OoPFfFp1gB7GZBWwlLsy5zgJhy0tsfzuHGaJeU2Lrmu+sEEcrSrw4 /pNpAqPgLCTrZiFpn4WkfQEj8ypGjtLi1LLcdCODTYzAMD0mwaa7g3HPS8tDjNIcLErivF/e OgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYFzFu9Nmzro9bs+/nztx07j0w5ct20Jmf2k/ 0fhshvh8F/mS7EATtyMJL62MsrS09248vU/w4XK2HI+Wic85W4tZZrR84lVYW7f74Y4fTI5b f9ZxXbn8+66k153KpZtyqvqOXXZeoft55mT2zh+ZX/Icl/EvkfTMe9y6uEW/6eSkN2bzOGdu nz1PiaU4I9FQi7moOBEA8Zq2uiECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/ZKIj49SebhMwOcPwKNxu3XFEYns Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-04 - respond by April 13, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 04:26:04 -0000 Hi Marcin, Thanks a lot for your comments. We will get back to you with proposed text changes in the next couple of days. Regards Suresh On 04/01/2014 02:26 AM, Marcin Siodelski wrote: > I have read the document and I think it is not ready yet. > > A couple of comments/questions.... > > I wonder how this would work with multiple DHCP servers receiving > registration requests from a single client? Apparently, there may be a > form of race condition that they will both try to add or remove the > mapping from the DNS. One of them could wait and query DNS to see > whether the particular mapping is in DNS and do not update - which would > mean that the other one has updated DNS. But, that would require some > form of back-off mechanism. So, is this assumed in this document that > there is only one DHCP server performing registration function and > multiple registering servers are out of scope? I would be fine with > that, as long as it is mentioned in the document. > > Section 5.1. > > The > DHCPv6 ADDR-REGISTRATION-REQUEST message MUST contain exactly one > IA_NA option and exactly one FQDN option > > Why is this limited to exactly one IA_NA option? IIRC, RFC4704 allows updates for multiple bindings. A fragment from RFC4704: > > > The Client FQDN option MUST only appear in a message's options field > and applies to all addresses for all IA_NA bindings in the > transaction. > > If there is a good reason for such limitation, it would be useful to explain why only one IA_NA option is allowed. Especially, that one IA_NA may contain multiple addresses anyway. > > Also. section 5.3 seems to be a little contradicting to this: > > > For each IA in the ADDR-REGISTRATION-REQUEST > message for which the server does not succeed in registering, the > server adds an IA option using the IAID from the ADDR-REGISTRATION- > REQUEST message, and includes a Status Code option with the value > RegistrationDenied (TBA3) in the IA option. No other options are > included in the IA option. > > If you only allow one IA_NA, then why do you have to perform "for each". > Perhaps server should discard the packet with multiple IA_NAs? > > IMHO, server should allow multiple IA_NAs, unless there is a good reason > not to. But, that should be explained. > > Section 4. > What does the server do if IA_NA or FQDN is missing? This section only > talks about discarding the message that contains server id. > > Section 5.3. > > In the "normal" exchange with DHCPv6, client MUST include ORO to request > that server returns Client FQDN. By returning the FQDN option, server > may indicate whether or not it performs DNS updates for the client. It > may also send its notion of the FQDN. For example: a client may send > partial FQDN and rely on the server to generate one. There are no such > considerations in the draft. In particular, it is not said whether > client MUST or MUST NOT put ORO in the ADDR-REGISTRATION-REQUEST. Also, > the server's response is optional (which is wrong in my opinion) and so > the server's notion of FQDN is not communicated back to the client. Is > this the intent? From the draft it is unclear in what circumstances the > server will send back RegistrationDenied? Does it include the case when > client sends FQDN that DHCP server doesn't like (e.g. partial), and > instead of generating FQDN for the client (and sending it back in the > FQDN option), server would send RegistrationDenied? > > Sorry for a bit long and blurry comment here, but in section 5. you > mention about "reusing" FQDN option from RFC4704 and I am not sure how > much of RFC4704 (and existing logic for processing FQDN) you intend to > reuse in the addr-registration. > > Marcin > > On 29/03/14 15:04, Bernie Volz (volz) wrote: >> >> Folks, the authors of draft-ietf-dhc-addr-registration >> (http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-04) >> >> feel it's ready for work group last call. Please review this draft and >> indicate whether or not you feel it is ready to be published. >> >> At the time of this writing, there is no IPR reported against this draft. >> >> Tomek and I will evaluate consensus after April 13, 2014. >> >> Thanks, >> >> Bernie & Tomek >> >> >> >> _______________________________________________ >> 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 nobody Mon Apr 7 13:22:59 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FE91A07E9 for ; Mon, 7 Apr 2014 13:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egtUIzxIzgHg for ; Mon, 7 Apr 2014 13:22:51 -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 32BDD1A04B1 for ; Mon, 7 Apr 2014 13:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8039; q=dns/txt; s=iport; t=1396902166; x=1398111766; h=from:to:subject:date:message-id:mime-version; bh=iHTYhUMqLfs9idjDexapvec86voiwZ5aqZb8C6+esQA=; b=BZJmcCw0D5Y7YW9hloIZPL6GnasF9fLf2Hem5OZkpD7a/+dHjbmn2hU1 FmNogmLAgUW2mC6nJ7CLuHPvHJBy8etP2HFAVkNwG9uC/BRbXweyIMwv2 IdPoTq1o1iJaWek6FkGPqAkjfvYrMl/ipzC9hVAeNjlCY2gJNgNVONx9C E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAM8HQ1OtJA2D/2dsb2JhbABZgkJEO1fEI4EqFnSCJQEBAQQtXgEZBAEBCx05FAkJAQQTCIdxDZoXsT8XjkA3gyWBFASaD5ELgXGBP4Ir X-IronPort-AV: E=Sophos;i="4.97,812,1389744000"; d="scan'208,217";a="315857756" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP; 07 Apr 2014 20:22:45 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s37KMj0j032613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Apr 2014 20:22:45 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.206]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 7 Apr 2014 15:22:45 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Reminder - WGLC for draft-ietf-dhc-addr-registration-04 - respond by April 13, 2014 Thread-Index: Ac9SnyHgqAGgr6WsQEiN2gO/L+yPEQ== Date: Mon, 7 Apr 2014 20:22:44 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFAD287@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.252.73] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AFAD287xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/2R66rhXCM4V-iqVvgIihPXOoWfY Subject: [dhcwg] Reminder - WGLC for draft-ietf-dhc-addr-registration-04 - respond by April 13, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 20:22:58 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AFAD287xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a friendly reminder that this WGLC is in progress and responses (in fa= vor of or indicating specific objections) are desired. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Saturday, March 29, 2014 10:04 AM To: dhcwg@ietf.org Subject: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-04 - respond by = April 13, 2014 Folks, the authors of draft-ietf-dhc-addr-registration (http://tools.ietf.o= rg/html/draft-ietf-dhc-addr-registration-04) feel it's ready for work group last call. Please review this draft and indi= cate whether or not you feel it is ready to be published. At the time of this writing, there is no IPR reported against this draft. Tomek and I will evaluate consensus after April 13, 2014. Thanks, Bernie & Tomek --_000_489D13FBFA9B3E41812EA89F188F018E1AFAD287xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a friendly remind= er that this WGLC is in progress and responses (in favor of or indicating s= pecific objections) are desired.

 

-&nb= sp;         Bernie

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Saturday, March 29, 2014 10:04 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-04 - resp= ond by April 13, 2014

 

Folks, the authors of draft-ietf-dhc-addr-registr= ation (http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-04)=

feel it's ready for work group last call. Please = review this draft and indicate whether or not you feel it is ready to be pu= blished.

 

At the time of this writing, there is no IPR repo= rted against this draft.

 

Tomek and I will evaluate consensus after April 1= 3, 2014.

 

Thanks,

Bernie & Tomek

 

--_000_489D13FBFA9B3E41812EA89F188F018E1AFAD287xmbrcdx04ciscoc_-- From nobody Tue Apr 8 04:02:47 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A3E1A02E2 for ; Tue, 8 Apr 2014 04:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZL68w-ih1p8 for ; Tue, 8 Apr 2014 04:02:41 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id DDE071A018D for ; Tue, 8 Apr 2014 04:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5293; q=dns/txt; s=iport; t=1396954955; x=1398164555; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fDgNo19d37YWcuqOnk1HP7+Hc0j9I9mzduu+NpaJx0Y=; b=YnHXhXfDjY049gsJUVCKKS7TMpYnWFCzkYa3jqt+hmzXj3sI/aPTbf3L hHeVEUVlm0mxYTbPo1Lb62BpEgJdGftN4pn5cAVoe54eDUYrZ9c0pF9P7 o8LVKh1+6YmunzQrFEfHqHhpPeEkZGtLD8fOJi55VGK54imS/oQjH/Dkx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAIPWQ1OtJA2N/2dsb2JhbABZgwY7vAWIdoEiFnSCJQEBAQRuGwIBDA0DAQIoByERFAcCCAIEExuHSgMRDcMuDYZrF4xRgggXAQaDHoEUBJZvgW2BNIs9hU+DMA X-IronPort-AV: E=Sophos; i="4.97,817,1389744000"; d="scan'208,217"; a="33917908" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 08 Apr 2014 11:02:34 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s38B2YHN021346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Apr 2014 11:02:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.55]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 06:02:34 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WGLC: draft-ietf-savi-dhcp-22 Thread-Index: AQHPUxW/9DQ8gw8yMUCrlyXouynUJ5sHjeuK Date: Tue, 8 Apr 2014 11:02:34 +0000 Message-ID: <1D2FDCA5-0700-4AF9-A630-F3CB4DD6BE3A@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1D2FDCA507004AF9A630F3CB4DD6BE3Aciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/9b4lRt69FjQZNNPqxqOKa_wqxTc Subject: [dhcwg] Fwd: WGLC: draft-ietf-savi-dhcp-22 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 11:02:46 -0000 --_000_1D2FDCA507004AF9A630F3CB4DD6BE3Aciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please take a look at this document and send any issues to Jean-Michel and/= or savi WG. Begin forwarded message: Resent-From: > From: Jean-Michel Combes > Date: April 8, 2014 at 6:31:17 AM EDT Resent-To: >,= > To: > Cc: Ted Lemon > Subject: Fwd: WGLC: draft-ietf-savi-dhcp-22 Hi, As this document specifies a mechanism strongly based on DHCPv4/v6, I would= appreciate to get feedback from the DHC WG during the WGLC. So, could you, please, forward this WGLC announcement on the DHC WG ML? Thanks in advance for your help. Best regards, JMC, SAVI WG chair. ---------- Forwarded message ---------- From: Jean-Michel Combes > Date: 2014-04-08 12:15 GMT+02:00 Subject: WGLC: draft-ietf-savi-dhcp-22 To: SAVI Mailing List > Cc: ">" >, Ted Lemon > Folks, As it has been deeply modified since the last WGLC (version -06), this is a= new two weeks WGLC for the following document: "SAVI Solution for DHCP" (h= ttp://tools.ietf.org/html/draft-ietf-savi-dhcp-22). Please, don't hesitate to give your opinion (i.e., agreement/disagreement t= o move forward the document, comments, etc.)! Thanks in advance. Best regards, JMC. --_000_1D2FDCA507004AF9A630F3CB4DD6BE3Aciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please take a look at this document and send any issues to Jean-Michel= and/or savi WG.

Begin forwarded message:

Resent-From: <wg-alias-bounces@tools.ietf.org>
From: Jean-Michel Combes <jeanmichel.combes@gmail.com>
Date: April 8, 2014 at 6:31:17 AM EDT
Resent-To: <tomasz.= mrugalski@gmail.com>, <volz@cis= co.com>
To: <dhc-chairs@tool= s.ietf.org>
Cc: Ted Lemon <mellon@fugue.c= om>
Subject: Fwd: WGLC: draft-ietf-savi-dhcp-22

Hi,

As this document specifies a mechanism strongly based on DHCPv4/v6, I would= appreciate to get feedback from the DHC WG during the WGLC.
So, could you, please, forward this WGLC announcement on the DHC WG ML?

Thanks in advance for your help.

Best regards,

JMC, SAVI WG chair.

---------- Forwarded message ----------
From: Jean-Michel Combes <jeanmichel.combes@gmai= l.com>
Date: 2014-04-08 12:15 GMT+02:00
Subject: WGLC: draft-ietf-savi-dhcp-22
To: SAVI Mailing List <savi@ietf.org>
Cc: "<draft-= ietf-savi-dhcp@tools.ietf.org>" <draft-ietf-savi-dhcp@tools.ietf.org>, Te= d Lemon <mellon@fugue.com>

Folks,

As it has been deeply modified since the last WGLC (version -06), this is a= new two weeks WGLC for the following document: "SAVI Solution for DHC= P" (http://tools.ietf.org/html/draft-ietf-savi-dhcp-22).

Please, don't hesitate to give your opinion (i.e., agreement/disagreement t= o move forward the document, comments, etc.)!

Thanks in advance.

Best regards,

JMC.

--_000_1D2FDCA507004AF9A630F3CB4DD6BE3Aciscocom_-- From nobody Tue Apr 8 10:56:01 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCE41A0679 for ; Tue, 8 Apr 2014 10:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E4VSG_JGZHK for ; Tue, 8 Apr 2014 10:55:58 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 30C3F1A0663 for ; Tue, 8 Apr 2014 10:55:58 -0700 (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 3A5131B805A for ; Tue, 8 Apr 2014 10:55:58 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 08B8F19005C; Tue, 8 Apr 2014 10:55:58 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Apr 2014 10:55:57 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <1D2FDCA5-0700-4AF9-A630-F3CB4DD6BE3A@cisco.com> Date: Tue, 8 Apr 2014 13:55:56 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <41DDE37F-1D46-4A1D-9079-CD20D37E9BE7@nominum.com> References: , <1D2FDCA5-0700-4AF9-A630-F3CB4DD6BE3A@cisco.com> To: Bernie Volz X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/8ILS7tpBRm1tXm04Fis6aXlTgtM Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC: draft-ietf-savi-dhcp-22 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 17:55:59 -0000 On Apr 8, 2014, at 7:02 AM, Bernie Volz (volz) wrote: > Please take a look at this document and send any issues to Jean-Michel = and/or savi WG. Just so people know, what this document is is a description of how to = set up a switch so that it tracks DHCP transactions and knows what = addresses have been assigned to what devices attached to its ports. = It's somewhat intricate, and more careful review would be nice. I did = a pretty thorough review, but I'm not the most persnickety of the DHCP = reviewers, so more might help. Please do not review for language unless the language is unclear. The = RFC Editor will be doing that, and it will take a lot of time if people = send in voluminous comments about that. From nobody Tue Apr 8 11:08:01 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B611A0695 for ; Tue, 8 Apr 2014 11:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.622 X-Spam-Level: **** X-Spam-Status: No, score=4.622 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NorkLZCdySCK for ; Tue, 8 Apr 2014 11:07:49 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 85F0F1A0694 for ; Tue, 8 Apr 2014 11:07:49 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so1341362wgg.26 for ; Tue, 08 Apr 2014 11:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=V8W9Gn6qq5Ap/XbkkUs2OFgUllCyvsFastNIL4NnhVY=; b=XPqYxM8PnpAp3rotyDagEqxH/t8cIn4a6KZ6Tlh+tdPVGca81CWQ3UZN4c4+LlvmM5 5KuWEgeEt0G6TvU2AkTApmzyrxgjuSRwLnAd+Z+3dQuszRdhlR7QLQjA729CcuQ8gCdH cQL0Az+CawCWY3P+L6GeAz5h0GIaNrHKHvQinYnyi8I9ST83+8dAIF+pnsSXCKa7GWF0 YeGcA99rTpXlfKekktKfT8EworvukGhOU8Ni0jQmyqyDvQfLflzowQ1GYENE8hhYuxSF eqE1dWXJpoQgflkIpC3hIr0Iv3oAOqsd2hyx6fTl4vSKSlwV8nrlm0fTJldb2d9ww/0D vhEw== MIME-Version: 1.0 X-Received: by 10.180.24.134 with SMTP id u6mr33446898wif.41.1396980468941; Tue, 08 Apr 2014 11:07:48 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.101 with HTTP; Tue, 8 Apr 2014 11:07:48 -0700 (PDT) Date: Tue, 8 Apr 2014 11:07:48 -0700 X-Google-Sender-Auth: KwBhvhgV654vqkg3rP98ZEzjpb8 Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: draft-ietf-dhc-topo-conf@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/tGODpj8_TWWfIbkGFZZyeA6kRsU Cc: "dhcwg@ietf.org" Subject: [dhcwg] comments on ietf-dhc-topo-conf-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:07:51 -0000 I have some small (and maybe a bit out of scope) comments on the draft. - page 6 (Section 3) it states: [...] If for whatever reason that is not feasible (e.g. because the relay agent does not have a global address), the relay agent includes an interface-id option that identifies the link clients are connected to. In the "e.g." part, "the relay agent does not have a global address" means it doesn't have a global address configured on the client-facing interface, right? (Otherwise it's very unlikely for the relay agent to reach DHCPv6 servers). But this sentence could also read as if the relay agent doesn't have any global address on any of its interfaces. Maybe it's not that confusing in the entire context, but I think it's better to revise it so it will be even much less confusing. - and on the next sentence: [...] It is up to administrator to make sure that the interface-id is unique within his administrative domain. Is it expected that an administrator would use interface-id's unique even outside of the relay agent? While RFC 3315 doesn't seem to be very specific, I thought interface-id's would be generally only unique within that particular relay agent (an DHCPv6 relay agent implementation I previously worked on used the OS interface index for the interface-id). While this sentence is not incorrect since it only says "it's up to admin", the tone of this sentence is a bit surprising to me, and I wonder what's the common practice in other implementations and actual deployments. - also in Section 3 (page 7), this paragraph isn't very understandable to me: In all cases, then, the DHCP server will have a link-identifying IP address, and in some cases it may also have a link-specific identifier. It should be noted that there is no guarantee that the link-specific identifier will be unique outside the scope of the link-identifying IP address. What's "link-specific identifier"? Is this a higher level concept that means - global address for the link-address field when provided, or - the interface-id option value when provided or mandated ? The second sentence is also not really clear to me...what does "outside the scope of the link-identifying IP address" mean? Usually "the link-identifying IP address" should be global, so there is basically no "outside the scope" of it in the first place. I guess these are mostly an editorial matter rather than a technical issue, but in its current form this paragraph is very confusing to me. - In Section 8, it states: [...] When changes are made to the DNS server, these changes are immediately and automatically adopted by the DHCP server. I'm afraid "immediately" is not very accurate, since it's more likely that the DHCP server actually uses some caching server and a change at the DNS server (or more accurately, zone) won't be visible to the DHCP server until the cache expires. Of course, it's the DNS admin's responsibility to make sure that the cached information is valid until all cache of it expires, but that's different from the new information being "immediately adopted" by the DHCP server. Also related, this paragraph actually talks about two different types of DNS servers (or their administrators"): the caching DNS server that the DHCP server uses and the authoritative DNS server that manages the information that the DHCP server would ultimately need. It would probably be clearer if this paragraph differentiates these two types of DNS servers according to the appropriate context. -- JINMEI, Tatuya From nobody Wed Apr 9 12:33:24 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201141A0435 for ; Wed, 9 Apr 2014 12:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH9DT2st6z5O for ; Wed, 9 Apr 2014 12:33:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id A20001A0265 for ; Wed, 9 Apr 2014 12:33:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E149418000B; Wed, 9 Apr 2014 12:33:12 -0700 (PDT) To: mellon@nominum.com, sommerfeld@sun.com, brian@innovationslab.net, ted.lemon@nominum.com, volz@cisco.com, tomasz.mrugalski@gmail.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140409193312.E149418000B@rfc-editor.org> Date: Wed, 9 Apr 2014 12:33:12 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/FDiLQQCft975co8ZYJnK90vuNB4 Cc: dhcwg@ietf.org, samir@iniche.com, rfc-editor@rfc-editor.org Subject: [dhcwg] [Editorial Errata Reported] RFC4361 (3954) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:33:23 -0000 The following errata report has been submitted for RFC4361, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4361&eid=3954 -------------------------------------- Type: Editorial Reported by: Samir Sawhney Section: 7 Original Text ------------- "Some DHCP servers work around this problem for the common case where the boot Programmable Read Only Memory (PROM) presents no client identifier, and the operating system DHCP client presents a client identifier constructed from the Message Authentication Code (MAC) address of the network interface..." Corrected Text -------------- "Some DHCP servers work around this problem for the common case where the boot Programmable Read Only Memory (PROM) presents no client identifier, and the operating system DHCP client presents a client identifier constructed from the Media Access Control (MAC) address of the network interface..." Notes ----- The sentence (included above) from Section 7 of RFC 4361 provides an incorrect expansion of the MAC acronym (Message Authentication Code). Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4361 (draft-ietf-dhc-3315id-for-v4-05) -------------------------------------- Title : Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) Publication Date : February 2006 Author(s) : T. Lemon, B. Sommerfeld Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From nobody Wed Apr 9 12:36:06 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EC51A0444; Wed, 9 Apr 2014 12:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67xD2Bep0kiA; Wed, 9 Apr 2014 12:36:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id AB1FC1A0435; Wed, 9 Apr 2014 12:36:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0BD2D18000B; Wed, 9 Apr 2014 12:35:55 -0700 (PDT) To: samir@iniche.com, mellon@nominum.com, sommerfeld@sun.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140409193556.0BD2D18000B@rfc-editor.org> Date: Wed, 9 Apr 2014 12:35:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/XeLOVi807rdT2uHvMVRqmUu9Po0 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org, ted.lemon@nominum.com, iesg@ietf.org Subject: [dhcwg] [Errata Verified] RFC4361 (3954) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:36:01 -0000 The following errata report has been verified for RFC4361, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4361&eid=3954 -------------------------------------- Status: Verified Type: Editorial Reported by: Samir Sawhney Date Reported: 2014-04-09 Verified by: Ted Lemon (IESG) Section: 7 Original Text ------------- "Some DHCP servers work around this problem for the common case where the boot Programmable Read Only Memory (PROM) presents no client identifier, and the operating system DHCP client presents a client identifier constructed from the Message Authentication Code (MAC) address of the network interface..." Corrected Text -------------- "Some DHCP servers work around this problem for the common case where the boot Programmable Read Only Memory (PROM) presents no client identifier, and the operating system DHCP client presents a client identifier constructed from the Media Access Control (MAC) address of the network interface..." Notes ----- The sentence (included above) from Section 7 of RFC 4361 provides an incorrect expansion of the MAC acronym (Message Authentication Code). -------------------------------------- RFC4361 (draft-ietf-dhc-3315id-for-v4-05) -------------------------------------- Title : Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) Publication Date : February 2006 Author(s) : T. Lemon, B. Sommerfeld Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From nobody Wed Apr 9 12:36:37 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B131A045F for ; Wed, 9 Apr 2014 12:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu8sot-5dlE3 for ; Wed, 9 Apr 2014 12:36:34 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 921F21A044F for ; Wed, 9 Apr 2014 12:36:34 -0700 (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 55A731B806B for ; Wed, 9 Apr 2014 12:36:34 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4E67519005C; Wed, 9 Apr 2014 12:36:34 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Apr 2014 12:36:34 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <20140409193312.E149418000B@rfc-editor.org> Date: Wed, 9 Apr 2014 15:36:34 -0400 Content-Transfer-Encoding: 7bit Message-ID: <79896724-282C-45D7-A206-4B7395F75E20@nominum.com> References: <20140409193312.E149418000B@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/3gxAgS1KJMhCCGuqSuUXHROGAHs Cc: Brian Haberman , Bernie Volz , sommerfeld@sun.com, dhcwg@ietf.org, samir@iniche.com Subject: Re: [dhcwg] [Editorial Errata Reported] RFC4361 (3954) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:36:35 -0000 Oy. I don't know how that happened. Thanks for pointing out the error. From nobody Wed Apr 9 12:52:38 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14321A03BC for ; Wed, 9 Apr 2014 12:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv-xGoPxMu9I for ; Wed, 9 Apr 2014 12:52:31 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8381A0232 for ; Wed, 9 Apr 2014 12:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=645; q=dns/txt; s=iport; t=1397073151; x=1398282751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GeEgDr/uKzVuzzRBl3hv4eevL7jOYuvhnMQDVAyvqz4=; b=Ew3ZWDuItl0tb8qvYwj3Dxs0/CQkxZkVJz5MLWuJ3fXSOF83lE/jhe39 WsM5xF3PYhhfmBwSM8SpkOrpBWf+AItqcfvDsA84yC5HIr09uz537wfZ6 vNpvKUoh7QvccXHrZeJBSdSAvM9qqCL0EDoyQP1c98VftUDZ6Fsbxu9aM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAHWkRVOtJA2M/2dsb2JhbABZgwY7V7xYhzWBIxZ0giUBAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIh3QNzSYTBI47MQcGgx6BFAEDqyCDMIIr X-IronPort-AV: E=Sophos;i="4.97,828,1389744000"; d="scan'208";a="34406336" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP; 09 Apr 2014 19:52:30 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s39JqT4F021841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Apr 2014 19:52:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.62]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 9 Apr 2014 14:52:29 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , RFC Errata System Thread-Topic: [dhcwg] [Editorial Errata Reported] RFC4361 (3954) Thread-Index: AQHPVCqQLPb6ioTIXEqKxSVHuVcOOZsKAYQA//+wQYA= Date: Wed, 9 Apr 2014 19:52:28 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFCD7EA@xmb-rcd-x04.cisco.com> References: <20140409193312.E149418000B@rfc-editor.org> <79896724-282C-45D7-A206-4B7395F75E20@nominum.com> In-Reply-To: <79896724-282C-45D7-A206-4B7395F75E20@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/PY3ia6Z02fnaEgfIBBcXXfDPNFI Cc: "dhcwg@ietf.org" , Brian Haberman , "sommerfeld@sun.com" , "samir@iniche.com" Subject: Re: [dhcwg] [Editorial Errata Reported] RFC4361 (3954) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:52:35 -0000 Looks like RFC Editor added a definition for MAC - it wasn't in the last ve= rsion of the draft. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, April 09, 2014 3:37 PM To: RFC Errata System Cc: Brian Haberman; Bernie Volz (volz); sommerfeld@sun.com; dhcwg@ietf.org;= samir@iniche.com Subject: Re: [dhcwg] [Editorial Errata Reported] RFC4361 (3954) Oy. I don't know how that happened. Thanks for pointing out the error. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Apr 9 13:06:54 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0E91A00DC for ; Wed, 9 Apr 2014 13:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH32JdVWxGuY for ; Wed, 9 Apr 2014 13:06:46 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 64B4E1A01E7 for ; Wed, 9 Apr 2014 13:06:46 -0700 (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 1E2881B806B for ; Wed, 9 Apr 2014 13:06:46 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 05A7719005C; Wed, 9 Apr 2014 13:06:46 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Apr 2014 13:06:46 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFCD7EA@xmb-rcd-x04.cisco.com> Date: Wed, 9 Apr 2014 16:06:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140409193312.E149418000B@rfc-editor.org> <79896724-282C-45D7-A206-4B7395F75E20@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1AFCD7EA@xmb-rcd-x04.cisco.com> To: Bernie Volz X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/vfspt_mfW1Xy14XHo9f-G1-AcFk Cc: "dhcwg@ietf.org" , Brian Haberman , "sommerfeld@sun.com" , "samir@iniche.com" , RFC Errata System Subject: Re: [dhcwg] [Editorial Errata Reported] RFC4361 (3954) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:06:51 -0000 On Apr 9, 2014, at 3:52 PM, Bernie Volz (volz) wrote: > Looks like RFC Editor added a definition for MAC - it wasn't in the = last version of the draft. Yup, but we didn't catch it in AUTH48. :( From nobody Thu Apr 10 19:33:19 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95841A0013 for ; Thu, 10 Apr 2014 19:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERaTxIOgRTqk for ; Thu, 10 Apr 2014 19:33:13 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEAB1A000A for ; Thu, 10 Apr 2014 19:33:13 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id r10so4669434pdi.30 for ; Thu, 10 Apr 2014 19:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=Qrmh5mM/lvREHE4Tw17aAh8ST1D3dcmXRNOY/AH05KY=; b=Z8zTk8tihYufuvriwRB9RSjhKqdKSrfBGYpau7oIjwDcwSMGgjCxk0vpPt0PBYws/e w5x/znzksiy6ylYwPAMIOG1qah+nEzH7hUmm1leiOj0Z8M54KdT2JMuH2W09ycgsBoS+ oxnvzNuwTWcNr1kkEmczHwatXgx+S7sSFQv+/KKYz20bfyV4LQm7NJ8seSHUMrr/VIxH bKOsea0pHyZGBfQI64GY/BftACDX/WtP7d1H1PkrnkH0oPAun49aR6iAweIDcV8Jbpjg OGnAQroPOqpzRSpaaKshq/4e7ffcIkjFT6YInvyXAM1b0ieKbZsY5FH6Zw5TsNiBNL2G +8Zg== X-Received: by 10.67.13.134 with SMTP id ey6mr23789694pad.44.1397183592110; Thu, 10 Apr 2014 19:33:12 -0700 (PDT) Received: from [192.168.1.185] ([166.111.68.233]) by mx.google.com with ESMTPSA id op3sm12100483pbc.40.2014.04.10.19.33.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 19:33:11 -0700 (PDT) From: Qi Sun Content-Type: multipart/alternative; boundary="Apple-Mail=_14E92A0D-39D3-4337-92F4-6197787C9A9C" Date: Fri, 11 Apr 2014 10:33:01 +0800 References: <20140404232406.9815.17014.idtracker@ietfa.amsl.com> To: "" Message-Id: <9915C9D9-03D9-4019-BE2A-E176133DA5C9@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/gm3T3jm8fDDPkFG7nTFciG6365o Subject: [dhcwg] Review request for draft-ietf-dhc-dynamic-shared-v4allocation-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 02:33:18 -0000 --Apple-Mail=_14E92A0D-39D3-4337-92F4-6197787C9A9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all,=20 After the adoption of this document, we have submitted a new version, = covering comments gathered in London.=20 The major changes are: 1) Clean up the text through the document, especially the Introduction = section 2) Add a section of Terminology 3) Remove the =93updates RFC2131=94 and merge the related text/sections = into behaviour descriptions 4) In section 5.1, add consideration that the server only has one = address pool for shared address allocation 5) Correct some typos Could you please review the document? Thanks a lot! Best Regards, Qi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-dhc-dynamic-shared-v4allocation-00.txt > Date: April 5, 2014 at 7:24:06 AM GMT+8 > To: "Qiong Sun" , Yiu L. Lee = , "Yiu Lee" , = Qiong Sun , Yong Cui = , Mohamed Boucadair = , Ian Farrer , "Qi = Sun" , Qi Sun = , "Ian Farrer" , = "Mohamed Boucadair" , "Yong Cui" = >=20 >=20 > A new version of I-D, = draft-ietf-dhc-dynamic-shared-v4allocation-00.txt > has been successfully submitted by Qi Sun and posted to the > IETF repository. >=20 > Name: draft-ietf-dhc-dynamic-shared-v4allocation > Revision: 00 > Title: Dynamic Allocation of Shared IPv4 Addresses > Document date: 2014-04-04 > Group: dhc > Pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-dhc-dynamic-shared-v4alloca= tion-00.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-dhc-dynamic-shared-v4allocatio= n/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-dhc-dynamic-shared-v4allocation-00 >=20 >=20 > Abstract: > This memo describes the dynamic allocation of shared IPv4 addresses > to clients using DHCPv4. Address sharing allows a single IPv4 > address to be allocated to multiple, active clients simultaneously, > each client being differentiated by a unique set of transport source > port numbers. The necessary changes to existing DHCPv4 client and > server behavior are described and a new DHCPv4 option for > provisioning clients with shared IPv4 addresses is included. >=20 > Due to the nature of IP addresses sharing, some limitations to their > applicability are necessary. This memo describes these limitations > and recommends suitable architectures and technologies where address > sharing may be utilized. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_14E92A0D-39D3-4337-92F4-6197787C9A9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = all, 

After the adoption of this document, we = have submitted a new version, covering comments gathered in = London. 

The major changes = are:
1) Clean up the text through the document, especially the = Introduction section
2) Add a section of Terminology
3) Remove the = =93updates RFC2131=94 and merge the related text/sections into behaviour = descriptions
4) In section 5.1, add consideration that the server = only has one address pool for shared address allocation
5) Correct = some typos

Could you please review the = document? Thanks a lot!

Best = Regards,
Qi

Begin forwarded message:

Subject: = New Version = Notification for = draft-ietf-dhc-dynamic-shared-v4allocation-00.txt
Date: April 5, 2014 at 7:24:06 AM = GMT+8


A new version of I-D, = draft-ietf-dhc-dynamic-shared-v4allocation-00.txt
has been = successfully submitted by Qi Sun and posted to the
IETF = repository.

Name: = draft-ietf-dhc-dynamic-shared-v4allocation
Revision: = 00
Title: Dynamic Allocation of Shared IPv4 = Addresses
Document date: 2014-04-04
Group: = dhc
Pages: 13
URL: =            http://www.ietf.org/internet-drafts/draft-ietf-dhc-dy= namic-shared-v4allocation-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-dhc-dynamic-shared= -v4allocation/
Htmlized:       http://tools.ietf.org/html/draft-ietf-dhc-dynamic-shared-v4allocat= ion-00


Abstract:
  This memo describes the = dynamic allocation of shared IPv4 addresses
  to clients = using DHCPv4.  Address sharing allows a single IPv4
=   address to be allocated to multiple, active clients = simultaneously,
  each client being differentiated by a = unique set of transport source
  port numbers.  The = necessary changes to existing DHCPv4 client and
  server = behavior are described and a new DHCPv4 option for
=   provisioning clients with shared IPv4 addresses is = included.

  Due to the nature of IP addresses sharing, = some limitations to their
  applicability are necessary. =  This memo describes these limitations
  and = recommends suitable architectures and technologies where address
=   sharing may be utilized.





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

The IETF = Secretariat



= --Apple-Mail=_14E92A0D-39D3-4337-92F4-6197787C9A9C-- From nobody Fri Apr 11 08:30:09 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD95B1A06E7 for ; Fri, 11 Apr 2014 08:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7DmyCw6fdAk for ; Fri, 11 Apr 2014 08:30:04 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 11D5E1A069B for ; Fri, 11 Apr 2014 08:30:04 -0700 (PDT) Received: from [IPv6:2001:470:88a3::b8bd:1281:669e:a254] (unknown [IPv6:2001:470:88a3:0:b8bd:1281:669e:a254]) by toccata.fugue.com (Postfix) with ESMTPSA id B915D2380CB4; Fri, 11 Apr 2014 11:30:00 -0400 (EDT) From: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Apr 2014 11:29:58 -0400 Message-Id: To: draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/MNLPN-iOoEJ01WMR19Lps8k-NKQ Cc: DHC WG Subject: [dhcwg] AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 15:30:07 -0000 Page 4, paragraph 3: OLD: DHCP clients may be running on CPE devices, end hosts or any other device that supports the DHCP client function. At the time of writing, DHCP clients on CPE devices are comparatively easier to modify than those implemented on end hosts. As a result, this document uses the CPE as an example for describing the mechanism. This does not preclude any end-host, or other device requiring IPv4 configuration, from implementing DHCPv4 over DHCPv6 in the future. NEW: DHCP clients may be running on CPE devices, end hosts or any other device that supports the DHCP client function. This document uses the CPE as an example for describing the mechanism. This does not preclude any end-host, or other device requiring IPv4 configuration, from implementing DHCPv4 over DHCPv6 in the future. The assertion that CPE devices are easier than hosts isn't precisely = true, although I understand what you mean. In any case, it's not = necessary to say this, and it's likely to get a DISCUSS, so why not just = take it out? :) In section 7: A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST message to either a broadcast or unicast address depending on its state. For example, a client in the RENEWING state uses a unicast address to contact the DHCPv4 server to renew its lease. A client in the REBINDING state uses a broadcast address. If there is a DHCPv4 relay agent in the middle, a client in the RENEWING state may send a DHCPREQUEST message to the unicast address of the relay agent. In such a case, the server is unable to determine whether the client sent the message to a unicast or broadcast address and thus the server may be unable to correctly determine the client's state. [RFC5010] introduced the "Flags Suboption" that relay agents add to relayed messages to indicate whether broadcast or unicast was used by the client. You say that the client unicasts to the relay agent in the RENEWING = state, but it actually unicasts to the DHCP server. Last paragraph on page 9: The server MAY include the 4o6 Server Address option in its response to the client. If the client receives this option, it MUST enable the DHCPv4-over-DHCPv6 function. The client MUST NOT enable the DHCPv4-over-DHCPv6 function if the server does not include the 4o6 I think you should say "If the client receives this option, it enables = the DHCPv4-over-DHCPv6 function." I don't think you need a MUST there. = The MUST NOT is necessary, however. Same paragraph, top of page 10: Server Address option in its response. If the client does not receive this option and DHCPv4 over DHCPv6 is already enabled, the client MUST disable the DHCPv4-over-DHCPv6 function. This is underspecified=97a client may be talking to more than one DHCPv6 = server, and may have more than one DHCPv6-derived configuration active = at the same time. I think you need something like this: Server Address option in its response. If the DHCPv6 configuration that contained the 4o6 Server Address option subsequently expires, = the client MUST disable the DHCPv4-over-DHCPv6 function. If, when the DHCPv6 configuration that contained the 4o6 Server Address option is renewed, the renewed configuration does not contain a 4o6 Server = Address option, the client MUST disable the DHCPv4-over-DHCPv6 function. It is possible in a multi-homed configuration for there to be more = than one DHCPv6 configuration active at the same time that contains a 4o6 Server Address option. In this case, the configurations are treated as being independent, so that when any such configuration is active, = a DHCPv4-over-DHCPv6 function may be enabled for that configuration. An implementation may also treat such configurations as being exclusive, such that only one is kept active at a time. In this = case, the client keeps the same configuration active continuously as long as it is valid. If that configuration becomes invalid but one or = more other configurations remain valid, the client activates one of the remaining valid configurations. Which strategy to follow is dependent on the implementation: keeping multiple configurations active at the same time may provide useful redundancy in some applications, but may be needlessly complex in other cases. Please let me know what you think. I would like to last-call this = document once we've addressed the above issues. From nobody Fri Apr 11 10:37:31 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B84A1A0286 for ; Fri, 11 Apr 2014 10:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OiLdyWVO8h8 for ; Fri, 11 Apr 2014 10:37:26 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id DBD351A070D for ; Fri, 11 Apr 2014 10:37:25 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id c41so4401358eek.36 for ; Fri, 11 Apr 2014 10:37:24 -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=uI1ipDDCymfe8i8+5g+3QPOZpZgSp99OGHS62RP7P4c=; b=VPo1tuHHELiRoHDsJDHtN2HEUZH9DevbIygzuvWeeLBfiJVfEBYMmpMI769RB9sED5 Z6Eb9aJvQx8UAlc2oq7zjk83J/bImthyJFhw00KXJXcf5GwDLfO/FaXOZQ0MiWBo2oil 7xqB+FuIvXGNqO3fBnRnMMFFNiZnzizV/WOOxiw4WNRwOwmRwl1+9vfclYaZOFHPWC9N HGiQ6JsBf+wRK0Mw5spSUwio8EwS4g9mi8C9wDlYptfcGyibeYTf17PMhXGOJjZQNGeO cwHXJ/YcSyS5ZaCKtolzIRBaIeE7dOkc2HjtUmLtOVmwREIK0verv0SxvNWlAOmxJiOb xU7Q== X-Received: by 10.15.51.141 with SMTP id n13mr30700043eew.17.1397237844004; Fri, 11 Apr 2014 10:37:24 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id q49sm19120134eem.34.2014.04.11.10.37.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 10:37:22 -0700 (PDT) Message-ID: <5348284F.4060307@gmail.com> Date: Fri, 11 Apr 2014 19:37:19 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Bernie Volz (volz)" , "dhcwg@ietf.org" References: <489D13FBFA9B3E41812EA89F188F018E1AF08ACE@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AF08ACE@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140411193719528 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/WSG2kJt4PwHe-NWNQF0q57iZk54 Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:37:28 -0000 On 13.03.2014 03:36, Bernie Volz (volz) wrote: > This WGLC is for draft-ietf-dhc-dhcpv6-load-balancing-01. Please send > your comments by March 31, 2014. If you do not feel this document should > advance, please state your reasons why. Apologies for late response, I was on vacation. I did carefully review draft-ietf-dhcpv6-load-balancing-01 and have some comments. The text mostly addresses my previous concerns, but there are still some minor corrections to be made. I support this document moving forward and all issues mentioned below can be fixed in updated revision after WGLC. Even though the list may seem a bit long, these are really easy to fix things. 1. I think you can drop the "DHC" from the title. It's name of the working group, not the algorithm. Or even make the title shorter and also drop "Algorithm". "Load Balancing for DHCPv6" is short and gets the message across. 2. The new text in Introduction section mentions servers load and refers to section 5.3 of RFC6853. That section mentions client requirements. You probably meant some other section? 3. In section 3 the new text says: "LEASEQUERY [RFC5007] messages with a query based on IP SHOULD NOT have load balancing applied to them." I would make it MUST NOT. Also "LEASEQUERY and its extensions...". That's sort of obvious that bulk and active leasequery are out of scope for load balancing as they are TCP based, but it's better to be explicit here. 4. "LEASEQUERY messages with a query based on Client ID SHOULD have load balancing applied to them". This one is interesting. I would assume that leasequery messages are sent to specific server directly, so they are outside of scope for load balancing. Furthermore, I think it is legal to send QUERY_BY_CLIENTID queries over TCP connection. Obviously, load balacing is out of scope for any TCP connections. I don't have any strong opinion here, but I think leasequery should be not load balanced at all, regardless of the query type. I talked about this with Bernie and he seems to agree with that. If you still want to keep that text, I think it should say "LEASEQUERY message with a QUERY_BY_CLIENTID that are sent over UDP SHOULD have load balancing applied to them." 5. Also in section 3: "Load balancing only applies to incoming UDP DHCPv6 messages that servers would normally process: SOLICIT, REQUEST, CONFIRM, RENEW, REBIND, RELEASE, DECLINE, INFORMATION-REQUEST, and RECONFIGURE-REQUEST [RFC6977]." That's an unfortunate choice of words. The text may be interpreted as if these were the only messages that server processes, which is not true. Server will process any messages that it received, including LEASEQUERY, RELAY-FORW and others. Perhaps adding "client-originated UDP DHCPv6 messages" would be better? Or saying "Load balancing only applies to the following incoming UDP DHCPv6 messages:"? 6. Still in section 3: "DHCPV4-QUERY [I-D.ietf-dhc-dhcpv4-over-dhcpv6] messages SHOULD NOT be load balanced, but should be subject to DHCPv4 load balncing, if the server supports it.". Did you want the second "should" to be capitalized? That one is interesting. Right now the DHCPv6 relay does not need to do any special about DHCPv4-over-DHCPv6 messages, just forward them towards the server (it may do fancy things, but it doesn't have to). With this statement, suddenly it becomes much more complex, as the DHCPv6 relay should become DHCPv4 aware, DHCPv4 LB aware and have separate configuration for DHCPv4 LB. Nowadays, realistically speaking relays which do LB for DHCPv6 will also do LB for DHCPv4. But this may not be the case in a decade or so. 7. As I pointed out earlier (http://www.ietf.org/mail-archive/web/dhcwg/current/msg14316.html), it would be good to mention in the security considerations that if the hash buckets are misconfigured, some clients would be ingored. It is not a security threat per se, just a new failure mode that is introduced by this draft. Personally, I think it is worth mentioning, but I won't insist on it if you think otherwise. 8. There is an informative reference to I-D.ietf-dhc-dhcpv4-over-dhcpv6, but the normative text uses it. I'm afraid this is a normative, not an informative reference. It's ok to have normative references to other drafts. It introduces a dependency, but dhcpv4-over-dhcpv6 is sent to IESG already, it shouldn't delay this work. Tomek From nobody Fri Apr 11 10:46:21 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86AB1A072E for ; Fri, 11 Apr 2014 10:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LJHhMSVftEj for ; Fri, 11 Apr 2014 10:46:11 -0700 (PDT) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 325931A0738 for ; Fri, 11 Apr 2014 10:46:11 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id d17so4430188eek.32 for ; Fri, 11 Apr 2014 10:46:09 -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=z5YffJFRdx3zcXWYDNQtRksMUuTgGsUm78Y+X/zoXsE=; b=d2tUho2ZlPWiofOku/r8/jkG9iuwtvyhAcFd3YnPTxqhJPaD+VrjNREiSZmsvdW7Uq vI5eBwWVI/6J7WxFRkazAR48YEqYEHLh4DVQ1palWw25YeNYydA380cJMEB5mpAcK36k 52su4orE84HaH4SfNDhlP4rkaZ0SzLaQDGZ0uplRVlnXKgO6mHZvOWwHWw/hyW32YbM0 VlpWJzdtNH6Fbdaea5ZKItgq10pxPUjSLpf6Q1ypaPyU4RsGX8cOvcFDdsz9o8tbLyHQ e+EtxPkFPip7ywtIpoJwqRN4GqGieOgthaHt35kPgbItMFeIc0/Ho7G0BLDg02BcIxWT mTMA== X-Received: by 10.15.75.9 with SMTP id k9mr3717190eey.110.1397238369455; Fri, 11 Apr 2014 10:46:09 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id e42sm19176720eev.32.2014.04.11.10.46.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 10:46:08 -0700 (PDT) Message-ID: <53482A5D.5050900@gmail.com> Date: Fri, 11 Apr 2014 19:46:05 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E1AF08ACE@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AF08ACE@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140411194605858 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/u92zQK5l45_DBq0rZTnCbbJsLdU Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01: Passed X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:46:12 -0000 On 13.03.2014 03:36, Bernie Volz (volz) wrote: > This WGLC is for draft-ietf-dhc-dhcpv6-load-balancing-01. Please send > your comments by March 31, 2014. If you do not feel this document should > advance, please state your reasons why. Apologies for a bit of delay with wrapping this one out. Chairs discussed this WGLC. Even though the number of responses was a bit low, this second WLGC is on a draft that was very similar to the previous WGLC that we had over a year ago. Furthermore, this is an application of a well known and operationally proven algorithm to DHCPv6 and there was never any opposition for this work. Hence we declare this WGLC to be successful. Some minor issues were raised, so an updated revision is needed. Andre, please address them and upload -02. Thank you to everyone who responded to this WGLC. Bernie & Tomek From nobody Fri Apr 11 11:14:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9311E1A075C for ; Fri, 11 Apr 2014 11:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwoXp6BbstCZ for ; Fri, 11 Apr 2014 11:14:30 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CE8461A074C for ; Fri, 11 Apr 2014 11:14:29 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so4402274eek.17 for ; Fri, 11 Apr 2014 11:14:27 -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 :content-type:content-transfer-encoding; bh=p1wTvzTpMwBND7wg6kZvNDFRWpFKKUPDJ02KDjdT4jk=; b=zSUpa5fuO89d7j138yOhi9QK5Y5h8aX2KlM75Md/zeRY8sxDLPREhHjBrnlDplP5OQ y3I4BljNjRL+zT86/nYizOvO+a4kO5br8cXwx1fRcFdu/qTIUdRUa9iKENsJxomguEPN YWGQWV2/dqLzVSbpnecAJDvGI9JQUtlXdrWNL3hF0rQnlYteZwhonlznvfY45JyQSQq5 vXgVW2bZtdNzzLmhlu2xslnUqYbVAS7f71H7w7YcBLn7TrbhJSm75S/AChIv6/qU/NdN Yxg3uniocRacctuo1Sy8tgxsmYi89V9UmLzCUabOlutkO6wJpu5n2RnDhFh5GUpEfj6R 7kKA== X-Received: by 10.15.61.133 with SMTP id i5mr4464675eex.80.1397240067849; Fri, 11 Apr 2014 11:14:27 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id t50sm19346814eev.28.2014.04.11.11.14.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 11:14:24 -0700 (PDT) Message-ID: <534830FD.7040701@gmail.com> Date: Fri, 11 Apr 2014 20:14:21 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dhcwg X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/UWiNFW-35YW-3DYOlpd8jttjtnU Subject: [dhcwg] IPR disclosures for active-leasequery drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:14:31 -0000 Recently two drafts defining active-leasequery for both DHCPv4 and DHCPv6 passed WGLC. Shepherds and chairs noticed that for both there were IPR disclosures, but that fact was never emphasized during the WGLC. I just thought that it would be useful to mention that there are IPR disclosures for both draft-ietf-dhc-dhcpv4-active-leasequery-00 and draft-ietf-dhc-dhcpv4-active-leasequery-01. That fact is clearly visible in datatracker (http://datatracker.ietf.org/wg/dhc/) or using IPR search (http://datatracker.ietf.org/ipr/search/). Please note that Cisco acted very responsibly here by submitting the IPR disclosures promptly, mere days after individual draft submissions. Normally, IPR submissions are sent to the mailing lists, but those particular IPRs were sent when the drafts were still individual work, hence no WG posts. The IPRs are: http://datatracker.ietf.org/ipr/1278/ (for DHCPv4 active leasequery) http://datatracker.ietf.org/ipr/2210/ (for DHCPv6 active leasequery) I'm not a lawyer, but my layman interpretation is that both IPRs are very benign. In my understanding Cisco allows to do whatever you want with the standard (implement, use, sell, export) and they will not sue you, but they reserve their right to use that patent for defence if you sue them. I just though it would be useful to mention that on WG for full transparency. Tomek (draft-ietf-dhc-dhcpv4-active-leasequery shepherd) From nobody Sat Apr 12 07:04:33 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BA61A017F for ; Sat, 12 Apr 2014 07:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggPjy66yiHFE for ; Sat, 12 Apr 2014 07:04:31 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3221A017E for ; Sat, 12 Apr 2014 07:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4092; q=dns/txt; s=iport; t=1397311470; x=1398521070; h=from:to:subject:date:message-id:mime-version; bh=cHIoBDz+oj3iqNA/WJSmS0wFgF7dfz9bhBVuTEx1XKo=; b=WtXm/m+1tR5bE+Q4LTljLxTVwN8cb1pZJiwfCdDj9Rvez9fqtbtDckVU 7tCZS/l6HqfZmVNFcrYxrTh5nzAt/70PWEDrzcV4DIX2qstjse9cBkfME +r72bDyrjhnP0DAh50gz187YJKtR9cH4Xt88jhkss956o6DbHGeXHURWH I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAGVHSVOtJV2a/2dsb2JhbABZgkJEO1e6NYh0gRkWdIInAQQtXgEMHlYmAQQbAYdzDZk5sWsXjh0BAR6DXIEUBJoXkQ2BcoE/gXI5 X-IronPort-AV: E=Sophos; i="4.97,848,1389744000"; d="scan'208,217"; a="35239787" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 12 Apr 2014 14:04:29 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3CE4TmG009868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 12 Apr 2014 14:04:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.175]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Sat, 12 Apr 2014 09:04:29 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 Thread-Index: Ac9WV3oMvXR98LDOSrigT2xIptRMWw== Date: Sat, 12 Apr 2014 14:04:28 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFDEE1D@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.243.164] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AFDEE1Dxmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/jfpbBkACeRNgP68FzzTZMmYAkdg Subject: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 14:04:32 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AFDEE1Dxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, the authors of draft-ietf-dhc-access-network-identifier (http://tool= s.ietf.org/html/draft-ietf-dhc-access-network-identifier-02) feel it's ready for work group last call. Please review this draft and indi= cate whether or not you feel it is ready to be published. At the time of this writing, there is no IPR reported against this draft. P= lease see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html = for a reminder regarding IPR disclosure requirements. Tomek and I will evaluate consensus after April 27, 2014. Thanks, Bernie & Tomek --_000_489D13FBFA9B3E41812EA89F188F018E1AFDEE1Dxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks, the authors of draft-ietf-dhc-access-netwo= rk-identifier (http://tools.ietf.org/html/draft-ietf-dhc-access-net= work-identifier-02)

feel it's ready for work group last call. Please = review this draft and indicate whether or not you feel it is ready to be pu= blished.

 

At the time of this writing, there is no IPR repo= rted against this draft. Please see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html for = a reminder regarding IPR disclosure requirements.

 

Tomek and I will evaluate consensus after April 2= 7, 2014.

 

Thanks,

Bernie & Tomek

 

--_000_489D13FBFA9B3E41812EA89F188F018E1AFDEE1Dxmbrcdx04ciscoc_-- From nobody Mon Apr 14 07:52:10 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D110A1A0165 for ; Mon, 14 Apr 2014 07:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYDGumNirasm for ; Mon, 14 Apr 2014 07:51:58 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3A91A044B for ; Mon, 14 Apr 2014 07:51:57 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so8318718pab.36 for ; Mon, 14 Apr 2014 07:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d+Bgt0RUdJFBR0aNo41rbOGOrRxL18ieG4/6oqyAwxI=; b=bj2jZ20fpgdzRASFaBBrqolUMEH+aCMIDl256zkilRE7WbG3mHWiVlZRS8g9+x87jB OwXToB/IzWiD4LfFaRzxuv0FAT0YovFVdXII4vRUl4V41UiLb/+eYMErAYi2q1+cVlyy 6BNtutDgaqLW52QFZWF7i4Swces7W/yni4buz9FkN83nqr5MNuYSCsRVRfyUNvTSTjR8 Dt1xYLjJgfYbCnYDQm3qjXdcEHRCLfR5Iiid75xJjWvDzd4GFG+4CYqDUC/Wv7//q3L2 n2htuPMWctotlJM8hB7yZnSuatxhqLL9KS42SjLYHJBOck4FpkXVnD5nWKQ4/xekK2Fq AVpA== X-Received: by 10.68.134.198 with SMTP id pm6mr44836033pbb.9.1397487115153; Mon, 14 Apr 2014 07:51:55 -0700 (PDT) Received: from sunqideair.lan ([114.255.40.21]) by mx.google.com with ESMTPSA id bz4sm34312787pbb.12.2014.04.14.07.51.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Apr 2014 07:51:54 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Qi Sun In-Reply-To: Date: Mon, 14 Apr 2014 22:51:34 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <06B8F2CA-A5D5-4F00-8A00-E0D8C99CF976@gmail.com> References: To: Ted Lemon X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Bbop9TrCZBa_pkANd28qYyg8CVw Cc: DHC WG , draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org Subject: Re: [dhcwg] AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:52:07 -0000 Dear Ted, Many thanks for your review! We=92ve updated the local version = accordingly.=20 As for the text in Section 7: > In section 7: > A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST > message to either a broadcast or unicast address depending on its > state. For example, a client in the RENEWING state uses a unicast > address to contact the DHCPv4 server to renew its lease. A client = in > the REBINDING state uses a broadcast address. If there is a DHCPv4 > relay agent in the middle, a client in the RENEWING state may send a > DHCPREQUEST message to the unicast address of the relay agent. In > such a case, the server is unable to determine whether the client > sent the message to a unicast or broadcast address and thus the > server may be unable to correctly determine the client's state. > [RFC5010] introduced the "Flags Suboption" that relay agents add to > relayed messages to indicate whether broadcast or unicast was used = by > the client. >=20 > You say that the client unicasts to the relay agent in the RENEWING = state, but it actually unicasts to the DHCP server. There is a statement in The 3rd paragraph of the Introduction of = RFC5010: In some situations, DHCP Clients may unicast their DHCPREQUEST/RENEW packets to the DHCP Relay Agent, which will forward the packet on to the DHCP server. In these cases, the DHCP server cannot tell whether the packet was broadcast or unicast by the DHCP client, and so it may be unable to process the DHCP client packets in the manner that it would if it knew whether the original DHCP packet was broadcast or unicast. For example, a server might be willing to NAK a client in the REBINDING state based on a determination that the client's address does not match its location in the network, but might not be willing to do so if the client is in the RENEWING state. That=92s why we wrote that text. How about the following change: OLD: If there is a DHCPv4 relay agent in the middle, a client in the RENEWING state may send a DHCPREQUEST message to the unicast address of the relay agent.=20 NEW: If there is a DHCPv4 relay agent in the middle, [RFC5010] describes the possibility of a client in the RENEWING state sending a DHCPREQUEST message to the unicast address of the relay agent. Would it be better?=20 Thanks, Qi On Apr 11, 2014, at 11:29 PM, Ted Lemon wrote: > Page 4, paragraph 3: > OLD: > DHCP clients may be running on CPE devices, end hosts or any other > device that supports the DHCP client function. At the time of > writing, DHCP clients on CPE devices are comparatively easier to > modify than those implemented on end hosts. As a result, this > document uses the CPE as an example for describing the mechanism. > This does not preclude any end-host, or other device requiring IPv4 > configuration, from implementing DHCPv4 over DHCPv6 in the future. > NEW: > DHCP clients may be running on CPE devices, end hosts or any other > device that supports the DHCP client function. This > document uses the CPE as an example for describing the mechanism. > This does not preclude any end-host, or other device requiring IPv4 > configuration, from implementing DHCPv4 over DHCPv6 in the future. >=20 > The assertion that CPE devices are easier than hosts isn't precisely = true, although I understand what you mean. In any case, it's not = necessary to say this, and it's likely to get a DISCUSS, so why not just = take it out? :) >=20 > In section 7: > A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST > message to either a broadcast or unicast address depending on its > state. For example, a client in the RENEWING state uses a unicast > address to contact the DHCPv4 server to renew its lease. A client = in > the REBINDING state uses a broadcast address. If there is a DHCPv4 > relay agent in the middle, a client in the RENEWING state may send a > DHCPREQUEST message to the unicast address of the relay agent. In > such a case, the server is unable to determine whether the client > sent the message to a unicast or broadcast address and thus the > server may be unable to correctly determine the client's state. > [RFC5010] introduced the "Flags Suboption" that relay agents add to > relayed messages to indicate whether broadcast or unicast was used = by > the client. >=20 > You say that the client unicasts to the relay agent in the RENEWING = state, but it actually unicasts to the DHCP server. >=20 > Last paragraph on page 9: > The server MAY include the 4o6 Server Address option in its response > to the client. If the client receives this option, it MUST enable > the DHCPv4-over-DHCPv6 function. The client MUST NOT enable the > DHCPv4-over-DHCPv6 function if the server does not include the 4o6 >=20 > I think you should say "If the client receives this option, it enables = the DHCPv4-over-DHCPv6 function." I don't think you need a MUST there. = The MUST NOT is necessary, however. >=20 > Same paragraph, top of page 10: > Server Address option in its response. If the client does not > receive this option and DHCPv4 over DHCPv6 is already enabled, the > client MUST disable the DHCPv4-over-DHCPv6 function. >=20 > This is underspecified=97a client may be talking to more than one = DHCPv6 server, and may have more than one DHCPv6-derived configuration = active at the same time. I think you need something like this: >=20 > Server Address option in its response. If the DHCPv6 configuration > that contained the 4o6 Server Address option subsequently expires, = the > client MUST disable the DHCPv4-over-DHCPv6 function. If, when the > DHCPv6 configuration that contained the 4o6 Server Address option is > renewed, the renewed configuration does not contain a 4o6 Server = Address > option, the client MUST disable the DHCPv4-over-DHCPv6 function. >=20 > It is possible in a multi-homed configuration for there to be more = than > one DHCPv6 configuration active at the same time that contains a 4o6 > Server Address option. In this case, the configurations are = treated > as being independent, so that when any such configuration is active, = a > DHCPv4-over-DHCPv6 function may be enabled for that configuration. >=20 > An implementation may also treat such configurations as being > exclusive, such that only one is kept active at a time. In this = case, > the client keeps the same configuration active continuously as long > as it is valid. If that configuration becomes invalid but one or = more > other configurations remain valid, the client activates one of the > remaining valid configurations. >=20 > Which strategy to follow is dependent on the implementation: keeping > multiple configurations active at the same time may provide useful > redundancy in some applications, but may be needlessly complex in > other cases. >=20 > Please let me know what you think. I would like to last-call this = document once we've addressed the above issues. >=20 >=20 From nobody Mon Apr 14 08:55:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0811A01D9 for ; Mon, 14 Apr 2014 08:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGskkuQ2jdIe for ; Mon, 14 Apr 2014 08:55:22 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3221A01BE for ; Mon, 14 Apr 2014 08:55:22 -0700 (PDT) Received: from [192.168.146.119] (unknown [70.114.139.95]) by toccata.fugue.com (Postfix) with ESMTPSA id D72A923807EC; Mon, 14 Apr 2014 11:55:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <06B8F2CA-A5D5-4F00-8A00-E0D8C99CF976@gmail.com> Date: Mon, 14 Apr 2014 10:55:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <06B8F2CA-A5D5-4F00-8A00-E0D8C99CF976@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/OWYpyMQkGsJRM2XtwuNBBSmuEe4 Cc: DHC WG , draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org Subject: Re: [dhcwg] AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:55:24 -0000 The only reason a client would ever unicast to a relay would be if the = Server Override Suboption (RFC5107) were in use. This can't be used in = the case of DHCPv4-over-DHCPv6 because there isn't necessarily an IPv4 = address for the relay agent, nor an IPv4 transport the client could use = to reach it. I think mentioning this is unnecessary and confusing. I = can't think of any situation where there would be confusion as to = whether the server override option could be used with = DHCPv4-over-DHCPv6. You could forbid using the option if you think = this needs to be addressed. So I think the right thing to do is remove text, not change text. Your = new text is more confusing than the old text, but if the only reason you = thought to mention this was to address the RFC5107/RFC5010 use case, I = think you can skip it. From nobody Mon Apr 14 23:55:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9251A0276 for ; Mon, 14 Apr 2014 23:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC2ufBdi8M8R for ; Mon, 14 Apr 2014 23:55:28 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0C37D1A0269 for ; Mon, 14 Apr 2014 23:55:28 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id v10so9136621pde.1 for ; Mon, 14 Apr 2014 23:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=x6sojeHuytbuRU/FdNggMXWg1U+pK5ZWItbVa82cS6c=; b=vB7C+0sGiVKaInDnjsUR+MaVZj5EJF0DTx8sy3vefzVtFOEogdTk2Lyz8XfRB0df9l Rf23Q5ZAwX49A3/g8aAXB0iG0oeWzCgpOvUdJ58Pkk6HMJkL3Bmk8tvAj9eVV74sLAOq FoeeDvnx9k6rAbAcoFT3iECtWpMci220hpmboS09t5MAjrf8WIgISsG4/DUh8VoOuLfE ajH5eXJ5oJvngFpiN0ACAf7XL5yTP0NgVkdCtsTOdZXfjBCfgTrq1OYOMN1ie1dAsbPf FBfOvMafuf7h81KgtMGfhwT/7Q9+/H23lcDfCBZyZKGFib/l7e4G7dBZiTOH4UMxswFO 6esw== X-Received: by 10.68.191.138 with SMTP id gy10mr192929pbc.169.1397544925378; Mon, 14 Apr 2014 23:55:25 -0700 (PDT) Received: from ?IPv6:2402:f000:1:4410:181c:54a2:b3ae:7369? ([2402:f000:1:4410:181c:54a2:b3ae:7369]) by mx.google.com with ESMTPSA id yq4sm47563443pab.34.2014.04.14.23.55.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Apr 2014 23:55:24 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Qi Sun In-Reply-To: Date: Tue, 15 Apr 2014 14:54:14 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <06B8F2CA-A5D5-4F00-8A00-E0D8C99CF976@gmail.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/HkaDaB0cRHinYF_rJZwsREt-HqM Cc: DHC WG , draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org Subject: Re: [dhcwg] AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 06:55:33 -0000 Dear Ted, Many thanks for the suggestion.=20 How about this one, with text/reference about RFC5010 removed: OLD: 7. Use of the DHCPv4-query Unicast Flag A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST message to either a broadcast or unicast address depending on its state. For example, a client in the RENEWING state uses a unicast address to contact the DHCPv4 server to renew its lease. A client in the REBINDING state uses a broadcast address. If there is a DHCPv4 relay agent in the middle, a client in the RENEWING state may send a DHCPREQUEST message to the unicast address of the relay agent. In such a case, the server is unable to determine whether the client sent the message to a unicast or broadcast address and thus the server may be unable to correctly determine the client's state. [RFC5010] introduced the "Flags Suboption" that relay agents add to relayed messages to indicate whether broadcast or unicast was used by the client. In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the DHCP 4o6 server. There is no relation between the outer IPv6 address and the inner DHCPv4 message. As a result, the server is unable to determine whether the received DHCPv4 messages should have been sent using broadcast or unicast in IPv4 by checking the IPv6 address. This is similar to the case addressed by [RFC5010]. In order to allow the server to determine the client's state, the "Unicast" flag is carried in the DHCPv4-query message. =85 NEW: 7. Use of the DHCPv4-query Unicast Flag A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST message to either a broadcast or unicast address depending on its state. For example, a client in the RENEWING state uses a unicast address to contact the DHCPv4 server to renew its lease. A client in the REBINDING state uses a broadcast address. =20 In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the DHCP 4o6 server. There is no relation between the outer IPv6 address and the inner DHCPv4 message. As a result, the server is unable to determine whether the received DHCPv4 messages should have been sent using broadcast or unicast in IPv4 by checking the IPv6 address. In order to allow the server to determine the client's state, the "Unicast" flag is carried in the DHCPv4-query message. ... Would this be clear enough?=20 Best Regards, Qi On Apr 14, 2014, at 11:55 PM, Ted Lemon wrote: > The only reason a client would ever unicast to a relay would be if the = Server Override Suboption (RFC5107) were in use. This can't be used in = the case of DHCPv4-over-DHCPv6 because there isn't necessarily an IPv4 = address for the relay agent, nor an IPv4 transport the client could use = to reach it. I think mentioning this is unnecessary and confusing. I = can't think of any situation where there would be confusion as to = whether the server override option could be used with = DHCPv4-over-DHCPv6. You could forbid using the option if you think = this needs to be addressed. >=20 > So I think the right thing to do is remove text, not change text. = Your new text is more confusing than the old text, but if the only = reason you thought to mention this was to address the RFC5107/RFC5010 = use case, I think you can skip it. >=20 From nobody Tue Apr 15 02:36:17 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031521A076F; Tue, 15 Apr 2014 02:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uygYcd6CaH9q; Tue, 15 Apr 2014 02:36:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E921A033C; Tue, 15 Apr 2014 02:36:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140415093613.32395.34169.idtracker@ietfa.amsl.com> Date: Tue, 15 Apr 2014 02:36:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/CyA18vkWyTUAESJYfrPeF_XuaVw Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 09:36:15 -0000 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 : Secure DHCPv6 with Public Key Authors : Sheng Jiang Sean Shen Dacheng Zhang Filename : draft-ietf-dhc-sedhcpv6-02.txt Pages : 19 Date : 2014-04-15 Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attacks. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism for communication between DHCPv6 client and server. This mechanism is based on public/private key pairs. The authority of the sender may depend on either pre-configuration mechanism or Public Key Infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-sedhcpv6-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 15 07:53:41 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546171A03E5 for ; Tue, 15 Apr 2014 07:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jayXHGRVjOpw for ; Tue, 15 Apr 2014 07:53:36 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 11A301A01FF for ; Tue, 15 Apr 2014 07:53:36 -0700 (PDT) Received: from [172.16.0.175] (rrcs-67-78-65-202.sw.biz.rr.com [67.78.65.202]) by toccata.fugue.com (Postfix) with ESMTPSA id 2E4B42380CB4; Tue, 15 Apr 2014 10:53:30 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 15 Apr 2014 09:53:29 -0500 Content-Transfer-Encoding: 7bit Message-Id: <180954E7-159D-4E02-9EC8-7AB042ECC9C1@fugue.com> References: <06B8F2CA-A5D5-4F00-8A00-E0D8C99CF976@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/EiWkT3tplUudLlG00z9jUKNat3s Cc: DHC WG , draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org Subject: Re: [dhcwg] AD review of draft-ietf-dhc-dhcpv4-over-dhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 14:53:40 -0000 On Apr 15, 2014, at 1:54 AM, Qi Sun wrote: > Would this be clear enough? Yes, I think that's much better. Thanks! From nobody Tue Apr 15 10:37:14 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC831A0698; Tue, 15 Apr 2014 10:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdlzrCED8S7Q; Tue, 15 Apr 2014 10:37:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E24D1A01FA; Tue, 15 Apr 2014 10:37:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140415173707.31429.44756.idtracker@ietfa.amsl.com> Date: Tue, 15 Apr 2014 10:37:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/3cZYg_XilAGtsj6WCpGzbcWSpr8 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 17:37:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv4 over DHCPv6 Transport Authors : Qi Sun Yong Cui Marcin Siodelski Suresh Krishnan Ian Farrer Filename : draft-ietf-dhc-dhcpv4-over-dhcpv6-07.txt Pages : 15 Date : 2014-04-15 Abstract: IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-over-dhcpv6-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 15 11:09:16 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BD91A03BF; Tue, 15 Apr 2014 11:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEvvZhNJEsuO; Tue, 15 Apr 2014 11:09:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBE21A022D; Tue, 15 Apr 2014 11:09:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140415180912.15974.26968.idtracker@ietfa.amsl.com> Date: Tue, 15 Apr 2014 11:09:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/MxtJMx2F6c8dJ1f4tbzXpI5RD7U Cc: dhcwg@ietf.org Subject: [dhcwg] Last Call: (DHCPv4 over DHCPv6 Transport) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 18:09:14 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'DHCPv4 over DHCPv6 Transport' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Apr 15 20:39:04 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31C21A0022 for ; Tue, 15 Apr 2014 20:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvejNeAOB_nn for ; Tue, 15 Apr 2014 20:39:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 572F11A0020 for ; Tue, 15 Apr 2014 20:39:00 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-98-534dacde18f4 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 99.60.05011.EDCAD435; Wed, 16 Apr 2014 00:04:15 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue, 15 Apr 2014 23:38:56 -0400 From: Suresh Krishnan To: "dhcwg@ietf.org" Thread-Topic: Review of draft-ietf-dhc-topo-conf-01 Thread-Index: Ac9ZHi1PPgQxUk9oTxe9Ve2nDA1AjA== Date: Wed, 16 Apr 2014 03:38:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_E87B771635882B4BA20096B589152EF6286B7372eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXSPn+79Nb7BBjf/8Fjc7WhhdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrSuVtaCNsuK05PPsTQwTjXsYuTkkBAwkfjU+owZwhaTuHBv PVsXIxeHkMBRRolZU74wQzjLGSVON19kAqliA+rYsPMzmC0ioCqx8uBkdhBbWEBPYt3bOWwQ cWOJ6eu6GLsYOYBsPYm+1eIgYRag8kOr57KC2LwCvhKdhy+A2YxAi7+fWgM2kllAXOLWk/lM EAcJSCzZcx7qOFGJl4//sULYShIff89nh6jPl1jY0MAGMVNQ4uTMJywTGIVmIRk1C0nZLCRl EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxalluupHBJkZg4B+TYNPdwbjnpeUh RgEORiUeXqGa3AAh1sSy4srcQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amCc5fbxiPFzTs2JqwRzLid3SEc+e3lT6MbOeO7X4nxsq/93fVkdq+I00yDWr/vM457ebq6p e8/s3nnPWKZDKOX1/02b/h/efzG1WpZRfmHwm7Avwt2cp2WfVWSKbvqZdqFlcVaVfZtS8Pq7 WVmKmgp/cuK49x68tS9yxoTHtQs+hPTH/Ll92CxMiaU4I9FQi7moOBEANFoFg10CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/eNG9dF8oStFmQvtbjK7mHkioV-M Subject: [dhcwg] Review of draft-ietf-dhc-topo-conf-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 03:39:03 -0000 --_000_E87B771635882B4BA20096B589152EF6286B7372eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I went over draft-ietf-dhc-topo-conf-01 and I found it to be useful and = easy to read. I had some comments that you may wish to address. Section 2: I think you were meaning to define "Routable IP address" as the first term = but it is missing from the text Section 3 Page 6: I think this rewording will make the sentence read better OLD: if the client does not yet have an IP address configuration NEW: if the client does not yet have an IP address configured Section 3 Page 7: I guess you want to refer to the Interface-Id option when you talk about th= e Interface Identifier option. If so, can you please replace. As a side comment, would it make sense to add references for these options = when they are first referred to in the draft? e.g. For Interface-Id add Section 22.18 of RFC3315, for server unicast add = Section 22.12 of RFC3315 Section 4 Page 8: I think this example needs to be rewritten with a different IP prefix reser= ved for documentation instead of using the 10.0.0.0/8 RFC1918 prefix. Sugge= st using the TEST-NET-1, TEST-NET-2 and TEST-NET-3 blocks from RFC5737 for = this purpose. [NOTE: Since there are only 3 /24 documentation blocks reserved, the exampl= es need to use a longer than /24 prefix for at least two of the subnets.] Section 5: Since the "it" refers to the relay agent code and not the router suggest s/it doesn't have to be one./it doesn't have to be./ Section 6: s/first relay agent that seen/first relay agent that saw/ Section 8: Not sure what the last paragraph adds. Is this text necessary? Thanks Suresh --_000_E87B771635882B4BA20096B589152EF6286B7372eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

  I went over  draft-ietf-dhc-topo-conf-01= and I found it to be useful and easy to read. I had some comments that you= may wish to address.

 

Section 2:

 

I think you were meaning to define “Routable I= P address” as the first term but it is missing from the text

 

Section 3 Page 6:

 

I think this rewording will make the sentence read b= etter

 

OLD:

if  the client does not yet have an IP address = configuration

NEW:

if the client does not yet have an IP address config= ured

 

Section 3 Page 7:

 

I guess you want to refer to the Interface-Id option= when you talk about the Interface Identifier option. If so, can you please= replace.

 

As a side comment, would it make sense to add refere= nces for these options when they are first referred to in the draft?

 

e.g. For Interface-Id add Section 22.18 of RFC3315, = for server unicast add Section 22.12 of RFC3315

 

Section 4 Page 8:

 

I think this example needs to be rewritten with a di= fferent IP prefix reserved for documentation instead of using the 10.0.0.0/= 8 RFC1918 prefix. Suggest using the TEST-NET-1, TEST-NET-2 and TEST-NET-3 b= locks from RFC5737 for this purpose.

 

[NOTE: Since there are only 3 /24 documentation bloc= ks reserved, the examples need to use a longer than /24 prefix for at least= two of the subnets.]

 

Section 5:

 

Since the “it” refers to the relay agent= code and not the router suggest

 

s/it doesn't have to be one./it doesn't have to be./=

 

Section 6:

 

s/first relay agent that seen/first relay agent that= saw/

 

Section 8:

 

Not sure what the last paragraph adds. Is this text = necessary?

 

Thanks

Suresh

 

--_000_E87B771635882B4BA20096B589152EF6286B7372eusaamb107erics_-- From nobody Mon Apr 21 06:28:04 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4F01A01D7 for ; Mon, 21 Apr 2014 06:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-5NrLGK222Z for ; Mon, 21 Apr 2014 06:27:58 -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 CF7631A0181 for ; Mon, 21 Apr 2014 06:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8367; q=dns/txt; s=iport; t=1398086873; x=1399296473; h=from:to:subject:date:message-id:mime-version; bh=ZcfpHiphTIOeY5FBHjOSG9Va/anXLM5ablJUtEVzfKQ=; b=PlBq8FM0BEJb8rCHQ7zu2MTBOrTfKMBVe7pwojOdJ7HnLS+s7D18oDeC scoo6NIaIdxZ5m9ITLwLNTELX1fstNhMXCGVU0X+BMAKEzREAUfulrtcy OfU/j4OA0nq6WjFo539O/6E12/WqfXoCHKJDzoEuOS8vbrpvjWf1fVbxx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwFALgbVVOtJV2c/2dsb2JhbABZgkJET1e7E4h7gR4WdIIlAQEBBC1eARkEAQELVh0JAQQTCAGIOA2bKLIpF44RAQEeg1yBFASaJZEYgXKBP4FyOQ X-IronPort-AV: E=Sophos;i="4.97,896,1389744000"; d="scan'208,217";a="319220554" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 21 Apr 2014 13:27:50 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3LDRoCH000569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Apr 2014 13:27:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 08:27:50 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 Thread-Index: Ac9dZRqkjOSHG0oIQNqdXl8y/gCSiw== Date: Mon, 21 Apr 2014 13:27:49 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFF12C8@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.176] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AFF12C8xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/IxE4db0YozLHgWHgMvl_y4HVO-I Subject: [dhcwg] Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 13:28:03 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AFF12C8xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Friendly reminder regarding this WGLC. There has been no feedback so far. - Bernie From: Bernie Volz (volz) Sent: Saturday, April 12, 2014 10:04 AM To: dhcwg@ietf.org Subject: WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by = April 27, 2014 Folks, the authors of draft-ietf-dhc-access-network-identifier (http://tool= s.ietf.org/html/draft-ietf-dhc-access-network-identifier-02) feel it's ready for work group last call. Please review this draft and indi= cate whether or not you feel it is ready to be published. At the time of this writing, there is no IPR reported against this draft. P= lease see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html = for a reminder regarding IPR disclosure requirements. Tomek and I will evaluate consensus after April 27, 2014. Thanks, Bernie & Tomek --_000_489D13FBFA9B3E41812EA89F188F018E1AFF12C8xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Friendly reminder rega= rding this WGLC. There has been no feedback so far.

 

-&nb= sp;         Bernie

 

From: Bernie V= olz (volz)
Sent: Saturday, April 12, 2014 10:04 AM
To: dhcwg@ietf.org
Subject: WGLC for draft-ietf-dhc-access-network-identifier-02 - resp= ond by April 27, 2014

 

Folks, the authors of draft-ietf-dhc-access-netwo= rk-identifier (http://tools.ietf.org/html/draft-ietf-dhc-access-net= work-identifier-02)

feel it's ready for work group last call. Please = review this draft and indicate whether or not you feel it is ready to be pu= blished.

 

At the time of this writing, there is no IPR repo= rted against this draft. Please see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html for = a reminder regarding IPR disclosure requirements.

 

Tomek and I will evaluate consensus after April 2= 7, 2014.

 

Thanks,

Bernie & Tomek

 

--_000_489D13FBFA9B3E41812EA89F188F018E1AFF12C8xmbrcdx04ciscoc_-- From nobody Mon Apr 21 21:47:24 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6731A0066 for ; Mon, 21 Apr 2014 21:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHn8S6c3Ia2c for ; Mon, 21 Apr 2014 21:47:18 -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 9C15B1A0064 for ; Mon, 21 Apr 2014 21:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10809; q=dns/txt; s=iport; t=1398142034; x=1399351634; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=4+8Mjabtr3fVU+ObT30mwRvOkeooBHEJ8xwRVQbd+eI=; b=ZrGdmmcgCQm/px6MfwEl5fPef2x5u5sl/JLmfYdxXkdkv9LyAgjufrY2 grgn3QsHPjphPtGCTfGByU1oavkPVR4tyJqmHtFs2p5gvVLTcQkI/VOdh BjLP7Ue4m3Beck2GlcEMj1tvVJwcXDehcRQG+HvkkKkeCbGQMyx8gzYzu 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFANvzVVOtJV2Z/2dsb2JhbABZgkJET1e7FYh6gSAWdIIlAQEBBC1cAgEIEQQBAQsdBzIUCQgBAQQBEggBiDgNzFsXjgUBAR43AYMkgRQEmiWRGYFygT+Bcjk X-IronPort-AV: E=Sophos;i="4.97,901,1389744000"; d="scan'208,217";a="319370011" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 22 Apr 2014 04:47:13 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3M4lDGY000476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Apr 2014 04:47:13 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.196]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 23:47:12 -0500 From: "Gaurav Halwasia (ghalwasi)" To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 Thread-Index: Ac9dZRqkjOSHG0oIQNqdXl8y/gCSiwAf69Kw Date: Tue, 22 Apr 2014 04:47:12 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB2D45B1BD@xmb-aln-x06.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AFF12C8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFF12C8@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.142.104.85] Content-Type: multipart/alternative; boundary="_000_90903C21C73202418A48BFBE80AEE5EB2D45B1BDxmbalnx06ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/_-t3drkV-i7nvh5IHDaqqJKsFXs Subject: Re: [dhcwg] Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 04:47:23 -0000 --_000_90903C21C73202418A48BFBE80AEE5EB2D45B1BDxmbalnx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have read/reviewed this document earlier and now. I support this document= to move forward. One small nit. Spelling of "Description" is incorrect in section 5 & 10. Thanks -Gaurav From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, April 21, 2014 6:58 PM To: dhcwg@ietf.org Subject: [dhcwg] Reminder - WGLC for draft-ietf-dhc-access-network-identifi= er-02 - respond by April 27, 2014 Friendly reminder regarding this WGLC. There has been no feedback so far. - Bernie From: Bernie Volz (volz) Sent: Saturday, April 12, 2014 10:04 AM To: dhcwg@ietf.org Subject: WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by = April 27, 2014 Folks, the authors of draft-ietf-dhc-access-network-identifier (http://tool= s.ietf.org/html/draft-ietf-dhc-access-network-identifier-02) feel it's ready for work group last call. Please review this draft and indi= cate whether or not you feel it is ready to be published. At the time of this writing, there is no IPR reported against this draft. P= lease see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html = for a reminder regarding IPR disclosure requirements. Tomek and I will evaluate consensus after April 27, 2014. Thanks, Bernie & Tomek --_000_90903C21C73202418A48BFBE80AEE5EB2D45B1BDxmbalnx06ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read/reviewed t= his document earlier and now. I support this document to move forward.

 

One small nit. Spellin= g of “Description” is inco= rrect in section 5 & 10.

 

Thanks

-Gaurav

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Monday, April 21, 2014 6:58 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Reminder - WGLC for draft-ietf-dhc-access-network-i= dentifier-02 - respond by April 27, 2014

 

Friendly reminder rega= rding this WGLC. There has been no feedback so far.

 

-&nb= sp;         Bernie

 

From: Bernie V= olz (volz)
Sent: Saturday, April 12, 2014 10:04 AM
To: dhcwg@ietf.org
Subject: WGLC for draft-ietf-dhc-access-network-identifier-02 - resp= ond by April 27, 2014

 

Folks, the authors of draft-ietf-dhc-access-netwo= rk-identifier (http://tools.ietf.org/html/draft-ietf-dhc-access-net= work-identifier-02)

feel it's ready for work group last call. Please = review this draft and indicate whether or not you feel it is ready to be pu= blished.

 

At the time of this writing, there is no IPR repo= rted against this draft. Please see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html for = a reminder regarding IPR disclosure requirements.

 

Tomek and I will evaluate consensus after April 2= 7, 2014.

 

Thanks,

Bernie & Tomek

 

--_000_90903C21C73202418A48BFBE80AEE5EB2D45B1BDxmbalnx06ciscoc_-- From nobody Mon Apr 21 23:19:58 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7E71A0089 for ; Mon, 21 Apr 2014 23:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr8NIpLewBY4 for ; Mon, 21 Apr 2014 23:19:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7B11A0092 for ; Mon, 21 Apr 2014 23:19:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFX61252; Tue, 22 Apr 2014 06:19:46 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Apr 2014 07:19:09 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Apr 2014 07:19:44 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.206]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 22 Apr 2014 14:19:40 +0800 From: Sheng Jiang To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 Thread-Index: Ac9dZRqkjOSHG0oIQNqdXl8y/gCSiwAaST0w Date: Tue, 22 Apr 2014 06:19:38 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE3CD5A@nkgeml512-mbx.china.huawei.com> References: <489D13FBFA9B3E41812EA89F188F018E1AFF12C8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFF12C8@xmb-rcd-x04.cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923AE3CD5Ankgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/akdu6O8L0-LR0LPC-YxBu4jlRuU Subject: Re: [dhcwg] Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 06:19:55 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B923AE3CD5Ankgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQuIE92ZXJhbGwsIGl0IHRhcmdldHMgdG8gc29s dmUgYSByZWFsIG9wZXJhdGlvbiBpc3N1ZS4gSSBhbSBub3Qga25vd2xlZGdlIGVub3VnaCB0byBy ZXZpZXcgdGhlIHJlcXVpcmVtZW50cyBhbmQgY29udGVudHMgZm9yIGVhY2ggYWNjZXNzLW5ldHdv cmstaWRlbnRpZmllciBzdWItb3B0aW9uLiBTbyB0aGUgYmVsb3cgaXMgb25seSByZXZpZXcgZnJv bSBESEMgcHJvdG9jb2wgcGVyc3BlY3RpdmUgYW5kIGRvY3VtZW50IHdyaXRpbmcuDQoNClRoZSBE SEMgcHJvdG9jb2wgc3BlY2lmaWMgZGVzY3JpcHRpb24gaW4gc2VjdGlvbiA3LCA4IGFuZCA5IGFy ZSBnZW5lcmFsbHkgd2Vhay4gSW4gc2VjdGlvbiA3LCBpdCBpcyB1bmNsZWFyIHdoZW4gdGhlIG9w dGlvbiBzaG91bGQgYmUgdXNlZCwgd2hpY2ggc3ViLW9wdGlvbiBzaG91bGQgYmUgdXNlZCB1bmRl ciB3aGF0IGNvbnNpZGVyYXRpb24sIGFuZCB3aGF0IERIQyBtZXNzYWdlIGlzIGludm9sdmVkLiBJ biBzZWN0aW9uIDgsIGhvdyB0aGUgcmVsYXkgYWdlbnQgaW5jbHVkZSB0aGVzZSBvcHRpb24gaXMg aW50YW5naWJseSBkZXNjcmliZWQuIEFsdGhvdWdoIFJGQyAzMDQ2LCBSZWxheSBBZ2VudCBJbmZv cm1hdGlvbiBPcHRpb24gKDgyKSB3YXMgbWVudGlvbmVkIGluIFNlY3Rpb24gNCwgdGhlIGFzc29j aWF0ZWQgYmVoYXZpb3IgaXMgbWlzc2VkLiBUaGUgUkZDIGlzIG5vdCByZWZlcnJlZCB0b28uIElu IFNlY3Rpb24gOSwgaG93IHNlcnZlciBpcyBiZWhhdmlvciB3aGVuIHJlY2VpdmVzIHRoZXNlIG9w dGlvbiBpcyBpbnRhbmdpYmxlLiBQYXJ0aWN1bGFybHksIHRoZSByZXNwb25zZSBpbiBESENQdjYg bWVzc2FnZSBpcyB3cm9uZzogdGhlIGRvY3VtZW50IHN0YXRlOiDigJxUaGVyZSBpcyBubyByZXF1 aXJlbWVudCB0aGF0IGEgc2VydmVyIHJldHVybiB0aGVzZSBvcHRpb25zICBhbmQgaXRzIGRhdGEg aW4gYSBkb3duc3RyZWFtIERIQ1AgbWVzc2FnZS7igJ0gVGhpcyBpcyBOT1QgY29tcGF0aWJsZSB3 aXRoIGV4aXN0aW5nIERIQyBkZWZpbml0aW9ucywgcGFydGljdWxhcmx5LCB3aGVuIHRoZSBuZXds eS1kZWZpbmVkIG9wdGlvbiBpcyBhZGRlZCBieSByZWxheSBhZ2VudC4gU29tZSByZWxldmFudCBx dW90ZSBsaXN0IGJlbG93Og0KDQpJbiBzZWN0aW9uIDIuMiwgUkZDMzA0Niwg4oCcREhDUCBzZXJ2 ZXJzIGNsYWltaW5nIHRvIHN1cHBvcnQgdGhlIFJlbGF5IEFnZW50IEluZm9ybWF0aW9uIG9wdGlv biBTSEFMTCBlY2hvIHRoZSBlbnRpcmUgY29udGVudHMgb2YgdGhlIFJlbGF5IEFnZW50IEluZm9y bWF0aW9uIG9wdGlvbiAgaW4gYWxsIHJlcGxpZXMu4oCdDQoNCkEgZmV3IHJlZmVyZW5jZSBpZG5p dHMgbmVlZCB0byBiZSBmaXhlZCB0b28uDQoNCiAgPT0gTWlzc2luZyBSZWZlcmVuY2U6ICdSRkMx MDM1Jw0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDMjQzNCcNCg0KICAqKiBPYnNvbGV0ZSBu b3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMgMjQzNCAoT2Jzb2xldGVkIGJ5IFJGQyA1MjI2KQ0KDQog IC0tIFBvc3NpYmxlIGRvd25yZWY6IE5vbi1SRkMgbm9ybWF0aXZlIHJlZmVyZW5jZTogcmVmLiAn QU5JJw0KICAtLSBQb3NzaWJsZSBkb3ducmVmOiBOb24tUkZDIG5vcm1hdGl2ZSByZWZlcmVuY2U6 IHJlZi4gJ1NNSScNCiAgLS0gUG9zc2libGUgZG93bnJlZjogTm9uLVJGQyBub3JtYXRpdmUgcmVm ZXJlbmNlOiByZWYuICdUUzIzMDAzJw0KICAtLSBQb3NzaWJsZSBkb3ducmVmOiBOb24tUkZDIG5v cm1hdGl2ZSByZWZlcmVuY2U6IHJlZi4gJ1RTMjMyMDMnDQogIC0tIFBvc3NpYmxlIGRvd25yZWY6 IE5vbi1SRkMgbm9ybWF0aXZlIHJlZmVyZW5jZTogcmVmLiAnVFMyMzQwMicNCg0KUmVnYXJkcywN Cg0KU2hlbmcNCg0KRnJvbTogZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQmVybmllIFZvbHogKHZvbHopDQpTZW50OiBNb25kYXksIEFwcmlsIDIxLCAy MDE0IDk6MjggUE0NClRvOiBkaGN3Z0BpZXRmLm9yZw0KU3ViamVjdDogW2RoY3dnXSBSZW1pbmRl ciAtIFdHTEMgZm9yIGRyYWZ0LWlldGYtZGhjLWFjY2Vzcy1uZXR3b3JrLWlkZW50aWZpZXItMDIg LSByZXNwb25kIGJ5IEFwcmlsIDI3LCAyMDE0DQoNCkZyaWVuZGx5IHJlbWluZGVyIHJlZ2FyZGlu ZyB0aGlzIFdHTEMuIFRoZXJlIGhhcyBiZWVuIG5vIGZlZWRiYWNrIHNvIGZhci4NCg0KDQotICAg ICAgICBCZXJuaWUNCg0KRnJvbTogQmVybmllIFZvbHogKHZvbHopDQpTZW50OiBTYXR1cmRheSwg QXByaWwgMTIsIDIwMTQgMTA6MDQgQU0NClRvOiBkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dA aWV0Zi5vcmc+DQpTdWJqZWN0OiBXR0xDIGZvciBkcmFmdC1pZXRmLWRoYy1hY2Nlc3MtbmV0d29y ay1pZGVudGlmaWVyLTAyIC0gcmVzcG9uZCBieSBBcHJpbCAyNywgMjAxNA0KDQoNCkZvbGtzLCB0 aGUgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLWRoYy1hY2Nlc3MtbmV0d29yay1pZGVudGlmaWVyICho dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1hY2Nlc3MtbmV0d29yay1p ZGVudGlmaWVyLTAyKQ0KDQpmZWVsIGl0J3MgcmVhZHkgZm9yIHdvcmsgZ3JvdXAgbGFzdCBjYWxs LiBQbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQgYW5kIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlv dSBmZWVsIGl0IGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hlZC4NCg0KDQoNCkF0IHRoZSB0aW1lIG9m IHRoaXMgd3JpdGluZywgdGhlcmUgaXMgbm8gSVBSIHJlcG9ydGVkIGFnYWluc3QgdGhpcyBkcmFm dC4gUGxlYXNlIHNlZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGhjd2cv Y3VycmVudC9tc2cxNDE0My5odG1sIGZvciBhIHJlbWluZGVyIHJlZ2FyZGluZyBJUFIgZGlzY2xv c3VyZSByZXF1aXJlbWVudHMuDQoNCg0KDQpUb21layBhbmQgSSB3aWxsIGV2YWx1YXRlIGNvbnNl bnN1cyBhZnRlciBBcHJpbCAyNywgMjAxNC4NCg0KDQoNClRoYW5rcywNCg0KQmVybmllICYgVG9t ZWsNCg0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AE3CD5Ankgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxh aW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH 5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofm nKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aW h+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KcC5QbGFpblRleHQsIGxpLlBsYWluVGV4dCwg ZGl2LlBsYWluVGV4dA0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCI7DQoJbXNvLXN0eWxl LWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWlu IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIz DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFtZToi5om5 5rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6NDE4NzE3Nzc0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoyMDY5MTUwMjYyIC04NjY1MDIyMTAgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo2Ow0KCW1zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+SSBo YXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQuIE92ZXJhbGwsIGl0IHRhcmdldHMgdG8gc29sdmUg YSByZWFsIG9wZXJhdGlvbiBpc3N1ZS4gSSBhbSBub3Qga25vd2xlZGdlIGVub3VnaCB0byByZXZp ZXcgdGhlIHJlcXVpcmVtZW50cyBhbmQgY29udGVudHMgZm9yIGVhY2ggYWNjZXNzLW5ldHdvcmst aWRlbnRpZmllcg0KIHN1Yi1vcHRpb24uIFNvIHRoZSBiZWxvdyBpcyBvbmx5IHJldmlldyBmcm9t IERIQyBwcm90b2NvbCBwZXJzcGVjdGl2ZSBhbmQgZG9jdW1lbnQgd3JpdGluZy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlRoZSBESEMgcHJvdG9jb2wgc3BlY2lmaWMg ZGVzY3JpcHRpb24gaW4gc2VjdGlvbiA3LCA4IGFuZCA5IGFyZSBnZW5lcmFsbHkgd2Vhay4gSW4g c2VjdGlvbiA3LCBpdCBpcyB1bmNsZWFyIHdoZW4gdGhlIG9wdGlvbiBzaG91bGQgYmUgdXNlZCwg d2hpY2ggc3ViLW9wdGlvbiBzaG91bGQgYmUgdXNlZCB1bmRlcg0KIHdoYXQgY29uc2lkZXJhdGlv biwgYW5kIHdoYXQgREhDIG1lc3NhZ2UgaXMgaW52b2x2ZWQuIEluIHNlY3Rpb24gOCwgaG93IHRo ZSByZWxheSBhZ2VudCBpbmNsdWRlIHRoZXNlIG9wdGlvbiBpcyBpbnRhbmdpYmx5IGRlc2NyaWJl ZC4gQWx0aG91Z2ggUkZDIDMwNDYsIFJlbGF5IEFnZW50IEluZm9ybWF0aW9uIE9wdGlvbiAoODIp IHdhcyBtZW50aW9uZWQgaW4gU2VjdGlvbiA0LCB0aGUgYXNzb2NpYXRlZCBiZWhhdmlvciBpcyBt aXNzZWQuIFRoZQ0KIFJGQyBpcyBub3QgcmVmZXJyZWQgdG9vLiBJbiBTZWN0aW9uIDksIGhvdyBz ZXJ2ZXIgaXMgYmVoYXZpb3Igd2hlbiByZWNlaXZlcyB0aGVzZSBvcHRpb24gaXMgaW50YW5naWJs ZS4gUGFydGljdWxhcmx5LCB0aGUgcmVzcG9uc2UgaW4gREhDUHY2IG1lc3NhZ2UgaXMgd3Jvbmc6 IHRoZSBkb2N1bWVudCBzdGF0ZTog4oCcVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdGhhdCBhIHNl cnZlciByZXR1cm4gdGhlc2Ugb3B0aW9ucyZuYnNwOyBhbmQgaXRzIGRhdGEgaW4NCiBhIGRvd25z dHJlYW0gREhDUCBtZXNzYWdlLuKAnSBUaGlzIGlzIE5PVCBjb21wYXRpYmxlIHdpdGggZXhpc3Rp bmcgREhDIGRlZmluaXRpb25zLCBwYXJ0aWN1bGFybHksIHdoZW4gdGhlIG5ld2x5LWRlZmluZWQg b3B0aW9uIGlzIGFkZGVkIGJ5IHJlbGF5IGFnZW50LiBTb21lIHJlbGV2YW50IHF1b3RlIGxpc3Qg YmVsb3c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5JbiBzZWN0aW9u IDIuMiwgUkZDMzA0Niwg4oCcREhDUCBzZXJ2ZXJzIGNsYWltaW5nIHRvIHN1cHBvcnQgdGhlIFJl bGF5IEFnZW50IEluZm9ybWF0aW9uIG9wdGlvbiBTSEFMTCBlY2hvIHRoZSBlbnRpcmUgY29udGVu dHMgb2YgdGhlIFJlbGF5IEFnZW50IEluZm9ybWF0aW9uIG9wdGlvbiZuYnNwOyBpbiBhbGwgcmVw bGllcy7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkEgZmV3IHJl ZmVyZW5jZSBpZG5pdHMgbmVlZCB0byBiZSBmaXhlZCB0b28uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsgPT0gTWlzc2luZyBSZWZlcmVuY2U6ICdSRkMxMDM1 Jw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOz09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkMyNDM0JzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7ICoqIE9ic29sZXRlIG5vcm1hdGl2ZSByZWZlcmVuY2U6 IFJGQyAyNDM0IChPYnNvbGV0ZWQgYnkgUkZDIDUyMjYpPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDsgLS0gUG9zc2libGUgZG93bnJlZjogTm9uLVJGQyBub3Jt YXRpdmUgcmVmZXJlbmNlOiByZWYuICdBTkknPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyAtLSBQb3NzaWJsZSBkb3ducmVmOiBOb24tUkZDIG5vcm1h dGl2ZSByZWZlcmVuY2U6IHJlZi4gJ1NNSSc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IC0tIFBvc3NpYmxlIGRvd25yZWY6IE5vbi1SRkMgbm9ybWF0 aXZlIHJlZmVyZW5jZTogcmVmLiAnVFMyMzAwMyc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IC0tIFBvc3NpYmxlIGRvd25yZWY6IE5vbi1SRkMgbm9y bWF0aXZlIHJlZmVyZW5jZTogcmVmLiAnVFMyMzIwMyc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IC0tIFBvc3NpYmxlIGRvd25yZWY6IE5vbi1SRkMg bm9ybWF0aXZlIHJlZmVyZW5jZTogcmVmLiAnVFMyMzQwMic8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xv cjojMUY0OTdEIj5TaGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGRoY3dnIFttYWls dG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVybmllIFZv bHogKHZvbHopPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMjEsIDIwMTQgOToyOCBQ TTxicj4NCjxiPlRvOjwvYj4gZGhjd2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2Ro Y3dnXSBSZW1pbmRlciAtIFdHTEMgZm9yIGRyYWZ0LWlldGYtZGhjLWFjY2Vzcy1uZXR3b3JrLWlk ZW50aWZpZXItMDIgLSByZXNwb25kIGJ5IEFwcmlsIDI3LCAyMDE0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkZyaWVuZGx5IHJlbWluZGVy IHJlZ2FyZGluZyB0aGlzIFdHTEMuIFRoZXJlIGhhcyBiZWVuIG5vIGZlZWRiYWNrIHNvIGZhci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkJlcm5pZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJlcm5p ZSBWb2x6ICh2b2x6KQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBcHJpbCAxMiwgMjAx NCAxMDowNCBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3Jn Ij5kaGN3Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gV0dMQyBmb3IgZHJhZnQt aWV0Zi1kaGMtYWNjZXNzLW5ldHdvcmstaWRlbnRpZmllci0wMiAtIHJlc3BvbmQgYnkgQXByaWwg MjcsIDIwMTQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gb2xrcywgdGhl IGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1kaGMtYWNjZXNzLW5ldHdvcmstaWRlbnRpZmllciAoPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtYWNjZXNzLW5l dHdvcmstaWRlbnRpZmllci0wMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1kaGMtYWNjZXNzLW5ldHdvcmstaWRlbnRpZmllci0wMjwvYT4pPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPmZlZWwgaXQn cyByZWFkeSBmb3Igd29yayBncm91cCBsYXN0IGNhbGwuIFBsZWFzZSByZXZpZXcgdGhpcyBkcmFm dCBhbmQgaW5kaWNhdGUgd2hldGhlciBvciBub3QgeW91IGZlZWwgaXQgaXMgcmVhZHkgdG8gYmUg cHVibGlzaGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QXQgdGhlIHRpbWUgb2YgdGhpcyB3 cml0aW5nLCB0aGVyZSBpcyBubyBJUFIgcmVwb3J0ZWQgYWdhaW5zdCB0aGlzIGRyYWZ0LiBQbGVh c2Ugc2VlDQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGhj d2cvY3VycmVudC9tc2cxNDE0My5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvZGhjd2cvY3VycmVudC9tc2cxNDE0My5odG1sPC9hPiBmb3IgYSByZW1pbmRlciByZWdh cmRpbmcgSVBSIGRpc2Nsb3N1cmUgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+VG9tZWsgYW5kIEkgd2lsbCBldmFsdWF0ZSBjb25zZW5zdXMgYWZ0ZXIgQXByaWwgMjcsIDIw MTQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlcm5pZSAmYW1w OyBUb21lazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B923AE3CD5Ankgeml512mbxchi_-- From nobody Tue Apr 22 09:39:13 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137111A06A4; Tue, 22 Apr 2014 09:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOefKCC3jw3b; Tue, 22 Apr 2014 09:39:07 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4F11A0697; Tue, 22 Apr 2014 09:39:06 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id e49so4811451eek.39 for ; Tue, 22 Apr 2014 09:39: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OML1TjpCB5izjlHOwP782CqPhRwE6QtDBM14deD6X6g=; b=a+o3sAvCRXosYX28bSW63rIEsRgExFLyH4B/+5E9UUajhQiTPOtVdBYJyklvYK26bC 6V7ggv+hIYSxvfrXAVtgfr2l6G12mN3smif6Oigdju0oEuQxq1oGphI12E0mlD3+pjLK jDaaHZLKxbSIpGM8xw/6bxjh3+T0O0tkMnyh59EFRF3s4Y3IpBE8OJGDAfZ/FTFu8Jd7 reCwMQmrvWmT5X3BpF6lkRgritUJa4Qm76TJNlLaWemJhegFk38cJNNLXvn0y/rF8JtC Sn+I23iF16xQ4ebiVtwJjtbIH5IMxyPqAm3GmawcIt0Xo+jpcLTHVGKNCFdCKAzKMl90 P38w== X-Received: by 10.15.82.132 with SMTP id a4mr56683368eez.47.1398184741104; Tue, 22 Apr 2014 09:39:01 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id q49sm114462345eem.34.2014.04.22.09.38.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 09:39:00 -0700 (PDT) Message-ID: <53569B1C.9030803@gmail.com> Date: Tue, 22 Apr 2014 18:38:52 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dhcwg References: <53422B8F.2020109@ericsson.com> In-Reply-To: <53422B8F.2020109@ericsson.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140422183852823 X-Forwarded-Message-Id: <53422B8F.2020109@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/gw5NcDGMbtQrc6gsnvRxarLsuxA Cc: Softwires-wg Subject: [dhcwg] WGLC for draft-ietf-softwire-map-dhcp-07 in Softwires WG X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 16:39:12 -0000 Oops, that slipped under the radar for while. I'd like to bring up to DHC attention a document that goes through WGLC in Softwires. This is a document that specifies provisioning mechanism for MAP, lw4over6 and possibly other IPv4/IPv6 transition technologies. It defines 8 DHCPv6 options. Some of them are containers and there are many inter-option dependencies (including dependence on PD options), so it's not a straightforward doc. Please post your DHCP-related comments to Softwires list with cc: to dhc. If you have MAP-, lw4over6- or other IPv4/IPv6 transition specific comments, please post them to Softwires only and not to DHC. With my DHC co-chair hat off: I used to be a primary author of that draft around 1,5 years ago. Since then I gave up and didn't follow on the discussions (simply because of lack of time). While technically I'm still listed as a co-author, I can't make any comments on the quality or correctness of this draft. Tomek -------- Original Message -------- Subject: [Softwires] Working group last call for draft-ietf-softwire-map-dhcp-07 Date: Mon, 7 Apr 2014 00:37:35 -0400 From: Suresh Krishnan To: Softwires WG CC: Yong Cui Hi all, This message starts a two week softwire working group last call on advancing the draft about the DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients as a Standards Track RFC. The authors believe that this version has addressed all the issues raised on the document. The latest version of the draft is available at http://www.ietf.org/id/draft-ietf-softwire-map-dhcp-07.txt http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-07 Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. This last call will conclude on April 21 2014. Regards, Suresh & Yong _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From nobody Tue Apr 22 11:31:45 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0561A0226 for ; Tue, 22 Apr 2014 11:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjVeneYI7oEV for ; Tue, 22 Apr 2014 11:31:42 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id EE4301A0242 for ; Tue, 22 Apr 2014 11:31:40 -0700 (PDT) Received: from mail-vc0-f182.google.com ([209.85.220.182]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKU1a1h7p13Am5H7HX2wdZK1cdwtQYF4xf@postini.com; Tue, 22 Apr 2014 11:31:36 PDT Received: by mail-vc0-f182.google.com with SMTP id ib6so3052608vcb.41 for ; Tue, 22 Apr 2014 11:31:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U3BLWyIDHFKegyMrG8ENMS9vS2pTjYsVFK+pggXFgAU=; b=BGyTp04/8VmdcwmPB6pMxaBdVWLHMCu+yWuI3q8/tM6KE4sN4ZtjZtozJP2qEHO8lQ MHIi6sFtkZ9C3CK4gbiajKIUkx0ylgVxVf9VX3k9FHuOQMmn2D+iWq5HmfBUj8IBO7WD nTr3NuQ/4dTsF3AzaGOIUTlncbL3eUmOH9OGgzvoWA8Xzs0chbDdYnN9rji/qABQm9D1 Wi6SP9WxmwZHvQvV3eKsa9rI7s6xFEa1Ndq+Gn9zz6v/o4CySLKGYhI/x2P9eK7RQ64p kPQZ2K/gxkNDgY5vQsz58D9B/TUgR3d+sliDgYDXi8greJphg+HCzTby0Qln4huj23pp METw== X-Gm-Message-State: ALoCoQlxtClBJzWZZ3OUW0w06FdBqSetE8dFu9kVuAVOYUwnsT+Ke0D1vOa1sJB69lwxQF0JyE2HCENHnxE5OzUh5aFMY5Y7dwnvK1NxsE5WOPp4gPpuXtmap/ArVHdFyaozqOhQnx0A X-Received: by 10.58.111.163 with SMTP id ij3mr8501114veb.26.1398191494870; Tue, 22 Apr 2014 11:31:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.111.163 with SMTP id ij3mr8500989veb.26.1398191493307; Tue, 22 Apr 2014 11:31:33 -0700 (PDT) Received: by 10.220.147.79 with HTTP; Tue, 22 Apr 2014 11:31:33 -0700 (PDT) In-Reply-To: <5348284F.4060307@gmail.com> References: <489D13FBFA9B3E41812EA89F188F018E1AF08ACE@xmb-rcd-x04.cisco.com> <5348284F.4060307@gmail.com> Date: Tue, 22 Apr 2014 11:31:33 -0700 Message-ID: From: Andre Kostur To: Tomek Mrugalski Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/5dwKQAyPGtbVigSstnJyj5RQE-E Cc: "dhcwg@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 18:31:44 -0000 Some of the changes have been integrated, but a few discussion points remain: > Also "LEASEQUERY and its extensions...". That's > sort of obvious that bulk and active leasequery are out of scope for > load balancing as they are TCP based, but it's better to be explicit here. I'm a little unclear as to what change is suggested here. Change "LEASEQUERY" to "LEASEQUERY and its extensions" ? > 4. "LEASEQUERY messages with a query based on Client ID SHOULD have load > balancing applied to them". This one is interesting. I would assume that > leasequery messages are sent to specific server directly, so they are > outside of scope for load balancing. Furthermore, I think it is legal to > send QUERY_BY_CLIENTID queries over TCP connection. Obviously, load > balacing is out of scope for any TCP connections. > > I don't have any strong opinion here, but I think leasequery should be > not load balanced at all, regardless of the query type. I talked about > this with Bernie and he seems to agree with that. If you still want to > keep that text, I think it should say "LEASEQUERY message with a > QUERY_BY_CLIENTID that are sent over UDP SHOULD have load balancing > applied to them." The document does already specify that it only applies to UDP DHCPv6 messages. Devices doing leasequery are likely configured to send to all DHCPv6 servers that they know about, and part of the goal is to help reduce the load on the servers. Thinking a little more on this, I agree that in the general case of load balancing, the server's don't necessarily know which server has allocated the IP, so this probably should but a MUST NOT. However, in the case where the servers are sharing lease data, this could be relaxed to a MAY so that it can still take advantage of the lessening of the load. This would come into play when the servers may be under a heavy load already due to their populating having rebooted and the routing element (CMTS?) is rebuilding its IP association tables. > 6. Still in section 3: "DHCPV4-QUERY [I-D.ietf-dhc-dhcpv4-over-dhcpv6] > messages SHOULD NOT be load balanced, but should be subject to DHCPv4 > load balncing, if the server supports it.". Did you want the second > "should" to be capitalized? > > That one is interesting. Right now the DHCPv6 relay does not need to do > any special about DHCPv4-over-DHCPv6 messages, just forward them towards > the server (it may do fancy things, but it doesn't have to). With this > statement, suddenly it becomes much more complex, as the DHCPv6 relay > should become DHCPv4 aware, DHCPv4 LB aware and have separate > configuration for DHCPv4 LB. Nowadays, realistically speaking relays > which do LB for DHCPv6 will also do LB for DHCPv4. But this may not be > the case in a decade or so. According to that draft, the relays don't participate in the v4 decisions. If they receive a DHCPV4-QUERY, they may send those messages to a different server than their general DHCPv6 servers. Where this comes into play is on the DHCP 4o6 Server. I'd like those servers to not decide on load balancing based on the DHCPv6 properties, but to make that decision based on the DHCPv4 properties if the 4o6 server has implemented DHCPv4 load balancing. -- Andre Kostur From nobody Tue Apr 22 12:46:02 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9977D1A0265 for ; Tue, 22 Apr 2014 12:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B7S2E5ejCwL for ; Tue, 22 Apr 2014 12:45:54 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 828011A016E for ; Tue, 22 Apr 2014 12:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5962; q=dns/txt; s=iport; t=1398195917; x=1399405517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AQ3SEssHjUdO/lVoi2gX7Gi89I4bngrkWHdAAuYhcgA=; b=WUalzD7TwiZUQyI8aW74GxgM3K/PxM62+UUS5NqQ11lC3jkxN4EPdyJq iihr50AHbHceXHZ5fnc8FQBfoosKj+O8nyzJ00Sd/GObomkf6SjXDLAlF HVxeArMLq+2R3O1vjRaaHlCLXP0MgefQ3D3tKpV+gpbR1kGgKR7eHaGNf U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FANfFVlOtJV2d/2dsb2JhbABZgwaBJoMPwQ8ZfRZ0giUBAQEDAQ4VETENBwUHBAIBCA4DBAEBAwIGHQMCAgIwFAEICAEBBAENBQiIMQirBqIbF4EpjHwxBwaCaTWBFAEDq0KBcoE/gis X-IronPort-AV: E=Sophos;i="4.97,905,1389744000"; d="scan'208";a="37833654" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 22 Apr 2014 19:45:10 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3MJjA2u000978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 19:45:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 14:45:09 -0500 From: "Bernie Volz (volz)" To: Andre Kostur , Tomek Mrugalski Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014 Thread-Index: Ac8+ZAWxLB0+cGh7TmezKNoQaI9GngXcpL+AAisZhYAACFzlMA== Date: Tue, 22 Apr 2014 19:45:09 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFF33D7@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AF08ACE@xmb-rcd-x04.cisco.com> <5348284F.4060307@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/B4hmPXiNaz6HX5hDSCWItSOodjQ Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 19:45:59 -0000 UmVnYXJkaW5nIExlYXNlcXVlcnksIEknZCBwcmVmZXIgdG8gbm90IGRvIGxvYWQgYmFsYW5jaW5n IG9uIHRoZXNlLg0KDQpUaGVyZSdzIG5vdCBtdWNoIHJlYXNvbiB0byBsb2FkIGJhbGFuY2UgdGhl c2UgYmVjYXVzZSB0aGV5IGdlbmVyYWxseSBhcmUgdmVyeSAnY2hlYXAnIGZvciBhIHNlcnZlciB0 byBwcm9jZXNzIChubyBkYXRhYmFzZSB3cml0ZXMsIGV0Yy4pLiBBbmQsIHRoZXJlIGlzbid0IGEg Y2xlYXIgcGF0aCBmb3IgaG93IHRoZSByZXF1ZXN0IGdvdCB0byB0aGUgc2VydmVyIChpLmUuLCB3 ZW50IHRocm91Z2ggcmVsYXkgb3Igbm90KSwgc28gaXQgaXMgbW9yZSBkaWZmaWN1bHQgdG8ga25v dyBpZiBhbGwgc2VydmVycyBnb3QgdGhlIHJlcXVlc3QgKHRob3VnaCBjZXJ0YWlubHkgaWYgeW91 IG1hbmRhdGUgdGhhdCBzb21lIExlYXNlcXVlcnkgcmVxdWVzdHMgY2FuIGJlIGxvYWQgYmFsYW5j ZWQsIHlvdSdkIGFsc28gaGF2ZSB0byBtYW5kYXRlIHRoYXQgYXQgbGVhc3QgdGhvc2UgcmVxdWVz dHMgYXJlIHNlbnQgdG8gYWxsIG9mIHRoZSBsb2FkIGJhbGFuY2luZyBzZXJ2ZXJzKS4NCg0KQW5k IHRoZXJlIGFyZSBhbHNvIHNvbWUgZmFpbG92ZXIgaW50ZXJhY3Rpb25zIChhdCBsZWFzdCB0aGVy ZSB3ZXJlIHdpdGggdjQgYmVjYXVzZSBvZiBsYXp5IHVwZGF0ZSBhbmQgaWYgbG9hZCBiYWxhbmNp bmcgaXMgdXNlZCBpbiB0aGUgZmFpbG92ZXIgcmVsYXRpb25zaGlwKSB0aGF0IGNhbiByZXN1bHQg aW4gdGhlIHdyb25nIGFuc3dlci4NCg0KLSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEFuZHJlIEtvc3R1ciBbbWFpbHRvOmFrb3N0dXJAaW5jb2duaXRvLmNvbV0g DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyMiwgMjAxNCAyOjMyIFBNDQpUbzogVG9tZWsgTXJ1Z2Fs c2tpDQpDYzogQmVybmllIFZvbHogKHZvbHopOyBkaGN3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtkaGN3Z10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LWxvYWQtYmFsYW5jaW5nLTAx IC0gUmVzcG9uZCBieSBNYXJjaCAzMSwgMjAxNA0KDQpTb21lIG9mIHRoZSBjaGFuZ2VzIGhhdmUg YmVlbiBpbnRlZ3JhdGVkLCBidXQgYSBmZXcgZGlzY3Vzc2lvbiBwb2ludHMgcmVtYWluOg0KDQo+ IEFsc28gIkxFQVNFUVVFUlkgYW5kIGl0cyBleHRlbnNpb25zLi4uIi4gVGhhdCdzIHNvcnQgb2Yg b2J2aW91cyB0aGF0IA0KPiBidWxrIGFuZCBhY3RpdmUgbGVhc2VxdWVyeSBhcmUgb3V0IG9mIHNj b3BlIGZvciBsb2FkIGJhbGFuY2luZyBhcyB0aGV5IA0KPiBhcmUgVENQIGJhc2VkLCBidXQgaXQn cyBiZXR0ZXIgdG8gYmUgZXhwbGljaXQgaGVyZS4NCg0KSSdtIGEgbGl0dGxlIHVuY2xlYXIgYXMg dG8gd2hhdCBjaGFuZ2UgaXMgc3VnZ2VzdGVkIGhlcmUuICBDaGFuZ2UgIkxFQVNFUVVFUlkiIHRv ICJMRUFTRVFVRVJZIGFuZCBpdHMgZXh0ZW5zaW9ucyIgPw0KDQo+IDQuICJMRUFTRVFVRVJZIG1l c3NhZ2VzIHdpdGggYSBxdWVyeSBiYXNlZCBvbiBDbGllbnQgSUQgU0hPVUxEIGhhdmUgDQo+IGxv YWQgYmFsYW5jaW5nIGFwcGxpZWQgdG8gdGhlbSIuIFRoaXMgb25lIGlzIGludGVyZXN0aW5nLiBJ IHdvdWxkIA0KPiBhc3N1bWUgdGhhdCBsZWFzZXF1ZXJ5IG1lc3NhZ2VzIGFyZSBzZW50IHRvIHNw ZWNpZmljIHNlcnZlciBkaXJlY3RseSwgDQo+IHNvIHRoZXkgYXJlIG91dHNpZGUgb2Ygc2NvcGUg Zm9yIGxvYWQgYmFsYW5jaW5nLiBGdXJ0aGVybW9yZSwgSSB0aGluayANCj4gaXQgaXMgbGVnYWwg dG8gc2VuZCBRVUVSWV9CWV9DTElFTlRJRCBxdWVyaWVzIG92ZXIgVENQIGNvbm5lY3Rpb24uIA0K PiBPYnZpb3VzbHksIGxvYWQgYmFsYWNpbmcgaXMgb3V0IG9mIHNjb3BlIGZvciBhbnkgVENQIGNv bm5lY3Rpb25zLg0KPg0KPiBJIGRvbid0IGhhdmUgYW55IHN0cm9uZyBvcGluaW9uIGhlcmUsIGJ1 dCBJIHRoaW5rIGxlYXNlcXVlcnkgc2hvdWxkIGJlIA0KPiBub3QgbG9hZCBiYWxhbmNlZCBhdCBh bGwsIHJlZ2FyZGxlc3Mgb2YgdGhlIHF1ZXJ5IHR5cGUuIEkgdGFsa2VkIGFib3V0IA0KPiB0aGlz IHdpdGggQmVybmllIGFuZCBoZSBzZWVtcyB0byBhZ3JlZSB3aXRoIHRoYXQuIElmIHlvdSBzdGls bCB3YW50IHRvIA0KPiBrZWVwIHRoYXQgdGV4dCwgSSB0aGluayBpdCBzaG91bGQgc2F5ICJMRUFT RVFVRVJZIG1lc3NhZ2Ugd2l0aCBhIA0KPiBRVUVSWV9CWV9DTElFTlRJRCB0aGF0IGFyZSBzZW50 IG92ZXIgVURQIFNIT1VMRCBoYXZlIGxvYWQgYmFsYW5jaW5nIA0KPiBhcHBsaWVkIHRvIHRoZW0u Ig0KDQpUaGUgZG9jdW1lbnQgZG9lcyBhbHJlYWR5IHNwZWNpZnkgdGhhdCBpdCBvbmx5IGFwcGxp ZXMgdG8gVURQIERIQ1B2NiBtZXNzYWdlcy4gIERldmljZXMgZG9pbmcgbGVhc2VxdWVyeSBhcmUg bGlrZWx5IGNvbmZpZ3VyZWQgdG8gc2VuZCB0byBhbGwgREhDUHY2IHNlcnZlcnMgdGhhdCB0aGV5 IGtub3cgYWJvdXQsIGFuZCBwYXJ0IG9mIHRoZSBnb2FsIGlzIHRvIGhlbHAgcmVkdWNlIHRoZSBs b2FkIG9uIHRoZSBzZXJ2ZXJzLiAgVGhpbmtpbmcgYSBsaXR0bGUgbW9yZSBvbiB0aGlzLCBJIGFn cmVlIHRoYXQgaW4gdGhlIGdlbmVyYWwgY2FzZSBvZiBsb2FkIGJhbGFuY2luZywgdGhlIHNlcnZl cidzIGRvbid0IG5lY2Vzc2FyaWx5IGtub3cgd2hpY2ggc2VydmVyIGhhcyBhbGxvY2F0ZWQgdGhl IElQLCBzbyB0aGlzIHByb2JhYmx5IHNob3VsZCBidXQgYSBNVVNUIE5PVC4gIEhvd2V2ZXIsIGlu IHRoZSBjYXNlIHdoZXJlIHRoZSBzZXJ2ZXJzIGFyZSBzaGFyaW5nIGxlYXNlIGRhdGEsIHRoaXMg Y291bGQgYmUgcmVsYXhlZCB0byBhIE1BWSBzbyB0aGF0IGl0IGNhbiBzdGlsbCB0YWtlIGFkdmFu dGFnZSBvZiB0aGUgbGVzc2VuaW5nIG9mIHRoZSBsb2FkLiAgVGhpcyB3b3VsZCBjb21lIGludG8g cGxheSB3aGVuIHRoZSBzZXJ2ZXJzIG1heSBiZSB1bmRlciBhIGhlYXZ5IGxvYWQgYWxyZWFkeSBk dWUgdG8gdGhlaXIgcG9wdWxhdGluZyBoYXZpbmcgcmVib290ZWQgYW5kIHRoZSByb3V0aW5nIGVs ZW1lbnQgKENNVFM/KSBpcyByZWJ1aWxkaW5nIGl0cyBJUCBhc3NvY2lhdGlvbiB0YWJsZXMuDQoN Cj4gNi4gU3RpbGwgaW4gc2VjdGlvbiAzOiAiREhDUFY0LVFVRVJZIFtJLUQuaWV0Zi1kaGMtZGhj cHY0LW92ZXItZGhjcHY2XSANCj4gbWVzc2FnZXMgU0hPVUxEIE5PVCBiZSBsb2FkIGJhbGFuY2Vk LCBidXQgc2hvdWxkIGJlIHN1YmplY3QgdG8gREhDUHY0IA0KPiBsb2FkIGJhbG5jaW5nLCBpZiB0 aGUgc2VydmVyIHN1cHBvcnRzIGl0LiIuIERpZCB5b3Ugd2FudCB0aGUgc2Vjb25kIA0KPiAic2hv dWxkIiB0byBiZSBjYXBpdGFsaXplZD8NCj4NCj4gVGhhdCBvbmUgaXMgaW50ZXJlc3RpbmcuIFJp Z2h0IG5vdyB0aGUgREhDUHY2IHJlbGF5IGRvZXMgbm90IG5lZWQgdG8gDQo+IGRvIGFueSBzcGVj aWFsIGFib3V0IERIQ1B2NC1vdmVyLURIQ1B2NiBtZXNzYWdlcywganVzdCBmb3J3YXJkIHRoZW0g DQo+IHRvd2FyZHMgdGhlIHNlcnZlciAoaXQgbWF5IGRvIGZhbmN5IHRoaW5ncywgYnV0IGl0IGRv ZXNuJ3QgaGF2ZSB0bykuIA0KPiBXaXRoIHRoaXMgc3RhdGVtZW50LCBzdWRkZW5seSBpdCBiZWNv bWVzIG11Y2ggbW9yZSBjb21wbGV4LCBhcyB0aGUgDQo+IERIQ1B2NiByZWxheSBzaG91bGQgYmVj b21lIERIQ1B2NCBhd2FyZSwgREhDUHY0IExCIGF3YXJlIGFuZCBoYXZlIA0KPiBzZXBhcmF0ZSBj b25maWd1cmF0aW9uIGZvciBESENQdjQgTEIuIE5vd2FkYXlzLCByZWFsaXN0aWNhbGx5IHNwZWFr aW5nIA0KPiByZWxheXMgd2hpY2ggZG8gTEIgZm9yIERIQ1B2NiB3aWxsIGFsc28gZG8gTEIgZm9y IERIQ1B2NC4gQnV0IHRoaXMgbWF5IA0KPiBub3QgYmUgdGhlIGNhc2UgaW4gYSBkZWNhZGUgb3Ig c28uDQoNCkFjY29yZGluZyB0byB0aGF0IGRyYWZ0LCB0aGUgcmVsYXlzIGRvbid0IHBhcnRpY2lw YXRlIGluIHRoZSB2NCBkZWNpc2lvbnMuICBJZiB0aGV5IHJlY2VpdmUgYSBESENQVjQtUVVFUlks IHRoZXkgbWF5IHNlbmQgdGhvc2UgbWVzc2FnZXMgdG8gYSBkaWZmZXJlbnQgc2VydmVyIHRoYW4g dGhlaXIgZ2VuZXJhbCBESENQdjYgc2VydmVycy4NCldoZXJlIHRoaXMgY29tZXMgaW50byBwbGF5 IGlzIG9uIHRoZSBESENQIDRvNiBTZXJ2ZXIuICBJJ2QgbGlrZSB0aG9zZSBzZXJ2ZXJzIHRvIG5v dCBkZWNpZGUgb24gbG9hZCBiYWxhbmNpbmcgYmFzZWQgb24gdGhlIERIQ1B2NiBwcm9wZXJ0aWVz LCBidXQgdG8gbWFrZSB0aGF0IGRlY2lzaW9uIGJhc2VkIG9uIHRoZSBESENQdjQgcHJvcGVydGll cyBpZiB0aGUgNG82IHNlcnZlciBoYXMgaW1wbGVtZW50ZWQgREhDUHY0IGxvYWQgYmFsYW5jaW5n Lg0KDQotLQ0KQW5kcmUgS29zdHVyDQo= From nobody Wed Apr 23 16:12:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199171A072A for ; Wed, 23 Apr 2014 16:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDP8wQi5kVop for ; Wed, 23 Apr 2014 16:12:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 275EA1A0299 for ; Wed, 23 Apr 2014 16:12:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGA08654; Wed, 23 Apr 2014 23:12:15 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 00:11:33 +0100 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 00:12:14 +0100 Received: from DFWEML703-CHM.china.huawei.com ([169.254.5.104]) by dfweml704-chm.china.huawei.com ([169.254.6.56]) with mapi id 14.03.0158.001; Wed, 23 Apr 2014 16:12:05 -0700 From: John Kaippallimalil To: "volz@cisco.com" , "dhcwg@ietf.org" Thread-Topic: FYI: Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 Thread-Index: AQHPX0lwvXI+YnXlrEmWFnJb/SOmCg== Date: Wed, 23 Apr 2014 23:12:04 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171D9DA006@dfweml703-chm.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171D9D9FEF@dfweml703-chm.china.huawei.com> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171D9D9FEF@dfweml703-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/JV8LVGlhIQbwm6tcQaBxI8QQVbs Cc: "mgrayson@cisco.com" Subject: Re: [dhcwg] FYI: Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 23:12:24 -0000 Hi, I went through the draft and think that it is useful and well written. A couple of comments that you may want to consider: 1. In 6.2, if we have a PLMN Identifier as Network Identifier for 3GPP RAN = network. What would be the Access Technology Type in 6.1. in this case? It may be useful to add some of the RAN types (that apply for PLMNs) to the= ANI list in 6.1. 2. Is it possible to assert that for all ANI changes, there will be a DHCP= request sent by the client. If so, perhaps it would be good to mention thi= s somewhere in the draft. Regards, John > -----Original Message----- > Resent-From: > From: "Bernie Volz (volz)" > Date: April 21, 2014 at 1:30:53 PM PDT > Resent-To: , , > , > To: "draft-ietf-dhc-access-network-identifier@tools.ietf.org" access-network-identifier@tools.ietf.org> > Subject: FYI: Reminder - WGLC for draft-ietf-dhc-access-network-identifie= r-02 > - respond by April 27, 2014 > Hi: >=20 > Not sure if there are some people you can get to review and comment on th= is > draft ... would be good so it doesn't fail WGLC. >=20 > - Bernie >=20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (vol= z) > Sent: Monday, April 21, 2014 9:28 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Reminder - WGLC for draft-ietf-dhc-access-network-identi= fier- > 02 - respond by April 27, 2014 >=20 > Friendly reminder regarding this WGLC. There has been no feedback so far. >=20 > - Bernie >=20 > From: Bernie Volz (volz) > Sent: Saturday, April 12, 2014 10:04 AM > To: dhcwg@ietf.org > Subject: WGLC for draft-ietf-dhc-access-network-identifier-02 - respond b= y > April 27, 2014 >=20 > Folks, the authors of draft-ietf-dhc-access-network-identifier > (http://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-02) > feel it's ready for work group last call. Please review this draft and > indicate whether or not you feel it is ready to be published. >=20 > At the time of this writing, there is no IPR reported against this draft. > Please see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.ht= ml > for a reminder regarding IPR disclosure requirements. >=20 > Tomek and I will evaluate consensus after April 27, 2014. >=20 > Thanks, > Bernie & Tomek From nobody Wed Apr 23 20:20:32 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC541A0794; Wed, 23 Apr 2014 20:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3GoKGE6Rmx1; Wed, 23 Apr 2014 20:20:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 828371A0783; Wed, 23 Apr 2014 20:20:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424032026.8104.6902.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 20:20:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/kAz3n55qS3NIowPQbZ-baUh4ock Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-ipv6-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 03:20:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv4 over IPv6 Transport Authors : Yong Cui Peng Wu Jianping Wu Ted Lemon Qi Sun Filename : draft-ietf-dhc-dhcpv4-over-ipv6-09.txt Pages : 14 Date : 2014-04-23 Abstract: In IPv6 networks, there remains a need to provide IPv4 service for some residual devices. This document describes a mechanism for allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 transport. It is done by putting a special relay agent function (Client Relay Agent) on the client side, as well as extending the behavior of the server; in the case where DHCP server only supports IPv4 transport, a relay agent is extended to support IPv6 transport (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, with a new Relay Agent Information sub-option added to carry the IPv6 address of the Client Relay Agent. DHCPv4 over IPv6 has been developed in the IETF, and some implementations and deployments have been carried out. But this mechanism is not recommended for future implementation or deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-over-ipv6-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 24 08:07:48 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C5B1A035B for ; Thu, 24 Apr 2014 08:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.772 X-Spam-Level: X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0VCGNC4mWYB for ; Thu, 24 Apr 2014 08:07:39 -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 075D71A0394 for ; Thu, 24 Apr 2014 08:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12307; q=dns/txt; s=iport; t=1398352053; x=1399561653; h=from:to:subject:date:message-id:mime-version; bh=PRrGgHpCz8/CgPD4IyaYDEF1lsRTBlRfKr1kY4tCPAg=; b=e6/o9iExxxF3lSfuG5I9QUz11mi6GRKANreqg1kREr1x1AsgCDo879aI VHWKCfWwXob/1T5Hd/7BZLiXD9aujpn086/g64uBzG12E/NkC5Loqe+Im j3WOJRL9+EmC/qeeZbIi+mnu07/AwLsswfKUs5XfKZx2CVnHyEUAL0ksM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAH8nWVOtJA2K/2dsb2JhbABZgkJET1fENoEaFnSCJQEBAQQtXgEZBAEBCx05FAkJAQQTCIg5DZkbsiwXjic3gyWBFQSaLZEegXKBP4Ir X-IronPort-AV: E=Sophos;i="4.97,919,1389744000"; d="scan'208,217";a="320078544" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 24 Apr 2014 15:07:32 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3OF7Wop028372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Apr 2014 15:07:32 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 10:07:32 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Results of WGLC for draft-ietf-dhc-addr-registration-04 - respond by April 13, 2014 Thread-Index: Ac9fzYaIb7AonmV8SWSTtd6w1vvIMg== Date: Thu, 24 Apr 2014 15:07:31 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFF6F6B@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.124] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AFF6F6Bxmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/pRtXujpLZuOlyUrYn-3pAy7Slvo Subject: [dhcwg] Results of WGLC for draft-ietf-dhc-addr-registration-04 - respond by April 13, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:07:43 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AFF6F6Bxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for being a little late with this WGLC results announcement. But the co-chairs feel that there wasn't sufficient support for this docume= nt (not just during the WGLC). And there were issues raised (by Marcin and = myself). I believe the way forward is: 1. Update the document based on the comments (before and after last c= all). 2. Find a few additional reviewers (over those that did in this last = call), who will agree to review it during the next WGLC. (Perhaps this will= need to await the Toronto meeting; if so authors may want to consider a s= hort agenda item to promote the draft and get reviewers.) 3. Schedule another WGLC. It is a bit frustrating as it would be nice to get this moved along (it is = just now 2 years since the WG -00 draft was published). - Bernie & Tomek From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Saturday, March 29, 2014 10:04 AM To: dhcwg@ietf.org Subject: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-04 - respond by = April 13, 2014 Folks, the authors of draft-ietf-dhc-addr-registration (http://tools.ietf.o= rg/html/draft-ietf-dhc-addr-registration-04) feel it's ready for work group last call. Please review this draft and indi= cate whether or not you feel it is ready to be published. At the time of this writing, there is no IPR reported against this draft. Tomek and I will evaluate consensus after April 13, 2014. Thanks, Bernie & Tomek --_000_489D13FBFA9B3E41812EA89F188F018E1AFF6F6Bxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry for being a litt= le late with this WGLC results announcement.

 

But the co-chairs feel= that there wasn’t sufficient support for this document (not just dur= ing the WGLC). And there were issues raised (by Marcin and myself).

 

I believe the way forw= ard is:

1.&n= bsp;      Update the doc= ument based on the comments (before and after last call).=

2.&n= bsp;      Find a few add= itional reviewers (over those that did in this last call), who will agree t= o review it during the next WGLC. (Perhaps this will need to await the Toro= nto meeting;  if so authors may want to consider a short agenda item to promote the draft and get reviewers.)

3.&n= bsp;      Schedule anoth= er WGLC.

 

It is a bit frustratin= g as it would be nice to get this moved along (it is just now 2 years since= the WG -00 draft was published).

 

-&nb= sp;         Bernie & T= omek

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Saturday, March 29, 2014 10:04 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-04 - resp= ond by April 13, 2014

 

Folks, the authors of draft-ietf-dhc-addr-registr= ation (http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-04)=

feel it's ready for work group last call. Please = review this draft and indicate whether or not you feel it is ready to be pu= blished.

 

At the time of this writing, there is no IPR repo= rted against this draft.

 

Tomek and I will evaluate consensus after April 1= 3, 2014.

 

Thanks,

Bernie & Tomek

 

--_000_489D13FBFA9B3E41812EA89F188F018E1AFF6F6Bxmbrcdx04ciscoc_-- From nobody Sat Apr 26 00:54:16 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FCF1A030D for ; Sat, 26 Apr 2014 00:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.46 X-Spam-Level: ** X-Spam-Status: No, score=2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKFsfHJb069Y for ; Sat, 26 Apr 2014 00:54:11 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 25D1A1A0700 for ; Sat, 26 Apr 2014 00:54:09 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 4116D1748167 for ; Sat, 26 Apr 2014 16:54:02 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEI9XhexFnMN for ; Sat, 26 Apr 2014 16:53:58 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 3AC981748161 for ; Sat, 26 Apr 2014 16:53:58 +0900 (JST) Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 2E3F21B9AC for ; Sat, 26 Apr 2014 16:40:03 +0900 (JST) Message-ID: <535B6614.7020503@kddilabs.jp> Date: Sat, 26 Apr 2014 16:53:56 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/FUY84tfUrqAYzFKFlGUYsCdfAsg Subject: [dhcwg] Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 07:54:15 -0000 Dear all,

I reviewed the I-D and think it is in good shape for publication. Maybe one more cycle of revision would be beneficial. I add my comments below, most of which are for clarification.
 
 
===================

4.  DHCPv4 Access-Network-Identifier Option

   Access network identifier option carries information to identify the
   access network to which the client is attached to.  This information
   includes access technology type, network identifier and access
   network operator identifiers.

   The format of the DHCPv4 Access-Network-Identifier option is shown
   below.


   Code    Len          ANI Sub-options
  +------+------+------+------+------+--   --+-----+
  | code |  len |  s1  |  s2  |  s2  |  ...  |  sn |
  +------+------+------+------+------+--   --+-----+

   code: 8-bit code carrying Access Network Identifier sub-options,
         If added by relay agent: Relay Agent Information Option (82)
         If added by client: OPTION_ACCESS_NETWORK_ID (TBD1)

[HY] It should be resolved which option to be used (82 or TBD1) at this point.

   len: 8 bit indicating total length of the included suboptions.

[HY] The following sub-option format should go into Section 4.1

   ANI Sub-options: The  ANI Sub-options consists of a
     sequence of SubOpt/Length/Value tuples for each sub-option, encoded
     in the following manner:

   SubOpt   Len     Sub-option Value
   +------+------+------+------+------+------+--...-+------+
   | code |   N  |  s1  |  s2  |  s3  |  s4  |      |  sN  |
   +------+------+------+------+------+------+--...-+------+

  ANI Sub-options are defined in following sections.

4.1.  DHCPv4 Access-Network-Identifier Sub-options

   Access network identifier information will be defined in multiple
   sub-options.  The initial assignment of DHCP access network
   identifier Sub-options is as follows:








Bhandari, et al.         Expires August 17, 2014                [Page 5]

Internet-Draft           DHCPv4 & v6 ANI options           February 2014


           Sub-option Code            Sub-Option Description
          ---------------            ----------------------
               TBD7                   Access-Network-Type Sub-option
               TBD8                   Network-Name Sub-option
               TBD9                   AP-Name Sub-option
               TBD12                  AP-BSSID Sub-option
               TBD10                  Operator-Identifier Sub-option
               TBD11                  Operator-Realm Sub-option



5.  DHCPv6 Access-Network-Identifier options

   The Access Network Identifier option defined here will be added by
   DHCPv6 client in upstream DHCPv6 messages or by the Relay in Relay-
   forward messages.

           Option Code             Descrption
          ---------------   ----------------------
              TBD2           OPTION_ANI_ATT
              TBD3           OPTION_ANI_NETWORK_NAME
              TBD4           OPTION_ANI_AP_NAME
              TBD13          OPTION_ANI_AP_BSSID
              TBD5           OPTION_ANI_OPERATOR_ID
              TBD6           OPTION_ANI_OPERATOR_REALM



6.  DHCPv4 and DHCPv6 Access-Network-Identifier Options

   This section defines DHCPv4 suboption and DHCPv6 options for access
   network identification.

6.1.  Access-Network-Type option

[HY] Access-Network-Type (Sub-)option [Sub-option for DHCPv4, Option for DHCPv6]

   This option is used for exchanging the type of the access technology
   the client is attached to the network.  Its format is as follows:














Bhandari, et al.         Expires August 17, 2014                [Page 6]

Internet-Draft           DHCPv4 & v6 ANI options           February 2014


   DHCPv4:
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | suboption-code|   Length      |          ATT                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    suboption-code:  8-bit code, it should be set to value of (TBD7),
                      indicating that its a Access-Network-Type sub-option

    Length: 8-bit unsigned integer indicating the length of this suboption
        in octets, excluding the suboption-code and length fields.
        This field MUST be set to 2.

[HY] According to RFC5213, the length of ATT is 1 octet. if 2 octets is preferred, 1 octet of reserved field should be prepended.

   DHCPv6:
    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 Code (TBD2)      |            OptLen             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       ATT                                     +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   option-code:        16-bit code OPTION_ANI_ATT (TBD2)
   option-length:      16-bit unsigned integer indicating length
                       in octets of this option

[HY] It should be specified which value to be set in oOptLen and the same argument as the above.

   Common format applicable to DHCPv4 and DHCPv6:
   Access Technology Type (ATT)

        An 16-bit field that specifies the access technology through
        which the client is connected to the access link.

        The values is as populated from the IANA name space
        Access Technology Type Option type values as requested in [RFC5213]

        0: Reserved         ("Reserved")
        1: Virtual          ("Logical Network Interface")
        2: PPP              ("Point-to-Point Protocol")
        3: IEEE 802.3       ("Ethernet")
        4: IEEE 802.11a/b/g ("Wireless LAN")
        5: IEEE 802.16e     ("WIMAX")

[HY] IANA assigns more than these values (0-12). Refer to the following link:
  http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml#mobility-parameters-10







Bhandari, et al.         Expires August 17, 2014                [Page 7]

Internet-Draft           DHCPv4 & v6 ANI options           February 2014


6.2.  Network-Identifier options

[HY] Network-Identifier (Sub-)options 
 Note: "(Sub-)options for Network identifier" may be better for a general name.

   These options can be used for carrying the name of the access network
   (e.g., a SSID in case of IEEE 802.11 Access Network, or PLMN
   Identifier [TS23003] in case of 3GPP access ) and Access Point name,
   to which the client is attached.  The format of these options is
   defined below.



   DHCPv4:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |suboption code |   Length      |                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Network Name (e.g., SSID or PLMNID)       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   suboption code:  8-bit code, it should be set to value of (TBD8),
                    indicating that its a Network-Name sub-option

   Length:  8-bit indicating Total length of this sub option,
           excluding the suboption code and length fields.
           The value can be in the range of 2 to 32 octets.


[HY] "Total length" is misleading since this does not include the subopt code and length fields. I recommend "the length" instead.

   DHCPv6:
    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 Code (TBD3)      |            OptLen             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Network Name (e.g., SSID or PLMNID)       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   option-code:        16-bit code OPTION_ANI_NETWORK_NAME (TBD3)
   option-length:      16-bit unsigned integer indicating length
                       in octets of this option.The value can be in the
                       range of 2 to 32 octets.

   Common format applicable to DHCPv4 and DHCPv6:


   Network Name:  The name of the access network to which the mobile



Bhandari, et al.         Expires August 17, 2014                [Page 8]

Internet-Draft           DHCPv4 & v6 ANI options           February 2014


      node is attached.  The type of the Network Name is dependent on
      the access technology to which the mobile node is attached.  If it
      is 802.11 access, the Network Name MUST be the SSID of the
      network.  If the access network is 3GPP access, the Network Name
      is the PLMN Identifier of the network.  If the access network is
      3GPP2 access, the Network Name is the
      Access Network Identifier [ANI].

      When encoding the PLMN Identifier, both the Mobile Network Code
      (MNC) [TS23003] and Mobile Country Code (MCC) [TS23003] MUST be 3
      digits.  If the MNC in use only has 2 digits, then it MUST be
      preceded with a '0'.  Encoding MUST be UTF-8.







































Bhandari, et al.         Expires August 17, 2014                [Page 9]

Internet-Draft           DHCPv4 & v6 ANI options           February 2014


   DHCPv4:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |suboption code |   Length      |                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Access-Point Name                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   suboption code: 8-bit code, it should be set to value of (TBD9),
                   indicating that its a Network-AP-Name sub-option

[HY] "Network-AP-Name sub-option" -> "AP-Name Sub-option".

   Length:  8-bit indicating Total length of this sub option,
           excluding the suboption code and length fields.
           The value can be in the range of 2 to 32 octets.

[HY] Same argument for "Total length".

   DHCPv6:

    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 Code (TBD3)      |          OptLen               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Access-Point Name                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code:        16-bit code OPTION_ANI_AP_NAME (TBD4)
   option-length:      16-bit unsigned integer indicating length
                       in octets of this option.The value can be in the
                       range of 2 to 32 octets.

   Common format applicable to DHCPv4 and DHCPv6:

   Access-Point Name:   The name of the access point (physical device
      name) to which the mobile node is attached.  This is the
      identifier that uniquely identifies the access point.  While
      Network Name (e.g., SSID) identifies the operator's access
      network, Access-Point Name identifies a specific network device in
      the network to which the mobile node is attached.  In some
      deployments, the Access-Point Name can be set to the Media Access
      Control (MAC) address of the device or some unique identifier that
      can be used by the policy systems in the operator network to
      unambiguously identify the device.  The string is carried in UTF-8
      representation.


[HY] 3GPP also defines "Access Point Name (APN)" as a reference to GGSN/PGW according to [TS23003]. This should be disambiguated. 




Bhandari, et al.         Expires August 17, 2014               [Page 10]

Internet-Draft           DHCPv4 & v6 ANI options           February 2014


   DHCPv4:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |suboption code |   Length(6)      |                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        Access-Point BSSID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   suboption code: 8-bit code, it should be set to value of (TBD12),
                   indicating that its a AP-BSSID sub-option

   Length:  8-bit indicating Total length of this sub option,
           excluding the suboption code and length fields.
           The value is set to 6.

[HY] Same argument for "Total length".

   DHCPv6:

    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 Code (TBD3)      |          OptLen(6)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Access-Point BSSID                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   option-code:        16-bit code OPTION_ANI_AP_BSSID (TBD13)
   option-length:      16-bit unsigned integer indicating length
                       in octets of this option.The value is set to 6.

   Common format applicable to DHCPv4 and DHCPv6:

   Access-Point BSSID:   The 48-bit Basic service set identification(BSSID)
      of the access point to which the mobile node is attached.

6.3.  Operator identifier options

[HY] "Operator-Identifier (Sub-)option 

   The Operator identifier options can be used for carrying the operator
   identifier of the access network to which the client is attached.

[HY] The Vendor-specific suboption for Relay agent option [RFC4243] can carry the same type of information. Any thought on that? 

   The format of these options is defined below.









Bhandari, et al.         Expires August 17, 2014               [Page 11]

Internet-Draft           DHCPv4 & v6 ANI options           February 2014


 DHCPv4:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | suboptioncode |     Length    |                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~      Operator Enterprise ID   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   suboption code:  8 bit code, It should be set to value of (TBD10),
                  indicating that it is Operator-Identifier sub-option

   Length:  Total length of this sub option, excluding the suboption code
      and length fields.

[HY] 8 bit of length? Also, the same argument for "Total length". The value can be  fixed to "32".

 DHCPv6:
    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 Code (TBD4)      |            OptLen             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Operator Enterprise ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   option-code:        16-bit code OPTION_ANI_OPERATOR_ID (TBD5)
   option-length:      16-bit unsigned integer indicating length
                       in octets of this option.

[HY] The Vendor-specific suboption for Relay agent option [RFC4243] can carry the same type of information. Any thought on that? 

   The format of these options is defined below.









Bhandari, et al.         Expires August 17, 2014               [Page 11]

Internet-Draft           DHCPv4 & v6 ANI options           February 2014


 DHCPv4:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | suboptioncode |     Length    |                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~      Operator Enterprise ID   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   suboption code:  8 bit code, It should be set to value of (TBD10),
                  indicating that it is Operator-Identifier sub-option

   Length:  Total length of this sub option, excluding the suboption code
      and length fields.

[HY] The value can be  fixed to "32".

 Common format applicable to DHCPv4 and DHCPv6:

   Operator Enterprise ID: Vendor ID as a four octet
                           Private Enterprise Number [SMI].
















Bhandari, et al.         Expires August 17, 2014               [Page 12]

Internet-Draft           DHCPv4 & v6 ANI options           February 2014


  DHCPv4:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | suboptioncode |     Length    |                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                        Operator Realm                         ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    suboption code:  8 bit code, It should be set to value of (TBD11),
                   indicating that it is Operator-Realm sub-option

    Length:  Total length of this sub option, excluding the suboption
       code and length fields.
[HY] The Vendor-specific suboption for Relay agent option [RFC4243] can carry the same type of information. Any thought on that? 

   The format of these options is defined below.









Bhandari, et al.         Expires August 17, 2014               [Page 11]

Internet-Draft           DHCPv4 & v6 ANI options           February 2014


 DHCPv4:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | suboptioncode |     Length    |                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~      Operator Enterprise ID   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   suboption code:  8 bit code, It should be set to value of (TBD10),
                  indicating that it is Operator-Identifier sub-option

   Length:  Total length of this sub option, excluding the suboption code
      and length fields.

[HY] 8 bit of length? Also, the same argument for "Total length".

  DHCPv6:
     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 Code (TBD4)      |              OptLen           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                       Operator Realm                          ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    option-code:        16-bit code OPTION_ANI_OPERATOR_REALM (TBD6)
    option-length:      16-bit unsigned integer indicating length
                        in octets of this option.

  Common format applicable to DHCPv4 and DHCPv6:

  Operator Realm:  Realm of the operator. Realm names are required to be
          unique, and are piggybacked on the administration of the DNS
          namespace.  Realms are encoded using a domain name encoding
          defined in [RFC1035].Up to 253 octets of the operator realm.

[HY] According to RFC1035, the maximum length of a domain name is 255. if it has more than 253, is it truncated? If so, how?


13.  Change log

   Changes from 00 - 01

[HY] Changes from 01 - 02 ?

   o  Added AP BSSID information

   Changes from 00 - 01

   o  Edited security consideration to handle multiple relay agents
      adding access network identifier options, server and relay agent
      behavior.

===================



-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
From nobody Sun Apr 27 06:36:43 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9811A079C for ; Sun, 27 Apr 2014 05:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWI2VmNwo4HE for ; Sun, 27 Apr 2014 05:55:06 -0700 (PDT) Received: from mail-gw3-out.broadcom.com (mail-gw3-out.broadcom.com [216.31.210.64]) by ietfa.amsl.com (Postfix) with ESMTP id D8EE21A0793 for ; Sun, 27 Apr 2014 05:55:06 -0700 (PDT) X-IronPort-AV: E=Sophos; i="4.97,937,1389772800"; d="scan'208,217"; a="26330779" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 27 Apr 2014 06:14:55 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sun, 27 Apr 2014 05:55:05 -0700 Received: from SJEXCHMB09.corp.ad.broadcom.com ([fe80::3da7:665e:cc78:181f]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Sun, 27 Apr 2014 05:55:05 -0700 From: Florin Baboescu To: "dhcwg@ietf.org" Thread-Topic: FYI: Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 Thread-Index: Ac9doILj82Kfys30SmaZENYan8+l5AC1GnEAAGibt8A= Date: Sun, 27 Apr 2014 12:55:05 +0000 Message-ID: References: <489D13FBFA9B3E41812EA89F188F018E1AFF17B1@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: [10.16.203.100] Content-Type: multipart/alternative; boundary="_000_FF83B7C4E3E20340A64DE85B768F08282AF5F6F8SJEXCHMB09corpa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/RAT4j4AbbHHzmnIGKHiLaIXQ22Q X-Mailman-Approved-At: Sun, 27 Apr 2014 06:36:40 -0700 Subject: [dhcwg] FW: FYI: Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 12:55:08 -0000 --_000_FF83B7C4E3E20340A64DE85B768F08282AF5F6F8SJEXCHMB09corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bernie, I also believe that this contribution is well written and ready to be publi= shed. Thank you. -Florin Baboescu From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, April 21, 2014 9:28 AM To: dhcwg@ietf.org Subject: [dhcwg] Reminder - WGLC for draft-ietf-dhc-access-network-identifi= er-02 - respond by April 27, 2014 Friendly reminder regarding this WGLC. There has been no feedback so far. - Bernie From: Bernie Volz (volz) Sent: Saturday, April 12, 2014 10:04 AM To: dhcwg@ietf.org Subject: WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by = April 27, 2014 Folks, the authors of draft-ietf-dhc-access-network-identifier (http://tool= s.ietf.org/html/draft-ietf-dhc-access-network-identifier-02) feel it's ready for work group last call. Please review this draft and indi= cate whether or not you feel it is ready to be published. At the time of this writing, there is no IPR reported against this draft. P= lease see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html = for a reminder regarding IPR disclosure requirements. Tomek and I will evaluate consensus after April 27, 2014. Thanks, Bernie & Tomek --_000_FF83B7C4E3E20340A64DE85B768F08282AF5F6F8SJEXCHMB09corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bernie,

I also believe that this = contribution is well written and ready to be published.  Thank you.

-Florin Baboescu

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Monday, April 21, 2014 9:28 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Reminder - WGLC for draft-ietf-dhc-access-network-i= dentifier-02 - respond by April 27, 2014=

 

Friendly reminder regarding this WGL= C. There has been no feedback so far.

 

- &nbs= p;        Bernie

 

From: Bernie Volz (volz)
Sent: Saturday, April 12, 2014 10:04 AM
To: dhcwg@ietf.org
Subject: WGLC for draft-ietf-dhc-access-network-identifier-02 - resp= ond by April 27, 2014<= /p>

 

Folks, the authors of dr= aft-ietf-dhc-access-network-identifier (http://tools.ietf.org/html/= draft-ietf-dhc-access-network-identifier-02)

feel it's ready for work= group last call. Please review this draft and indicate whether or not you = feel it is ready to be published.

 =

At the time of this writ= ing, there is no IPR reported against this draft. Please see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html for = a reminder regarding IPR disclosure requirements.

 =

Tomek and I will evaluat= e consensus after April 27, 2014.

 =

Thanks,

Bernie & Tomek<= /o:p>

 

--_000_FF83B7C4E3E20340A64DE85B768F08282AF5F6F8SJEXCHMB09corpa_-- From nobody Sun Apr 27 06:39:49 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30451A04F8 for ; Sun, 27 Apr 2014 06:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3P6US323h81V for ; Sun, 27 Apr 2014 06:39:45 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2D31A04A3 for ; Sun, 27 Apr 2014 06:39:45 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id lh4so129029vcb.20 for ; Sun, 27 Apr 2014 06:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RCcCR1MCyNv5IBVEVcOfPQhzKvh8525ged83AKx2YPg=; b=WZSdEdxcWxJhAm1ifA83AxC850vo/rZGAl3uVDElWcmPAa6qOinRR5WSSMJ85yR+TA czzETReYGnBhN3FpmWAxDql8QlRFpUjHOaB4tjePGOSkJny20ITLCfAwUCux9fZ1YK4A UnVveO/VUipfN9a5ckj3s+HubaGsBkml1icMIx1aiED7BxFeKs9n606quOAbDegJd+yC nSym0QfgxF8ny/iWM+SaRSoYH2V55XAzZqpgQDmGrk8wtURGLrLiTU9RmoQH6T9yx6bS 7A7VYAJf/INOVXekdJ30+dlU7KOD+uKvrR8lv/yy/4QpNZ7S49M+0WH6rIvqnTtdVtsL xXkg== MIME-Version: 1.0 X-Received: by 10.220.167.2 with SMTP id o2mr18135157vcy.8.1398605985129; Sun, 27 Apr 2014 06:39:45 -0700 (PDT) Received: by 10.220.252.132 with HTTP; Sun, 27 Apr 2014 06:39:45 -0700 (PDT) In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171D9DA006@dfweml703-chm.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171D9D9FEF@dfweml703-chm.china.huawei.com> <6561EABF52675C45BCDACA1B4D7AA1171D9DA006@dfweml703-chm.china.huawei.com> Date: Sun, 27 Apr 2014 21:39:45 +0800 Message-ID: From: Hui Deng To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=089e011618ceecb48304f8065492 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/XLyGPwK1u2Ez3_fu0-2LaGozDVQ Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] FYI: Reminder - WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 13:39:47 -0000 --089e011618ceecb48304f8065492 Content-Type: text/plain; charset=UTF-8 Hello all I believe this draft is well written and ready for WGLC, here are two comments 1: the document may consider to identify 11ac in access technology type since it has been widely supported already 2: if MAG is implemented in HeNB(Smallcell), does this make any difference like network name? do you consider 20bit macrocell ID? Thanks for your work -Hui > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz > (volz) > > Sent: Monday, April 21, 2014 9:28 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Reminder - WGLC for > draft-ietf-dhc-access-network-identifier- > > 02 - respond by April 27, 2014 > > > > Friendly reminder regarding this WGLC. There has been no feedback so far. > > > > - Bernie > > > > From: Bernie Volz (volz) > > Sent: Saturday, April 12, 2014 10:04 AM > > To: dhcwg@ietf.org > > Subject: WGLC for draft-ietf-dhc-access-network-identifier-02 - respond > by > > April 27, 2014 > > > > Folks, the authors of draft-ietf-dhc-access-network-identifier > > (http://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-02) > > feel it's ready for work group last call. Please review this draft and > > indicate whether or not you feel it is ready to be published. > > > > At the time of this writing, there is no IPR reported against this draft. > > Please see > http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html > > for a reminder regarding IPR disclosure requirements. > > > > Tomek and I will evaluate consensus after April 27, 2014. > > > > Thanks, > > Bernie & Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --089e011618ceecb48304f8065492 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all

I believe this dra= ft is well written and ready for WGLC, here are two comments
1: t= he document may consider to identify 11ac in access technology type since i= t has been widely supported already
2: if MAG is implemented in HeNB(Smallcell), does this make any differ= ence like network name? do you consider 20bit macrocell ID?

<= /div>
Thanks for your work

-Hui


> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)=
> Sent: Monday, April 21, 2014 9:28 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Reminder - WGLC for draft-ietf-dhc-access-network-ide= ntifier-
> 02 - respond by April 27, 2014
>
> Friendly reminder regarding this WGLC. There has been no feedback so f= ar.
>
> - =C2=A0 =C2=A0 Bernie
>
> From: Bernie Volz (volz)
> Sent: Saturday, April 12, 2014 10:04 AM
> To: dhcwg@ietf.org
> Subject: WGLC for draft-ietf-dhc-access-network-identifier-02 - respon= d by
> April 27, 2014
>
> Folks, the authors of draft-ietf-dhc-access-network-identifier
> (http://tools.ietf.org/html/draft-ietf-dhc-a= ccess-network-identifier-02)
> feel it's ready for work group last call. Please review this draft= and
> indicate whether or not you feel it is ready to be published.
>
> At the time of this writing, there is no IPR reported against this dra= ft.
> Please see http://www.ietf.org/mail-archive/web/dh= cwg/current/msg14143.html
> for a reminder regarding IPR disclosure requirements.
>
> Tomek and I will evaluate consensus after April 27, 2014.
>
> Thanks,
> Bernie & Tomek

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

--089e011618ceecb48304f8065492-- From nobody Sun Apr 27 07:20:19 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4691A0663 for ; Sun, 27 Apr 2014 07:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.251 X-Spam-Level: X-Spam-Status: No, score=-13.251 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCyykBxQ2avQ for ; Sun, 27 Apr 2014 07:20:15 -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 BC8421A0268 for ; Sun, 27 Apr 2014 07:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23161; q=dns/txt; s=iport; t=1398608414; x=1399818014; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=4Qu3I1qoJkM+Qfp02gh4hDauCNFhV6oIU7q1SxpxtP8=; b=XjgkViIGOHyE7aadoBLrI4thzGmSeczmkY8N0M4qL+FPuA5q71WzK/F4 7kLbWG5w6rcigxMbN6r/pwCWPvO+7rDXuBCoKeEXSDUct02RHPEClncm0 F+H0HRJ+M2TN5OtIUSF9FMEAauDWR45QDtK8X3+Ot3CCO6+nkwEuoYwVS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAHARXVOtJV2b/2dsb2JhbABZgkJET1e7YYFCAYc4gQgWdIIlAQEBBAwhPh4CAQgRBAEBCxYHBzIUCQgBAQQTCAGIOA3JBheJN4RRAQEeNwGCLnaBFQSaRpEkgXKBP4FyOQ X-IronPort-AV: E=Sophos;i="4.97,937,1389744000"; d="scan'208,217";a="320715705" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 27 Apr 2014 14:20:11 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3REKCHr025856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 27 Apr 2014 14:20:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Sun, 27 Apr 2014 09:20:12 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 Thread-Index: Ac9WV3oMvXR98LDOSrigT2xIptRMWwJ1JqCw Date: Sun, 27 Apr 2014 14:20:11 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFF89F7@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AFDEE1D@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFDEE1D@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.131] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AFF89F7xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Kzga_ENglkHVrvtF2chJPiItAxY Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 14:20:18 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AFF89F7xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (This are individual comments, with my co-chair hat off.) In addition to the comments by Hidetoshi Yokota, which were very thorough, = and those from Sheng, I have the following: In Section 3, "SSID differentiates from one network to the other" is oddly = worded ... perhaps "SSID differentiates one network from another."? It woul= d also be good to have a hyphen or something separate the term from the def= inition? In section 4 (Hidetoshi comment on this as well), what does the "if added b= y relay/client" mean? And for Option 82, this this would not be an option b= ut a sub-option. code: 8-bit code carrying Access Network Identifier sub-options, If added by relay agent: Relay Agent Information Option (82) If added by client: OPTION_ACCESS_NETWORK_ID (TBD1) The DHCPv4 option vs the DHCPv4 Relay Agent Suboption should be completely = separate numbers (the number space is managed separately). So, you will nee= d to request a v4 OPTION_ACCESS_NETWORK_ID and a v4 Relay agent suboption (= from the "DHCP Relay Agent Sub-Option Codes" table), perhaps calling it "Ac= cess Network ID Suboption". The suboption contained with the v4 option and = v4 relay agent sub-options can have the same number space. I think this was raised in the discussion, but is allowing a client to spec= ify this information really a good idea? Having the relay supply this is fi= ne and much more 'secure'. Also, I don't see any text in the security considerations section (11) that= raises issues about the trustworthiness of the client's information. There= 's a lot about rogue relays, but that is much more complex than the client = just sending fake data. I think both the section 9 and 11 need text to reco= mmend against using the client's information or considering it untrustworth= y and thus used with care, if you continue to believe it worth allowing the= client to include it. In section 6.3, the reference to DNS wire encoding/RFC 1035 should be chang= ed to refer to RFC 3315, Section 8. This keeps definitions of what encoding= to use for Domain Names centralized and clarifies that the compressed from= is not to be used. In section 8, that a relay may overwrite these values is a bit odd and non-= standard. Also as the original values aren't recoverable when the server re= sponds (since the giaddr isn't overwritten the response will go back to the= first relay). I don't believe we have any RFCs for multi-relays for v4, wh= y would we want to 'partially' support this here for these options? I would= remove this paragraph - if there is a future specification to support this= , that would be what should be used. Section 9, "If DHCP server is unable to understand these options it MUST be= ignored". It should be they? Also, this seems an odd statement as existing= servers are supposed to do this anyway, and putting a requirement on exist= ing servers doesn't make any sense (as they can't be changed). I think you = should just drop this sentence. Minor issues: - "For e.g." is rather odd. Replace in Introduction with "For exam= ple". "E.g." means "for example". - Also in introduction and Terminology sections, "Dynamic Host Con= figuration Protocol v4" (and also v6 case) should use "Dynamic Host Configu= ration Protocol for IPv4". - Description misspelling in several places was already pointed ou= t. - "indicating that its a Access-Network-Type sub-option" ... I thi= nk you want "it's" (as in it is). Perhaps best to use "it is". This occurs = in a few other places. - There are a few formatting issues (missing spaces after end of s= entences, odd wrapping of text - no apparently good reasons for words to be= on next line instead of one same line, and apparently odd page breaks). - There's also a lot of minor wording issues. The RFC-Editor would handle fix the above, but nice to provide IESG and oth= ers a better doc to start with. Another revision of this document will be needed. In general, once the WGLC issues are addressed, this document should be abl= e to advance based on the option definitions, etc. (they adhere to the opti= on guidelines). It is difficult for me to evaluate whether these options an= d related server processing are needed and how widely they would be impleme= nted once available. The techniques a server uses for detecting 'where' a c= lient has connected have worked fine to date, so why and how this additiona= l information might be required is unclear to me. This mostly means section= 2, Motivation, isn't that 'strong' to me, but I'm also not an expert on pr= oxy mobile IPv6. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Saturday, April 12, 2014 10:04 AM To: dhcwg@ietf.org Subject: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - res= pond by April 27, 2014 Folks, the authors of draft-ietf-dhc-access-network-identifier (http://tool= s.ietf.org/html/draft-ietf-dhc-access-network-identifier-02) feel it's ready for work group last call. Please review this draft and indi= cate whether or not you feel it is ready to be published. At the time of this writing, there is no IPR reported against this draft. P= lease see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html = for a reminder regarding IPR disclosure requirements. Tomek and I will evaluate consensus after April 27, 2014. Thanks, Bernie & Tomek --_000_489D13FBFA9B3E41812EA89F188F018E1AFF89F7xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(This are individual c= omments, with my co-chair hat off.)

 

In addition to the com= ments by Hidetoshi Yokota, which were very thorough, and those from Sheng, = I have the following:

 

In Section 3, “S= SID differentiates from one network to the other” is oddly worded = 230; perhaps “SSID differentiates one network from another.”? I= t would also be good to have a hyphen or something separate the term from the definition?

 

In section 4 (Hidetosh= i comment on this as well), what does the “if added by relay/client&#= 8221; mean? And for Option 82, this this would not be an option but a sub-o= ption.

   code:=
 8-bit code carrying Access Network Identifier sub-options,
   =
      If added by relay agent: Relay Agent Informa=
tion Option (82)
   =
      If added by client: OPTION_ACCESS_NETWORK_ID=
 (TBD1)

The DHCPv4 option vs t= he DHCPv4 Relay Agent Suboption should be completely separate numbers (the = number space is managed separately). So, you will need to request a v4 OPTI= ON_ACCESS_NETWORK_ID and a v4 Relay agent suboption (from the “DHCP Relay Agent Sub-Option Codes” = table), perhaps calling it “Access Network ID Suboption”. The s= uboption contained with the v4 option and v4 relay agent sub-options can ha= ve the same number space.

 

I think this was raise= d in the discussion, but is allowing a client to specify this information r= eally a good idea? Having the relay supply this is fine and much more ̵= 6;secure’.

 

Also, I don’t se= e any text in the security considerations section (11) that raises issues a= bout the trustworthiness of the client’s information. There’s a= lot about rogue relays, but that is much more complex than the client just sending fake data. I think both the section 9 and 11 = need text to recommend against using the client’s information or cons= idering it untrustworthy and thus used with care, if you continue to believ= e it worth allowing the client to include it.

 

In section 6.3, the re= ference to DNS wire encoding/RFC 1035 should be changed to refer to RFC 331= 5, Section 8. This keeps definitions of what encoding to use for Domain Nam= es centralized and clarifies that the compressed from is not to be used.

 

In section 8, that a r= elay may overwrite these values is a bit odd and non-standard. Also as the = original values aren’t recoverable when the server responds (since th= e giaddr isn’t overwritten the response will go back to the first relay). I don’t believe we have any RFCs for mu= lti-relays for v4, why would we want to ‘partially’ support thi= s here for these options? I would remove this paragraph – if there is= a future specification to support this, that would be what should be used.

 

Section 9, “If D= HCP server is unable to understand these options it MUST be ignored”.= It should be they? Also, this seems an odd statement as existing servers a= re supposed to do this anyway, and putting a requirement on existing servers doesn’t make any sense (as they can’t be c= hanged). I think you should just drop this sentence.

 

Minor issues:

-&nb= sp;         “For e.g= .” is rather odd. Replace in Introduction with “For exampleR= 21;. “E.g.” means “for example”.<= /p>

-&nb= sp;         Also in introd= uction and Terminology sections, “Dynamic Host Configuration Protocol= v4” (and also v6 case) should use “Dynamic Host Configuration = Protocol for IPv4”.

-&nb= sp;         Description mi= sspelling in several places was already pointed out.

-&nb= sp;         “indicat= ing that its a Access-Network-Type sub-option” … I think you wa= nt “it’s” (as in it is). Perhaps best to use “it is= ”. This occurs in a few other places.

-&nb= sp;         There are a fe= w formatting issues (missing spaces after end of sentences, odd wrapping of= text – no apparently good reasons for words to be on next line inste= ad of one same line, and apparently odd page breaks).

-&nb= sp;         There’s = also a lot of minor wording issues.

The RFC-Editor would h= andle fix the above, but nice to provide IESG and others a better doc to st= art with.

 

 

Another revision of th= is document will be needed.

 

In general, once the W= GLC issues are addressed, this document should be able to advance based on = the option definitions, etc. (they adhere to the option guidelines). It is = difficult for me to evaluate whether these options and related server processing are needed and how widely they= would be implemented once available. The techniques a server uses for dete= cting ‘where’ a client has connected have worked fine to date, = so why and how this additional information might be required is unclear to me. This mostly means section 2, Motivation, isn= ’t that ‘strong’ to me, but I’m also not an expert = on proxy mobile IPv6.

 

-&nb= sp;         Bernie

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Saturday, April 12, 2014 10:04 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-0= 2 - respond by April 27, 2014

 

Folks, the authors of draft-ietf-dhc-access-netwo= rk-identifier (http://tools.ietf.org/html/draft-ietf-dhc-access-net= work-identifier-02)

feel it's ready for work group last call. Please = review this draft and indicate whether or not you feel it is ready to be pu= blished.

 

At the time of this writing, there is no IPR repo= rted against this draft. Please see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html for = a reminder regarding IPR disclosure requirements.

 

Tomek and I will evaluate consensus after April 2= 7, 2014.

 

Thanks,

Bernie & Tomek

 

--_000_489D13FBFA9B3E41812EA89F188F018E1AFF89F7xmbrcdx04ciscoc_-- From nobody Sun Apr 27 18:03:27 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3F31A0827 for ; Sun, 27 Apr 2014 18:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjkAS5ugreKq for ; Sun, 27 Apr 2014 18:03:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 940811A0825 for ; Sun, 27 Apr 2014 18:03:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGD34117; Mon, 28 Apr 2014 01:03:21 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Apr 2014 02:02:28 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Apr 2014 02:03:20 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.47]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 28 Apr 2014 09:03:14 +0800 From: Xueli To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 Thread-Index: Ac9WV3oMvXR98LDOSrigT2xIptRMWwMJSkyQ Date: Mon, 28 Apr 2014 01:03:14 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448F8923C@nkgeml504-mbx.china.huawei.com> References: <489D13FBFA9B3E41812EA89F188F018E1AFDEE1D@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFDEE1D@xmb-rcd-x04.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B448F8923Cnkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/rdLMSyAQi4z-sHI4Dr4OU3Lphqk Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 01:03:25 -0000 --_000_01FE63842C181246BBE4CF183BD159B448F8923Cnkgeml504mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all I believe this draft is well written. I support the WGLC. Regards Li From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Saturday, April 12, 2014 10:04 PM To: dhcwg@ietf.org Subject: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - res= pond by April 27, 2014 Folks, the authors of draft-ietf-dhc-access-network-identifier (http://tool= s.ietf.org/html/draft-ietf-dhc-access-network-identifier-02) feel it's ready for work group last call. Please review this draft and indi= cate whether or not you feel it is ready to be published. At the time of this writing, there is no IPR reported against this draft. P= lease see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html = for a reminder regarding IPR disclosure requirements. Tomek and I will evaluate consensus after April 27, 2014. Thanks, Bernie & Tomek --_000_01FE63842C181246BBE4CF183BD159B448F8923Cnkgeml504mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all

 

I believe this draft is well written. I support the WGLC.

 

Regards

Li

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Saturday, April 12, 2014 10:04 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-0= 2 - respond by April 27, 2014

 

Folks, the authors of draft-= ietf-dhc-access-network-identifier (http://tools.ietf.org/html/draf= t-ietf-dhc-access-network-identifier-02)

feel it's ready for work gro= up last call. Please review this draft and indicate whether or not you feel= it is ready to be published.

 

At the time of this writing,= there is no IPR reported against this draft. Please see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html for = a reminder regarding IPR disclosure requirements.

 

Tomek and I will evaluate co= nsensus after April 27, 2014.

 

Thanks,

Bernie & Tomek

 

--_000_01FE63842C181246BBE4CF183BD159B448F8923Cnkgeml504mbxchi_-- From nobody Sun Apr 27 20:30:11 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5041A085F for ; Sun, 27 Apr 2014 20:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWuyIX3ZG9C3 for ; Sun, 27 Apr 2014 20:30:08 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 41B3F1A085E for ; Sun, 27 Apr 2014 20:30:08 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ij19so7374609vcb.38 for ; Sun, 27 Apr 2014 20:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dyBbPjqKvcUwRmCaVnbTOLwoiqnKm92yzqkRPmKMYMw=; b=OgrYALaXVekYvw5l3DQU/9eHpdgIiMSbfefHJeyA5PeCR7+8wDHWOykHy4IwejkDHS 1oVqK/DYLuJpZAKX9GP6J+/N72hJj/bZIOX/wzQvfrOp6Cg2ZGYJHwV8mJzM4J1l2miW oHD+jLZJdtMicgolCHlEEI05opaUyljZft/TcSaJflSUagpeo3YeKhI5oMnp5EzM03jc XfautmPznzALMY8ceFb7d2eDumc4X0oMMcfd/aWkiGcMUF4ZNourtXywutndqUXgvXGq Y1QXR3Lt6Xw4xFZs7f4EqBv54wETV39/3oUnmSKJeUlUFwHcc6zqvr5E5W9lXgPPkzVS Em6w== MIME-Version: 1.0 X-Received: by 10.220.250.203 with SMTP id mp11mr21218685vcb.2.1398655807517; Sun, 27 Apr 2014 20:30:07 -0700 (PDT) Received: by 10.220.88.204 with HTTP; Sun, 27 Apr 2014 20:30:07 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFDEE1D@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1AFDEE1D@xmb-rcd-x04.cisco.com> Date: Mon, 28 Apr 2014 11:30:07 +0800 Message-ID: From: Liu Dapeng To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=089e013d050291f89404f811ee29 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/a659KNbZsbnIChDXB9p78yxgS50 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 03:30:10 -0000 --089e013d050291f89404f811ee29 Content-Type: text/plain; charset=ISO-8859-1 Hello all, I have read the draft and in general I think it is ready for WGLC. One comment in section 6.1: should the access technology type include cellular network? Thanks, Dapeng Liu 2014-04-12 22:04 GMT+08:00 Bernie Volz (volz) : > Folks, the authors of draft-ietf-dhc-access-network-identifier ( > http://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-02) > > feel it's ready for work group last call. Please review this draft and > indicate whether or not you feel it is ready to be published. > > > > At the time of this writing, there is no IPR reported against this draft. > Please see > http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html for a > reminder regarding IPR disclosure requirements. > > > > Tomek and I will evaluate consensus after April 27, 2014. > > > > Thanks, > > Bernie & Tomek > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > -- ------ Best Regards, Dapeng Liu --089e013d050291f89404f811ee29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all,

I have read the draft and in= general I think it is ready for WGLC.

One comment= in section 6.1: should the access technology type include cellular network= ?


Thanks,
Dapeng Liu=A0


2014-04-12= 22:04 GMT+08:00 Bernie Volz (volz) <volz@cisco.com>:

Folks, the authors of draft-ietf-dhc-access-network-identifier (http://tools.ietf.org/html/draft-ietf-dhc-access-network= -identifier-02)

feel it's ready for work group last call. Please review this draft a= nd indicate whether or not you feel it is ready to be published.<= /u>

=A0

At the time of this writing, there is no IPR reported against this draft= . Please see http://www.ietf.org/mail-archive/web/dhcwg/current/msg1= 4143.html for a reminder regarding IPR disclosure requirements.<= u>

=A0

Tomek and I will evaluate consensus after April 27, 2014.<= /p>

=A0

Thanks,

Bernie & Tomek

=A0


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




--

----= --
Best Regards,
Dapeng Liu
--089e013d050291f89404f811ee29-- From nobody Mon Apr 28 07:13:01 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8696E1A09FC for ; Mon, 28 Apr 2014 07:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MYaHna_h75r for ; Mon, 28 Apr 2014 07:12:55 -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 108B51A015E for ; Mon, 28 Apr 2014 07:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24944; q=dns/txt; s=iport; t=1398694374; x=1399903974; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=6Os0ObjT7Juo/XjINwdEwgLA4TEn47l64vq2YhIoAT8=; b=jLWUAV3guyKCTOC3pJUmv0SDJqNs8LGGd440IOvpQVqjlU1EUnoX+8G6 5EQDrLNMdLlkY9zoU2zIt46CheOb7aFEahJFJzwvXyhGMMsHFNyQuMzae XsvYgEpRVxb4TeAVDKIbfuYB/QCVoFqTLVxnJ14FvRnxCIyrBcRlHVNUb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FABlhXlOtJA2F/2dsb2JhbABZgkJET1e7a4h7gRUWdIIlAQEBBAwhPg4SAQgRAwEBASEHORQJCAIEAQ0FCYg4Dcl4F4k3hFEBAT4RBgGEOQSZDIE6kSSBcoE/gXI5 X-IronPort-AV: E=Sophos;i="4.97,944,1389744000"; d="scan'208,217";a="320913466" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 28 Apr 2014 14:12:54 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s3SECrrr021165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 14:12:53 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.55]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 09:12:53 -0500 From: "Sri Gundavelli (sgundave)" To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 Thread-Index: AQHPYuvx/xo8arOYukmidvZzRfG8zw== Date: Mon, 28 Apr 2014 14:12:52 +0000 Message-ID: In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AFF89F7@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.68.182] Content-Type: multipart/alternative; boundary="_000_CF83AFB813480Csgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/xhxU465hdlHPvpvOhSy8CPJ1Oro Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 14:12:58 -0000 --_000_CF83AFB813480Csgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bernie/All, Thanks for all the reviews. We will work on a revision to address all the c= omments. Regards Sri From: "Bernie Volz (volz)" > Date: Sunday, April 27, 2014 7:20 AM To: "dhcwg@ietf.org" > Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 -= respond by April 27, 2014 (This are individual comments, with my co-chair hat off.) In addition to the comments by Hidetoshi Yokota, which were very thorough, = and those from Sheng, I have the following: In Section 3, =93SSID differentiates from one network to the other=94 is od= dly worded =85 perhaps =93SSID differentiates one network from another.=94?= It would also be good to have a hyphen or something separate the term from= the definition? In section 4 (Hidetoshi comment on this as well), what does the =93if added= by relay/client=94 mean? And for Option 82, this this would not be an opti= on but a sub-option. code: 8-bit code carrying Access Network Identifier sub-options, If added by relay agent: Relay Agent Information Option (82) If added by client: OPTION_ACCESS_NETWORK_ID (TBD1) The DHCPv4 option vs the DHCPv4 Relay Agent Suboption should be completely = separate numbers (the number space is managed separately). So, you will nee= d to request a v4 OPTION_ACCESS_NETWORK_ID and a v4 Relay agent suboption (= from the =93DHCP Relay Agent Sub-Option Codes=94 table), perhaps calling it= =93Access Network ID Suboption=94. The suboption contained with the v4 opt= ion and v4 relay agent sub-options can have the same number space. I think this was raised in the discussion, but is allowing a client to spec= ify this information really a good idea? Having the relay supply this is fi= ne and much more =91secure=92. Also, I don=92t see any text in the security considerations section (11) th= at raises issues about the trustworthiness of the client=92s information. T= here=92s a lot about rogue relays, but that is much more complex than the c= lient just sending fake data. I think both the section 9 and 11 need text t= o recommend against using the client=92s information or considering it untr= ustworthy and thus used with care, if you continue to believe it worth allo= wing the client to include it. In section 6.3, the reference to DNS wire encoding/RFC 1035 should be chang= ed to refer to RFC 3315, Section 8. This keeps definitions of what encoding= to use for Domain Names centralized and clarifies that the compressed from= is not to be used. In section 8, that a relay may overwrite these values is a bit odd and non-= standard. Also as the original values aren=92t recoverable when the server = responds (since the giaddr isn=92t overwritten the response will go back to= the first relay). I don=92t believe we have any RFCs for multi-relays for = v4, why would we want to =91partially=92 support this here for these option= s? I would remove this paragraph =96 if there is a future specification to = support this, that would be what should be used. Section 9, =93If DHCP server is unable to understand these options it MUST = be ignored=94. It should be they? Also, this seems an odd statement as exis= ting servers are supposed to do this anyway, and putting a requirement on e= xisting servers doesn=92t make any sense (as they can=92t be changed). I th= ink you should just drop this sentence. Minor issues: - =93For e.g.=94 is rather odd. Replace in Introduction with =93Fo= r example=94. =93E.g.=94 means =93for example=94. - Also in introduction and Terminology sections, =93Dynamic Host C= onfiguration Protocol v4=94 (and also v6 case) should use =93Dynamic Host C= onfiguration Protocol for IPv4=94. - Description misspelling in several places was already pointed ou= t. - =93indicating that its a Access-Network-Type sub-option=94 =85 I= think you want =93it=92s=94 (as in it is). Perhaps best to use =93it is=94= . This occurs in a few other places. - There are a few formatting issues (missing spaces after end of s= entences, odd wrapping of text =96 no apparently good reasons for words to = be on next line instead of one same line, and apparently odd page breaks). - There=92s also a lot of minor wording issues. The RFC-Editor would handle fix the above, but nice to provide IESG and oth= ers a better doc to start with. Another revision of this document will be needed. In general, once the WGLC issues are addressed, this document should be abl= e to advance based on the option definitions, etc. (they adhere to the opti= on guidelines). It is difficult for me to evaluate whether these options an= d related server processing are needed and how widely they would be impleme= nted once available. The techniques a server uses for detecting =91where=92= a client has connected have worked fine to date, so why and how this addit= ional information might be required is unclear to me. This mostly means sec= tion 2, Motivation, isn=92t that =91strong=92 to me, but I=92m also not an = expert on proxy mobile IPv6. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Saturday, April 12, 2014 10:04 AM To: dhcwg@ietf.org Subject: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - res= pond by April 27, 2014 Folks, the authors of draft-ietf-dhc-access-network-identifier (http://tool= s.ietf.org/html/draft-ietf-dhc-access-network-identifier-02) feel it's ready for work group last call. Please review this draft and indi= cate whether or not you feel it is ready to be published. At the time of this writing, there is no IPR reported against this draft. P= lease see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html = for a reminder regarding IPR disclosure requirements. Tomek and I will evaluate consensus after April 27, 2014. Thanks, Bernie & Tomek --_000_CF83AFB813480Csgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Bernie/All,

Thanks for all the reviews. We will work on a revision to address all = the comments. 

Regards
Sri


From: "Bernie Volz (volz)"= ; <volz@cisco.com>
Date: Sunday, April 27, 2014 7:20 A= M
To: "dhcwg@ietf.org" <dhc= wg@ietf.org>
Subject: Re: [dhcwg] WGLC for draft= -ietf-dhc-access-network-identifier-02 - respond by April 27, 2014

(This are individual c= omments, with my co-chair hat off.)

 

In addition to the com= ments by Hidetoshi Yokota, which were very thorough, and those from Sheng, = I have the following:

 

In Section 3, =93SSID = differentiates from one network to the other=94 is oddly worded =85 perhaps= =93SSID differentiates one network from another.=94? It would also be good= to have a hyphen or something separate the term from the definition?

 

In section 4 (Hidetosh= i comment on this as well), what does the =93if added by relay/client=94 me= an? And for Option 82, this this would not be an option but a sub-option.

   code: 8-bit =
code carrying Access Network Identifier sub-options,

    &=
nbsp;    If added by relay agent: Relay Agent Information Op=
tion (82)


    &=
nbsp;    If added by client: OPTION_ACCESS_NETWORK_ID (TBD1)=



The DHCPv4 option vs t=
he DHCPv4 Relay Agent Suboption should be completely separate numbers (the =
number space is managed separately). So, you will need to request a v4 OPTI=
ON_ACCESS_NETWORK_ID and a v4 Relay
 agent suboption (from the =93DHCP Relay Agent Sub-Option Codes=94 table), =
perhaps calling it =93Access Network ID Suboption=94. The suboption contain=
ed with the v4 option and v4 relay agent sub-options can have the same numb=
er space.


 


I think this was raise=
d in the discussion, but is allowing a client to specify this information r=
eally a good idea? Having the relay supply this is fine and much more =91se=
cure=92.


 


Also, I don=92t see an=
y text in the security considerations section (11) that raises issues about=
 the trustworthiness of the client=92s information. There=92s a lot about r=
ogue relays, but that is much more complex
 than the client just sending fake data. I think both the section 9 and 11 =
need text to recommend against using the client=92s information or consider=
ing it untrustworthy and thus used with care, if you continue to believe it=
 worth allowing the client to include
 it.


 


In section 6.3, the re=
ference to DNS wire encoding/RFC 1035 should be changed to refer to RFC 331=
5, Section 8. This keeps definitions of what encoding to use for Domain Nam=
es centralized and clarifies that the
 compressed from is not to be used.


 


In section 8, that a r=
elay may overwrite these values is a bit odd and non-standard. Also as the =
original values aren=92t recoverable when the server responds (since the gi=
addr isn=92t overwritten the response will
 go back to the first relay). I don=92t believe we have any RFCs for multi-=
relays for v4, why would we want to =91partially=92 support this here for t=
hese options? I would remove this paragraph =96 if there is a future specif=
ication to support this, that would be what
 should be used.


 


Section 9, =93If DHCP =
server is unable to understand these options it MUST be ignored=94. It shou=
ld be they? Also, this seems an odd statement as existing servers are suppo=
sed to do this anyway, and putting a requirement
 on existing servers doesn=92t make any sense (as they can=92t be changed).=
 I think you should just drop this sentence.


 


Minor issues:


-=93For e.g=
.=94 is rather odd. Replace in Introduction with =93For example=94. =93E.g.=
=94 means =93for example=94.


-Also in in=
troduction and Terminology sections, =93Dynamic Host Configuration Protocol=
 v4=94 (and also v6 case) should use =93Dynamic Host Configuration Protocol=
 for IPv4=94.


-Descriptio=
n misspelling in several places was already pointed out.<=
/p>

-=93indicat=
ing that its a Access-Network-Type sub-option=94 =85 I think you want =93it=
=92s=94 (as in it is). Perhaps best to use =93it is=94. This occurs in a fe=
w other places.


-There are =
a few formatting issues (missing spaces after end of sentences, odd wrappin=
g of text =96 no apparently good reasons for words to be on next line inste=
ad of one same line, and apparently
 odd page breaks).


-There=92s =
also a lot of minor wording issues.


The RFC-Editor would h=
andle fix the above, but nice to provide IESG and others a better doc to st=
art with.


 


 


Another revision of th=
is document will be needed.


 


In general, once the W=
GLC issues are addressed, this document should be able to advance based on =
the option definitions, etc. (they adhere to the option guidelines). It is =
difficult for me to evaluate whether
 these options and related server processing are needed and how widely they=
 would be implemented once available. The techniques a server uses for dete=
cting =91where=92 a client has connected have worked fine to date, so why a=
nd how this additional information might
 be required is unclear to me. This mostly means section 2, Motivation, isn=
=92t that =91strong=92 to me, but I=92m also not an expert on proxy mobile =
IPv6.


 


-Bernie


 






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

Sent: Saturday, April 12, 2014 10:04 AM

To: dhcwg@ietf.org

Subject: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-0=
2 - respond by April 27, 2014






 


Folks, the authors of draft-ietf-dhc-access-netwo=
rk-identifier (http://tools.ietf.org/html/draft-ietf-dhc-access-net=
work-identifier-02)


feel it's ready for work group last call. Please =
review this draft and indicate whether or not you feel it is ready to be pu=
blished.


 


At the time of this writing, there is no IPR repo=
rted against this draft. Please see
http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html for =
a reminder regarding IPR disclosure requirements.


 


Tomek and I will evaluate consensus after April 2=
7, 2014.


 


Thanks,


Bernie & Tomek


 
--_000_CF83AFB813480Csgundaveciscocom_-- From nobody Tue Apr 29 11:21:56 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC821A0962 for ; Tue, 29 Apr 2014 11:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QfV4afS-0TM for ; Tue, 29 Apr 2014 11:21:40 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 64E581A0963 for ; Tue, 29 Apr 2014 11:21:40 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id d17so603004eek.15 for ; Tue, 29 Apr 2014 11:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=0f58YQZUMG2Ye1Uyli5qRBgw5tIMmmbj0B/fXRZIrUk=; b=Nmr9vd44UFigQtmtyJrFMYCBznnR7umXhYFhLEHbBeLtJEmclWR2EtF1jwyDklSk/0 OkcoPlihmvvaFBW1p4nUN+o34JuFjslMDAZgIWo5UbAoFiSqs0ch9e0E3U3sQNZiHcWz 0RQC5RxCShpAPSuWd8jI6l8ESGJfFwFl6fKe1y6cYjLRAGzMDmfExERsQoBK9aUdxpDS AvAzpNkTOf8eGx37r4azvBIsLNDU+p15W+LhpjWUL9wfrbE8IYb7+R1eJU/mOI/n7f2F 221mVw3POm9dGuSAQ9YxvVwrXl00wwwPe6+VM2OvymEogqxtEz07xmlpAKgK84W+/KY7 VwBw== X-Received: by 10.14.241.139 with SMTP id g11mr759837eer.49.1398795698631; Tue, 29 Apr 2014 11:21:38 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id 4sm61168392eeq.33.2014.04.29.11.21.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 11:21:37 -0700 (PDT) Message-ID: <535FEDAD.5010103@gmail.com> Date: Tue, 29 Apr 2014 20:21:33 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dhcwg X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/YurBVgILs6UEirHIZxAnnbJzGSc Subject: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 18:21:45 -0000 Hi all, This message starts DHC working group last call about advancing Secure DHCPv6 with Public Key document as a Standards Track RFC. The authors believe that this version addressed all the issues raised and is ready. The draft is available here: http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02 Since we have upcoming holiday on May 1st (which happens to be a reason for extended weekend in many parts of Europe) and the topic in question is not trivial, this WGLC is a bit longer than usual. Please send your comments by May 18th 2014. If you do not feel this document should advance, please state your reasons why. There are no IPR claims reported at this time. Tomek Mrugalski is the document shepherd. Bernie & Tomek From nobody Wed Apr 30 10:29:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347041A0922 for ; Wed, 30 Apr 2014 10:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU4YqqTwGIH0 for ; Wed, 30 Apr 2014 10:29:50 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id E0B121A0910 for ; Wed, 30 Apr 2014 10:29:49 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so1988606wes.38 for ; Wed, 30 Apr 2014 10:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=m9M0DNlhsO774WIIGK/c6cuS0GxoIWFAE7lm2yiHsPU=; b=h1ywXd/r6HkF7H3nBOKudNFTpAG29PWI8RPiKv5GfbjZxVg7mvXRIp2AaL3yp89Bg+ VUgmhQo7TZ88ygNQwxdqDuNpO+gaM7Z1Bex35UzC9O2MPJ6oekdHYcpP+U1yL0FYjk7l h/LxrTEVHovX83y9hP9gPUrIilw5juKqt4nDQ1KKNSlJghtVYkziE4/XZoVEWwMcCGMV a6pZUps7xlGmEFMbszDXcJ7+QIv7Ej39O1ZwPCboEnueultrYPOX5/66l9FbxEjNb3/G We1GLc0xs2OHOfU5B2Sz687bdJE3i4jMnP6GJ2tsis+GcrTtm7jqE8o69MVPQyT5bO0I v9Yg== MIME-Version: 1.0 X-Received: by 10.194.58.79 with SMTP id o15mr3542876wjq.62.1398878987845; Wed, 30 Apr 2014 10:29:47 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.3.14 with HTTP; Wed, 30 Apr 2014 10:29:47 -0700 (PDT) In-Reply-To: <535FEDAD.5010103@gmail.com> References: <535FEDAD.5010103@gmail.com> Date: Wed, 30 Apr 2014 10:29:47 -0700 X-Google-Sender-Auth: U-Y34UC_ZZqb3aSQ3PBsoU0onPc Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Tomek Mrugalski Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/UIYcI0IGh-MPcAZ7m-8LNPfbyJ4 Cc: dhcwg Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 17:29:51 -0000 At Tue, 29 Apr 2014 20:21:33 +0200, Tomek Mrugalski wrote: > Since we have upcoming holiday on May 1st (which happens to be a reason > for extended weekend in many parts of Europe) and the topic in question > is not trivial, this WGLC is a bit longer than usual. > > Please send your comments by May 18th 2014. If you do not feel this > document should advance, please state your reasons why. I've read the document. I don't have a particular opinion on whether it should advance, mainly because I'm not a security expert. I have some comments that may hopefully be useful, though: Some higher level points - (maybe already discussed before but) the concept of using public key authentication in DHCP makes some sense to me, but I wonder why we are discussing this specifically for DHCPv6. As far as I know there's no such counterpart in DHCPv4 (the only related thing I can google is draft-gupta-dhcp-auth-02.txt, which expired long ago), am I correct? If so, is that because *v4 is just too legacy and isn't worth improvements anymore? Or does that reflect some DHCP specific points that make public key authentication not so viable? If it's the latter, doesn't it also apply to this proposal? - The description of the draft is a bit vague (which may have to be clarified anyway), but if I understand it correctly, it assumes that both clients (each of them) and servers maintain their pair of public-private keys, and a client offers and uses its own key to authenticate messages from the client to servers. Is that correct? If so, does this make sense? My general understanding is that authenticating DHCP messages from clients to server is not that critical, and it's quite unlikely that servers maintain public keys of all possible clients so the servers would have to rely on the leap-of-faith model. They then may have to worry about the "resource exhaustion attacks" (although I'm not sure if this is a big issue, see below). Other non editorial comments on the draft: - Section 5.1: Public Key A variable-length field containing public key. The key MUST be represented as a lower-case hexadecimal string with the most significant octet of the key first. Typically, the length of a 2048-bit RSA Is there any specific reason it's represented as a string? Not necessarily bad, but I thought more common practice here is to simply use the binary value of the key. DHCP options in wire format are not expected to be human readable anyway, so I don't see the point for using a string here. - In Section 6.2: On the recipient that supports the leap of faith model, the number of cached public keys or unverifiable certificates MUST be limited in order to protect against resource exhaustion attacks. If the This is mainly concerned about servers, correct? If so, I'm not sure how severe this "attacks" are; DHCP servers generally need to maintain some state for each client (unless that's stateless only server) and would naturally already have some limitation on that resource. Shouldn't the general defense be enough for this particular resource, too? (But I was also not sure if it makes sense to use (public key) authentication for messages from clients in the first place; see higher-level discussions above) - Related, it seems some part of Section 6.2 is more specific for clients and some other part is more specific to servers. So it may be helpful if we have separate subsections focusing on these particular cases. Just a suggestion. Editorial nits: - Section 4.3 they may fall back the unsecure model, if both client and server s/fall back the/fall back to the/ (I found the missing 'to' of this kind in several other places in the draft) - Section 4.3 whether to accept the messages. If the client accept the unsecure messages from the DHCPv6 server. The subsequent exchanges will be in unsecure model. s/server. The/server, the/ - Section 4.3 on the server policy. If the server mandidates the authentication, s/mandidates/mandates/ - Section 6.1 messages, MUST contain either a the Public Key or Certificate option, s/a the/the/ (?) - Section 6.2 error status code, defined in Section 5.4, back to the client.. s/.././ -- JINMEI, Tatuya