From nobody Wed Feb 1 05:11:20 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA3E1298D9; Wed, 1 Feb 2017 05:11:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148595467496.24521.17172788517014344817.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 05:11:14 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-fsc-softwire-dhcp4o6-saddr-opt-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 13:11: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 of the IETF. Title : DHCPv4 over DHCPv6 Source Address Option Authors : Ian Farrer Qi Sun Yong Cui Linhui Sun Filename : draft-fsc-softwire-dhcp4o6-saddr-opt-07.txt Pages : 9 Date : 2017-02-01 Abstract: DHCPv4 over DHCPv6 [RFC7341] describes a mechanism for dynamically configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the operator must learn the /128 IPv6 address that the client will use as the source of IPv4-in-IPv6 tunnel. This address, in conjunction with the IPv4 address and the Port Set ID allocated to the DHCP 4o6 client are used to create a binding table entry in the softwire tunnel concentrator. This memo defines two DHCPv6 options used to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It also describes a method for configuring the client with the IPv6 address of the border router so that the softwire can be established. It is designed to work in conjunction with the IPv4 address allocation process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fsc-softwire-dhcp4o6-saddr-opt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-fsc-softwire-dhcp4o6-saddr-opt-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 Wed Feb 1 07:51:16 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BF0129496; Wed, 1 Feb 2017 07:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YEJjS67jh5vu; Wed, 1 Feb 2017 07:51:05 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2A5129407; Wed, 1 Feb 2017 07:51:04 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id 73so293203012otj.0; Wed, 01 Feb 2017 07:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b3G7OGOneZnM3JvRhU4ENwTcuf/euk03EKHPNxlHN7U=; b=p6Oti7Kbsmc+bh4VUgysRNPIcq5k2LqaqiHkCqf7CJYw6whtX8S1t/z2SlB1y/sq49 8UB4xDuHU/VQDLdIMHBKlyZNu46KXnEkrw9UKMk3yqloBuwGWdYlKDb8WkOIcGmKzqcP t8rcS1QIERDQtw/KNri6XGQJ8MCI4jxiAErFXNE8WCilQT1PzgTcY08d/6VVZcaMClMC HhDJTcBmsQo2DGUaqd6V46Qtr7HyWxnqo7NyOzzhAoSf+uAciVD6WW+DZxRuUW+MopeK FWTdlEN4FAICjl9B1G2/UbB5STiOIgjvq79Q6YaEDYpYFymF7Z41iiguYu5NFa93EnWw yhwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b3G7OGOneZnM3JvRhU4ENwTcuf/euk03EKHPNxlHN7U=; b=R3uDflmKRmcn0cArYtnx56uu8jp7nzgYATfvX3bnF3gwbFk29diYPkfJsMFPg0MSlq ND/3QdOcMXdrIAGwq/ToteP2lmz4zMp6U03JrHrChmdwd6MTRCk4pDCE2XnsY2KvdrTF YHb4MyimI/Iqy+cEFsTzy98yrRt1gHCdSLP88pJgY9eGkd0q4BA6uVYbYzJFskD9F1hI +ChnYm4gj6+NyPSQfnndJvGaZiyDP92dN96xNGlYz1bAgBO/9x9a+tBzqEvXGuUtCPiA Z3hyUY/xFMxk39C+PNu2pBVip2X00m3bbtQILUZgyzZABFYjR+A8IhjZmHc3tlgDwltN YFYQ== X-Gm-Message-State: AMke39n9+0zkIMLt2GPq5KJAJQqzwOMPpeJOkQcEsGYPHQUlqx9V1jBinSqoR5W0TbCD61zkjv+xKR/FdB19Ew== X-Received: by 10.157.52.253 with SMTP id t58mr1784906otd.161.1485964264194; Wed, 01 Feb 2017 07:51:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.1.202 with HTTP; Wed, 1 Feb 2017 07:50:23 -0800 (PST) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD770018@DGGEMM506-MBX.china.huawei.com> References: <148568056700.24536.11691583944564362484.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD770018@DGGEMM506-MBX.china.huawei.com> From: tianxiang li Date: Wed, 1 Feb 2017 23:50:23 +0800 Message-ID: To: Roni Even Content-Type: multipart/alternative; boundary=001a1140a4621dc8a505477a049b Archived-At: Cc: dhcwg , "gen-art@ietf.org" , Roni Even , "ietf@ietf.org" , "draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@ietf.org" Subject: Re: [dhcwg] [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 15:51:07 -0000 --001a1140a4621dc8a505477a049b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Roni, Thank you for the response, please see inline. Cheers, Tianxiang 2017-02-01 15:02 GMT+08:00 Roni Even : > Hi, > > See inline > > Roni > > > > *From:* Gen-art [mailto:gen-art-bounces@ietf.org] *On Behalf Of *tianxian= g > li > *Sent:* =D7=99=D7=95=D7=9D =D7=92 31 =D7=99=D7=A0=D7=95=D7=90=D7=A8 2017 = 17:59 > *To:* Roni Even > *Cc:* dhcwg; gen-art@ietf.org; ietf@ietf.org; > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@ietf.org > *Subject:* Re: [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-l > ength-hint-issue-05 > > > > Dear Roni, > > > > Thank you for providing a thorough review of this document. > > > > I have a few questions regarding the comments, please see inline. > > > > Best regards, > > Tianxiang > > > > 2017-01-29 17:02 GMT+08:00 Roni Even : > > Reviewer: Roni Even > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 > Reviewer: Roni Even > Review Date: 2017-01-29 > IETF LC End Date: 2017-02-09 > IESG Telechat date: 2017-02-16 > > Summary: This draft is almost ready for publication as a standard > track RFC. > > > Major issues: > > Minor issues: > > 1. I think that this document updates RFC3633 and it should be > mentioned in the title and abstract > > > > [Tianxiang] This document does not change any of the text in RFC 3633, bu= t > specifies the client and server behavior when using the "prefix-length > hint", which was not explained in RFC3633. Would it be suitable to state > "this document updates RFC3633"? > > *[Roni Even] Yes, this is what I meant and it needs to be written in the > title and abstract, it will also point people looking at RFC3633 to this > document* > > > [Tianxiang2] Okay, we could add a sentence in the end of the abstract saying "This document updates RFC3633". For the title, we followed a similar name with RFC7550 which updated RFC3315 and RFC3633. It was titled "Issues and Recommendations with Multiple Stateful DHCPv6 Options". Do you have some recommendations on how to change the document title? > 2. In section 3.1 reference RFC3315 for solicit message and 3.3 for > advertise messge > > > > [Tianxiang] Okay, we'll add reference to RFC3315 in section 3.1 and 3.3 > when mentioning Solicit and Advertise messgae. > > *[Roni Even] OK* > > > > 3. In section 3.1 solution last paragraph is the order of the two > IAPREFIX options important? > > > > [Tianxiang] There is no strict requirement for the order of the two > options. Would you prefer if we added a sentence to specify this? > > *[Roni Even] I assumed this was the case but it will better to clarify* > > > > 4. In section 3.2 solution why are you suing SHOULD and not MUST in > all recommendations? > > > > [Tianxiang] In this document, we used "MUST" for some of the client > behaviors, as they are mandatory to avoid client failure and necessary if > the client wanted to express its prefix-length requirement. > > > > For server behavior, we used "SHOULD" because this document specifies the > desired server behavior if the server wants to consider the prefix-length > hint, but the server could have its own behavioral policy (e.g. neglect t= he > prefix-length hint). > > *[Roni Even] This make sense, but it will be good to clarify why it is a > SHOULD using your explanation* > > > > 5. In section 3.2 solution, what should the server do if cannot > provide any of the requests > > > > [Tianxiang] If the server could not provide the requested prefix or > prefix-length, it should provide a prefix closest to the prefix-length > hint, as stated in the last sentence of section 3.2. > > > > Are you referring to what the sever should do of it simply could not > provide ANY prefixes to the client? In that case, we could add a sentence > at the end of the section 3.2: > > > > "If the server will not assign any prefixes to any IA_PDs in a subsequent > Request from the client, the server MUST send an Advertise message to the > client as described in section 11.2 of RFC 3633." > > *[Roni Even] This sentence is what I was looking for.* > > > > 6. In section 3.2 solution last paragraph =E2=80=9CSHOULD try to pro= vide=E2=80=9D and > in the first paragraph =E2=80=9CSHOULD provide=E2=80=9D should be the sam= e in both. > > > > [Tianxiang] Thanks for pointing that out, we'll change it to "SHOULD > provide". > > > > *[Roni Even] OK* > > > > 7. In section 3.4 =E2=80=9CIf the client decided to use the prefix = provided > by the server despite being longer than the prefix-length hint=E2=80=9D = yet I > did not see in section 3.2 that the server can provide a longer > prefix. > > > > [Tianxiang] This was mentioned in the last sentence of section 3.2: > > > > "If the requested prefix is not available in the server's prefix pool, an= d > the client also included a prefix-length hint in the same IA_PD option, > then the server SHOULD try to provide a prefix matching the prefix-length > value, or the prefix with the shortest length possible which is closest t= o > the prefix-length hint value." > > *[Roni Even] I understood from 3.2 that it should provide a shorter lengt= h > prefix closer to the request maybe =E2=80=9C*or the prefix with the clos= est > possible length to the prefix-length hint value=E2=80=9D > > > [Tianxiang2] The original sentence was a bit confusing, perhaps we could change it like this: OLD: "If the requested prefix is not available in the server's prefix pool, and the client also included a prefix-length hint in the same IA_PD option, then the server SHOULD try to provide a prefix matching the prefix-length value, or the prefix with the shortest length possible which is closest to the prefix-length hint value." NEW:"If the requested prefix is not available in the server's prefix pool, and the client also included a prefix-length hint in the same IA_PD option, then the server SHOULD provide a prefix matching the prefix-length hint, or a prefix which is length is shorter and as close as possible to the prefix-length hint. If the server could not provide a prefix which length is shorter or equal to the prefix-length hint, the server SHOULD provide the prefix which length is longer and as close as possible to the prefix-length hint." 8. In section 3.5 solution the document use =E2=80=9Cas close as possi= ble=E2=80=9D and > section 3.2 only talk about smaller. > > > > [Tianxiang] This was mentioned in the last sentence of section 3.2. > > *[Roni Even] See above to point 7* > > > > 9. In section 3.5 solution why offer options 3 and 4. The draft > says that option 3 will break client connections and 4 talks about =E2=80= =9Ca > short non-zero valid-lifetime=E2=80=9D which may cause the client to los= e > connection if "too short for the client" since =E2=80=9Cshort=E2=80=9D is= not an exact > value > > > > [Tianxiang] The idea was to list all the options, and discuss their > consequences. And the server could decide which option to use depending o= n > its policy. > > > > Option 3 avoids the complexity of handling multiple delegated prefixes, > despite of breaking up all connections. Option 4 allows to server to > configure a valid-lifetime for the old prefix depending on actual > requirements, rather than let the old prefix expire on its own. > > *[Roni Even] OK, still option 4 may have similar result to 3 since =E2=80= =9Ca > short non-zero=E2=80=9D may be too short. Why not add a recommended value= ?* > > > [Tianxiang2] Agree, as this may vary for different services, we could change the text to say "a specific valid-lifetime depending on the actual requirement". > > > > Nits/editorial comments: > > > > --001a1140a4621dc8a505477a049b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Roni,

Thank you for the response, pl= ease see inline.

Cheers,
Tianxiang
=

2017-02-01 15:02 = GMT+08:00 Roni Even <roni.even@huawei.com>:

Hi,

See inline

Roni

=C2=A0

From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of tianxiang li
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=92 3= 1 =D7=99=D7=A0=D7=95=D7=90=D7=A8 2017 17:59
To: Roni Even
Cc: dhcwg; gen= -art@ietf.org; ietf@= ietf.org; draft-ietf-dhc-dhcpv6-prefix-lengt= h-hint-issue.all@ietf.org
Subject: Re: [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-l= ength-hint-issue-05

=C2=A0

Dear Roni,

=C2=A0

Thank you for providing a thorough review of this do= cument.

=C2=A0

I have a few questions regarding the comments, pleas= e see inline.

=C2=A0

Best regards,

Tianxiang

=C2=A0

2017-01-29 17:02 GMT+08:00 Roni Even <roni.even@mail01.huaw= ei.com>:

Reviewer: Roni Even
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05
Reviewer: Roni Even
Review Date: 2017-01-29
IETF LC End Date: 2017-02-09
IESG Telechat date: 2017-02-16

Summary: This draft is almost ready for publication as a standard
track RFC.


Major issues:

Minor issues:

1.=C2=A0 =C2=A0 =C2=A0 I think that this document updates RFC3633 and it sh= ould be
mentioned in the title and abstract

=C2=A0

[Tianxiang] This document does not change any of the= text in RFC 3633, but specifies the client and server behavior when using = the "prefix-length hint", which was not explained in RFC3633. Wou= ld it be suitable to state "this document updates RFC3633"?

[Roni Even] Yes, this is w= hat I meant and it needs to be written in=C2=A0 the title and abstract, it = will also point people looking at RFC3633 to this document

=C2=A0

[Tianxiang2] Okay, we could add a sentence in the = end of the abstract saying "This document updates RFC3633".
=

For the title, we followed a similar name with RFC7550 = which updated RFC3315 and RFC3633. It was titled "Issues and Recommend= ations with Multiple Stateful DHCPv6 Options". Do you have some recomm= endations on how to change the document title?

2.=C2=A0 =C2=A0 =C2=A0 In section 3.1 reference RFC3= 315 for solicit message and 3.3 for
advertise messge=C2=A0

=C2=A0

[Tianxiang] Okay, we'll add reference to RFC3315= in section 3.1 and 3.3 when mentioning Solicit and Advertise messgae.

[Roni Even] OK

=C2=A0=C2=A0

3.=C2=A0 =C2=A0 =C2=A0 In section 3.1 solution last = paragraph is the order of the two
IAPREFIX options important?

=C2=A0

[Tianxiang] There is no strict requirement for the o= rder of the two options. Would you prefer if we added a sentence to specify= this?

[Roni Even] I assumed this was = the case but it will better to clarify=

=C2=A0

4.=C2=A0 =C2=A0 =C2=A0 In section 3.2 solution why a= re you suing SHOULD and not MUST in
all recommendations?

=C2=A0

[Tianxiang] In this document, we used "MUST&quo= t; for some of the client behaviors, as they are mandatory to avoid client = failure and necessary if the client wanted to express its prefix-length req= uirement.=C2=A0

=C2=A0

For server behavior, we used "SHOULD" beca= use this document specifies the desired server behavior if the server wants= to consider the prefix-length hint, but the server could have its own beha= vioral policy (e.g. neglect the prefix-length hint).

[Roni Even] This make sense, bu= t it will be good to clarify why it is a SHOULD using your explanation

=C2=A0

5.=C2=A0 =C2=A0 =C2=A0 In section 3.2 solution, what= should the server do if cannot
provide any of the requests

=C2=A0

[Tianxiang] If the server could not provide the requ= ested prefix or prefix-length, it should provide a prefix closest to the pr= efix-length hint, as stated in the last sentence of section 3.2.<= /u>

=C2=A0

Are you referring to what the sever should do of it = simply could not provide ANY prefixes to the client? In that case, we could= add a sentence at the end of the section 3.2:

=C2=A0

"If the server will not assign any prefixes to = any IA_PDs in a subsequent Request from the client, the server MUST send an= Advertise message to the client as described in section 11.2 of RFC 3633.&= quot;

[Roni Even] This sentence is wh= at I was looking for.

=C2=A0

6.=C2=A0 =C2=A0 =C2=A0 In section 3.2 solution last = paragraph =E2=80=9CSHOULD try to provide=E2=80=9D and
in the first paragraph =E2=80=9CSHOULD provide=E2=80=9D should be the same = in both.

=C2=A0

[Tianxiang] Thanks for pointing that out, we'll = change it to "SHOULD provide".

=C2=A0

[Roni Even] OK

=C2=A0

7.=C2=A0 =C2=A0 =C2=A0 In section 3.4 =E2=80=9CIf th= e client decided to use=C2=A0 the prefix provided
by the server despite being longer than the=C2=A0 prefix-length hint=E2=80= =9D yet I
did not see in section 3.2 that the server can provide a longer
prefix.

=C2=A0

[Tianxiang] This was mentioned in the last sentence = of section 3.2:=C2=A0

=C2=A0

"If the requested prefix is not available in th= e server's prefix pool, and the client also included a prefix-length hi= nt in the same IA_PD option, then the server SHOULD try to provide a prefix= matching the prefix-length value, or the prefix with the shortest length possible which is closest to the prefix-length hi= nt value."

[Roni Even] I understood from 3= .2 that it should provide a shorter length prefix =C2=A0closer to the reque= st maybe =E2=80=9Cor the prefix with the closest possible length to the prefix-length hint value=E2=80=9D=

=C2=A0

[Tianxiang2] The original sentence was a bit confu= sing, perhaps we could change it like this:

OLD:= =C2=A0"If the requested prefix is not available in the server's pr= efix pool, and the client also included a prefix-length hint in the same IA= _PD option, then the server SHOULD try to provide a prefix matching the pre= fix-length value, or the prefix with the shortest length possible which is = closest to the prefix-length hint value."

NEW= :"If the requested prefix is not available in the server's prefix = pool, and the client also included a prefix-length hint in the same IA_PD o= ption, then the server SHOULD provide a prefix matching the prefix-length h= int, or a prefix which is length is shorter and as close as possible to the= prefix-length hint. If the server could not provide a prefix which length = is shorter or equal to the prefix-length hint, the server SHOULD provide th= e prefix which length is longer and as close as possible to the prefix-leng= th hint."

<= u>

8.=C2=A0 =C2=A0 =C2=A0 In section 3.5 solution the d= ocument use =E2=80=9Cas close as possible=E2=80=9D and
section 3.2 only talk about smaller.

=C2=A0

[Tianxiang] This was mentioned in the last sentence = of section 3.2.=C2=A0

[Roni Even] See above to point = 7

=C2=A0

9.=C2=A0 =C2=A0 =C2=A0In section 3.5 solution why of= fer options 3 and 4. The draft
says that option 3 will break client connections and 4 talks about =E2=80= =9Ca
short non-zero valid-lifetime=E2=80=9D which may cause the=C2=A0 client to = lose
connection if "too short for the client" since =E2=80=9Cshort=E2= =80=9D is not an exact
value=C2=A0

=C2=A0

[Tianxiang] The idea was to list all the options, an= d discuss their consequences. And the server could decide which option to u= se depending on its policy.=C2=A0

=C2=A0

Option 3 avoids the complexity of handling multiple = delegated prefixes, despite of breaking up all connections. Option 4 allows= to server to configure a valid-lifetime for the old prefix depending on ac= tual requirements, rather than let the old prefix expire on its own.<= /u>

[Roni Even] OK, still option 4 = may have similar result to 3 since =E2=80=9Ca short non-zero=E2=80=9D may b= e too short. Why not add a recommended value?<= /p>

=C2=A0

=
[Tianxiang2] Agree, as this may vary for different servic= es, we could change the text to say "a specific valid-lifetime dependi= ng on the actual requirement".=C2=A0

<= div>

=C2=A0



Nits/editorial comments:


=C2=A0


--001a1140a4621dc8a505477a049b-- From nobody Wed Feb 1 08:28:34 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796CE1294D6; Wed, 1 Feb 2017 08:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 suIAsJFdaFnU; Wed, 1 Feb 2017 08:28:30 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6458A1294D2; Wed, 1 Feb 2017 08:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7689; q=dns/txt; s=iport; t=1485966510; x=1487176110; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1qw18UclONluZrxyGd4pptRfJr63C5hOGxMJKyF7Rd8=; b=JIFb0Tf7z9EpeCj5qr54lfR/eB2OWnD15hzjeXBGoaD1RoSMbaI7i8G2 Dvgrr7GSFWGnUsafO4rUGGnVrR+MMmwt4EdM+IfmNJmDGBB2E0zrHUm7q mPiaJOA/mLeiHcfLbtM2wwkhzqy37Lf2GsU83SbZWaGFuVPvo2CXGdyvu o=; X-IronPort-AV: E=Sophos;i="5.33,320,1477958400"; d="scan'208";a="203286801" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Feb 2017 16:28:29 +0000 Received: from bxb-kkinnear-8814.cisco.com (bxb-kkinnear-8814.cisco.com [10.98.10.245]) (authenticated bits=0) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v11GSShD014637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2017 16:28:28 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: kkinnear In-Reply-To: <148590541849.5999.8358163403846302600.idtracker@ietfa.amsl.com> Date: Wed, 1 Feb 2017 11:28:27 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <148590541849.5999.8358163403846302600.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) X-Authenticated-User: kkinnear@cisco.com Archived-At: Cc: Bernie Volz , dhc-chairs@ietf.org, The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 16:28:32 -0000 Ben, Thanks for the review. My comments are indented below. > On Jan 31, 2017, at 6:30 PM, Ben Campbell wrote: > > Ben Campbell has entered the following ballot position for > draft-ietf-dhc-dhcpv6-failover-protocol-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I think the security considerations need some elaboration. The draft says > "When operating in secure mode...", but it doesn't discuss when one might > want to run in secure more vs non-secure mode. It would be helpful to > discuss actual threats. You mention TCP DoS attacks, but, for example, > can an eavesdropper learn sensitive or private information? Is there a > risk of someone impersonating a partner? Tampering with messages on the > network? > > There's a mention of using TLS certs for authentication/authorization, > but I think there's more to be said there. Is there any authentication or > authorization if you aren't using secure mode? How do you match a TLS > certificate to the partner name? > > The section opens saying that the security considerations from 3315 and > 3633 apply, but I doubt either of those contemplated that you would be > sending DHCP messages over TCP connections between partner servers. While I could try to answer your questions directly, it seemed like offering an augmented Security Considerations section might be more useful. This takes into account both your comments and Kathleen Moriarty's comments as well: DHCPv6 failover is an extension of a standard DHCPv6 protocol, so all security considerations from [RFC3315], Section 23 and [RFC3633], Section 15 related to the server apply. The use of TCP introduces some additional concerns. Attacks that attempt to exhaust the DHCP server's available TCP connection resources can compromise the ability of legitimate partners to receive service. Malicious requestors who succeed in establishing connections but who then send invalid messages, partial messages, or no messages at all can also exhaust a server's pool of available connections. DHCPv6 failover can operate in secure or insecure mode. Secure mode (using TLS) would be indicated when the TCP connection between failover partners is open to external monitoring or interception. Insecure mode should only be used when the TCP connection between failover partners remains within set of protected systems. Details of such protections are beyond the scope of this document. The threats created by using failover directly mirror those from using DHCPv6 itself: information leakage through monitoring, and disruption of address assignment and configuration. Monitoring the failover TCP connection provides no additional data beyond that available from monitoring the interactions between DHCPv6 clients and the DHCPv6 server. Likewise, manipulating the data flow between failover servers provides no additional opportunities to disrupt address assignment and configuration beyond that provided by acting as a counterfeit DHCP server. Protection from both threats is easier than with basic DHCPv6, as only a single TCP connection needs to be protected. Either use secure mode to protect that TCP connection or ensure that it can only exist with a set of protected systems. When operating in secure mode, TLS [RFC5246] is used to secure the connection. The recommendations in [RFC7525] SHOULD be followed when negotiating a TLS connection. Servers SHOULD offer configuration parameters to limit the sources of incoming connections through validation and use of the digital certificates presented to create a TLS connection. They SHOULD also limit the number of accepted connections and limit the period of time during which an idle connection will be left open. Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to attempt to secure transmission of the messages described in this document. If authentication is desired, secure mode using TLS SHOULD be employed as described in Sections 8.2 and 9.1 of [RFC7653] > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - 6.1.3: I'm confused by the procedure for checking > OPTION_F_PROTOCOL_VERSION in the CONNECTREPLY message. The secondary > already checked that it supported the version in the CONNECT message; why > does the primary need to check it again? Is it expected that the > secondary might choose to send a different version in the CONNECTREPLY > than it received in CONNECT? Is it possible that the partners use > different protocol versions at the same time? > > The intent here is that each server tells the other server what protocol version that it will be sending, and also has the opportunity to accept or reject the version that that other server is sending. As noted in Section 5.5.14, there is a major/minor component to the protocol version. Each server is expected to have a range of acceptable major (and, possibly, minor) versions on reception. So, each server gets to see what the other server will be sending and accept or reject the connection based on that information. The secondary accepts or rejects that primary's version, and the primary gets to do the same with the secondary. So, yes, they might send different versions to each other. Future revisions of this document will define interoperability requirements when new versions are created, the details can't be known at this point. We just want to create a way to at least communicate the information from the outset. I will add this Section 6.1.1 (for the primary sending CONNECT): o OPTION_F_PROTOCOL_VERSION containing the protocol version that the primary server will use when sending failover messages. and this to Section 6.1.2 (for the secondary sending CONNECTREPLY): o OPTION_F_PROTOCOL_VERSION containing the protocol version being used by the secondary server when sending failover messages. and this to Section 6.1.3 (primary receiving the CONNECTREPLY): o OPTION_F_PROTOCOL_VERSION - The primary server decides if the protocol version in use by the secondary server is supported by the primary server. If it is not, send a DISCONNECT message and drop the connection. If it is supported, continue processing. It is possible that the primary and secondary server will each be sending different version of the protocol to the other server. The extent to which this is supported will be in part defined by as yet unknown differences in the protocols that the versions represent, and in part by the capabilities of the two implementations involved in the failover relationship. Again, thanks for the review. Kim From nobody Wed Feb 1 11:57:02 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBE1129571; Wed, 1 Feb 2017 11:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 F_p1qcLQ2-GD; Wed, 1 Feb 2017 11:56:57 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C419912955A; Wed, 1 Feb 2017 11:56:57 -0800 (PST) X-AuditID: c618062d-ab7ff70000007359-5e-589244c511cf Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id 0D.66.29529.5C442985; Wed, 1 Feb 2017 21:27:52 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0319.002; Wed, 1 Feb 2017 14:56:54 -0500 From: Suresh Krishnan To: Jouni Korhonen Thread-Topic: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02 Thread-Index: AQHSd5+97/nhpHQdmkuMjdpvr7SJ/6FK4VKAgAA2QQCAAFA2gIAAAySAgAAGBQCAAAf2AIABoSWAgAaNEwA= Date: Wed, 1 Feb 2017 19:56:53 +0000 Message-ID: References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> In-Reply-To: <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_E5981C9E-17BD-4CC2-92BD-FF0A454608A6"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUyuXRPrO4Jl0kRBj9nilrc7WhhtHg1YRe7 xaMr3SwW+9c1MFm8fhJq8WbNESaL/dcWMFksn6HpwOEx5fdGVo+mC8vYPXbOusvusWTJT6YA ligum5TUnMyy1CJ9uwSujIYXc1gL9tpUHF5Z2MA4w6KLkZNDQsBE4sX8XexdjFwcQgLrGSUm bT0D5SxjlNh17iYLSBUbUNWGnZ+Zuhg5OEQEtCWWbxADqWEWOMck0dh1nQmkRlggSOLeqnls ILaIQLDE0b+9zBB2ksSpBRvAbBYBFYktL3eD1fMK2EvMX3mVDWLZTmaJpVfOgi3gFLCVWH7c FaSGUUBM4vupNWD1zALiEreezGeCuFpE4uHF02wQtqjEy8f/WCFsJYmPv+ezQxw3hVHi965v bBDLBCVOznzCMoFRZBaSWbOQ1c1CUgdRpC2xbOFrZghbU2J/93KouKnE66MfGSFsa4kZvw6y QdiKElO6H7IvYORYxchRWlyQk5tuZLCJERilxyTYdHcw3p/ueYhRgINRiYfXwGBShBBrYllx Ze4hRhWg1kcbVl9glGLJy89LVRLhZbAESvOmJFZWpRblxxeV5qQWH2KU5mBREueNW30/XEgg PbEkNTs1tSC1CCbLxMEp1cB41JOx3uS8uumN9+5flnPIqLfnpuoIyRX4th86+tdm7fK9/RJ5 n9h078931a8Iy3w5e5r4j1VFRoyHHj015A09r8vet6LmkWXT9NXvikIcFr6YstBzedIewf4p vVqtZpLTa3aWNagsEZhfkF0o9/5K6oaHut7T23X3zZok8yrhU9ze2IBQxVAlluKMREMt5qLi RADH2XTN2gIAAA== Archived-At: Cc: Bernie Volz , "int-dir@ietf.org" , Ted Lemon , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" Subject: Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 19:56:59 -0000 --Apple-Mail=_E5981C9E-17BD-4CC2-92BD-FF0A454608A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jouni, Thanks for the review.=20 > On Jan 27, 2017, at 3:20 PM, jouni.nospam = wrote: >=20 >=20 >> On Jan 26, 2017, at 11:27 AM, Ted Lemon wrote: >>=20 >> On Jan 26, 2017, at 1:58 PM, jouni.nospam = wrote: >>> No. But in this case there are pieces of text that change specific = places in the original document from SHOULDs to MUSTs, musts to MUSTs, = and adds few pieces of new stuff, etc. Now how that in not updating? = Changes or =E2=80=9Cextensions=E2=80=9D like that would be nice to = follow from the base document. >>=20 >> Okay, I see your point. But suppose the document were changed so = that rather than "updating" the document as you suggest, it simply = referenced the sections in question and then made the SHOULDs into MUSTs = that way? Wouldn't that mean "implementations of this extension MUST," = and wouldn't that be perfectly reasonable? >>=20 >=20 > I would still argue that it updates specifically if the document here = is going to be standards track. If this document here would be more of a = recommendation e.g., BCP I would be fine without the =E2=80=9Cupdating=E2=80= =9D part (as I remember the MUST for IPsec in RFC3315bis was not = endorsed by the WG). I think the other two items in your review need to be fixed. But I have = a slightly different take on this specific issue. In my view this = document needs to stay on Standards track, and it should be made clear = that it is an (optional) extension to RFC3315. This allows people who = have implemented encryption for server-relay communications to claim = compliance to RFC3315 and this document. For RFC3315bis, I think it = should be discussed in the WG whether to mandate encryption or not as = there are backward compatibility related considerations to be made. Regards Suresh --Apple-Mail=_E5981C9E-17BD-4CC2-92BD-FF0A454608A6 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjAxMDAyMjMzWjAjBgkqhkiG9w0B CQQxFgQUAdhhuVZvj010o7GP8yVhW3IyIhkwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQADYrXLysVevX68p8bZsrs+8MhSRuZU69OzWy/NcdoTWXql7JMDCnv7Sue+GZhG k+c01c3cSvOaDsRyvLEyfspQb0q8DA9IMY4wzG2g/E6w1ElxnUXkGLdd+ypM0eEE5B00Sn5DxXLw rmBb9FhSPH6Qqk2hKs/RjsgtcHyPxHzAEGlTkRB0UPQrjWKAjUD/g/RiQjpCRllLYJM4fr8xnfh2 Gu5YJu4VeGFVTix7GuyYGrmEmsiIAUUAv353qkQYLjEqpkYn42ni4znrk5EbVac1apJ54ttGbgTX 60U3qUHCg4GD3N0SCSnjG2+QP4SehdgEh2e36VW/53z0lpbnjaV5AAAAAAAA --Apple-Mail=_E5981C9E-17BD-4CC2-92BD-FF0A454608A6-- From nobody Wed Feb 1 17:33:48 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F062129588; Wed, 1 Feb 2017 17:33:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148599922705.18700.14648245113952484559.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 17:33:47 -0800 Archived-At: Cc: dhc-chairs@ietf.org, volz@cisco.com, draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org Subject: [dhcwg] Stephen Farrell's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 01:33:47 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-dhc-dhcpv6-failover-protocol-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I support Ben's discuss about "secure mode" - a few more details are needed, in particular how a pair decide to use/not-use TLS - are there different ports or a STARTTLS equivalent - I can't see that defined here. (Is it inherited from RFC7653? If so, maybe you need to say?) - For the DNS update stuff - is there no need to use TSIG secrets? If there is, how is that sync'd between the pair of DHCP servers? If it is sync'd then don't you need to say that TLS is a MUST for such connections? If there is no support for TSIG, is that likely to work? From nobody Wed Feb 1 18:27:16 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EC1129620; Wed, 1 Feb 2017 18:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 pd2vC1R9B9bg; Wed, 1 Feb 2017 18:27:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F255F12948F; Wed, 1 Feb 2017 18:27:07 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v122R3Ex010520 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 1 Feb 2017 20:27:04 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: kkinnear Date: Wed, 01 Feb 2017 20:27:03 -0600 Message-ID: <3F50B6FB-FE8B-4308-9220-B88F9D79B6B1@nostrum.com> In-Reply-To: References: <148590541849.5999.8358163403846302600.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: dhc-chairs@ietf.org, dhcwg@ietf.org, Bernie Volz , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, The IESG Subject: Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with DISCUSS and COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 02:27:12 -0000 Hi, thanks for the response. Please see inline: Thanks! Ben. On 1 Feb 2017, at 10:28, kkinnear wrote: [...] >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I think the security considerations need some elaboration. The draft >> says >> "When operating in secure mode...", but it doesn't discuss when one >> might >> want to run in secure more vs non-secure mode. It would be helpful to >> discuss actual threats. You mention TCP DoS attacks, but, for >> example, >> can an eavesdropper learn sensitive or private information? Is there >> a >> risk of someone impersonating a partner? Tampering with messages on >> the >> network? >> >> There's a mention of using TLS certs for >> authentication/authorization, >> but I think there's more to be said there. Is there any >> authentication or >> authorization if you aren't using secure mode? How do you match a TLS >> certificate to the partner name? >> >> The section opens saying that the security considerations from 3315 >> and >> 3633 apply, but I doubt either of those contemplated that you would >> be >> sending DHCP messages over TCP connections between partner servers. > > While I could try to answer your questions directly, it seemed like > offering an augmented Security Considerations section might be more > useful. This takes into account both your comments and Kathleen > Moriarty's comments as well: > > > DHCPv6 failover is an extension of a standard DHCPv6 protocol, so > all security considerations from [RFC3315], Section 23 and > [RFC3633], Section 15 related to the server apply. > > The use of TCP introduces some additional concerns. Attacks that > attempt to exhaust the DHCP server's available TCP connection > resources can compromise the ability of legitimate partners to > receive service. Malicious requestors who succeed in establishing > connections but who then send invalid messages, partial messages, > or no messages at all can also exhaust a server's pool of available > connections. > > DHCPv6 failover can operate in secure or insecure mode. Secure > mode (using TLS) would be indicated when the TCP connection between > failover partners is open to external monitoring or interception. > Insecure mode should only be used when the TCP connection between > failover partners remains within set of protected systems. Details > of such protections are beyond the scope of this document. > > The threats created by using failover directly mirror those from > using DHCPv6 itself: information leakage through monitoring, and > disruption of address assignment and configuration. Monitoring the > failover TCP connection provides no additional data beyond that > available from monitoring the interactions between DHCPv6 clients > and the DHCPv6 server. Likewise, manipulating the data flow > between failover servers provides no additional opportunities to > disrupt address assignment and configuration beyond that provided > by acting as a counterfeit DHCP server. Protection from both > threats is easier than with basic DHCPv6, as only a single TCP > connection needs to be protected. Either use secure mode to > protect that TCP connection or ensure that it can only exist with a > set of protected systems. > > When operating in secure mode, TLS [RFC5246] is used to secure the > connection. The recommendations in [RFC7525] SHOULD be followed > when negotiating a TLS connection. > > Servers SHOULD offer configuration parameters to limit the sources > of incoming connections through validation and use of the digital > certificates presented to create a TLS connection. They SHOULD > also limit the number of accepted connections and limit the period > of time during which an idle connection will be left open. > > Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to > attempt to secure transmission of the messages described in this > document. If authentication is desired, secure mode using TLS > SHOULD be employed as described in Sections 8.2 and 9.1 of > [RFC7653] Thanks, that's exactly the sort of thing I was looking for. I will clear my discussion with the assumption that text will go into the draft. > > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - 6.1.3: I'm confused by the procedure for checking >> OPTION_F_PROTOCOL_VERSION in the CONNECTREPLY message. The secondary >> already checked that it supported the version in the CONNECT message; >> why >> does the primary need to check it again? Is it expected that the >> secondary might choose to send a different version in the >> CONNECTREPLY >> than it received in CONNECT? Is it possible that the partners use >> different protocol versions at the same time? >> >> > > The intent here is that each server tells the other server what > protocol version that it will be sending, and also has the > opportunity to accept or reject the version that that other server > is sending. As noted in Section 5.5.14, there is a major/minor > component to the protocol version. Each server is expected to have > a range of acceptable major (and, possibly, minor) versions on > reception. So, each server gets to see what the other server will > be sending and accept or reject the connection based on that > information. The secondary accepts or rejects that primary's > version, and the primary gets to do the same with the secondary. > > So, yes, they might send different versions to each other. Future > revisions of this document will define interoperability requirements > when new versions are created, the details can't be known at this > point. We just want to create a way to at least communicate the > information from the outset. > > I will add this Section 6.1.1 (for the primary sending CONNECT): > > o OPTION_F_PROTOCOL_VERSION containing the protocol version > that the primary server will use when sending failover messages. > > and this to Section 6.1.2 (for the secondary sending CONNECTREPLY): > > o OPTION_F_PROTOCOL_VERSION containing the protocol version being > used by the secondary server when sending failover messages. > > and this to Section 6.1.3 (primary receiving the CONNECTREPLY): > > o OPTION_F_PROTOCOL_VERSION - The primary server decides if the > protocol version in use by the secondary server is supported by > the primary server. If it is not, send a DISCONNECT message and > drop the connection. If it is supported, continue processing. > It is possible that the primary and secondary server will each > be sending different version of the protocol to the other > server. The extent to which this is supported will be in part > defined by as yet unknown differences in the protocols that the > versions represent, and in part by the capabilities of the two > implementations involved in the failover relationship. > That helps, thanks! From nobody Wed Feb 1 18:28:26 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB19412948F; Wed, 1 Feb 2017 18:28:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148600250475.18668.1653423716274399775.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2017 18:28:24 -0800 Archived-At: Cc: dhc-chairs@ietf.org, volz@cisco.com, draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org Subject: [dhcwg] Ben Campbell's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 02:28:25 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dhc-dhcpv6-failover-protocol-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS comment. I am clearing now under the assumption the proposed text will make it into the draft. From nobody Wed Feb 1 22:42:33 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA3127735; Wed, 1 Feb 2017 22:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 82R8R46u_R0i; Wed, 1 Feb 2017 22:42:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E548127078; Wed, 1 Feb 2017 22:42:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFQ60273; Thu, 02 Feb 2017 06:42:20 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 2 Feb 2017 06:42:18 +0000 Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by nkgeml411-hub.china.huawei.com (10.98.56.70) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 2 Feb 2017 14:42:14 +0800 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Thu, 2 Feb 2017 14:42:10 +0800 From: Roni Even To: tianxiang li Thread-Topic: [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 Thread-Index: AQHSfKMEGC59Kqb/I0a0hf43svJnhaFVREvg Date: Thu, 2 Feb 2017 06:42:09 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD771622@DGGEMM506-MBX.china.huawei.com> References: <148568056700.24536.11691583944564362484.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD770018@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD771622DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5892D4CD.030D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c1ff7e23a5fb1d24d3ae21aa07c5b874 Archived-At: Cc: dhcwg , "gen-art@ietf.org" , Roni Even , "ietf@ietf.org" , "draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@ietf.org" Subject: Re: [dhcwg] [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 06:42:27 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD771622DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJIHdpbGwgbGVhdmUgb25seSB0aGUgaXRlbXMgdGhhdCBuZWVkZWQgbXkgcmVzcG9uc2UN Cg0KNy4gICAgICBJbiBzZWN0aW9uIDMuNCDigJxJZiB0aGUgY2xpZW50IGRlY2lkZWQgdG8gdXNl ICB0aGUgcHJlZml4IHByb3ZpZGVkDQpieSB0aGUgc2VydmVyIGRlc3BpdGUgYmVpbmcgbG9uZ2Vy IHRoYW4gdGhlICBwcmVmaXgtbGVuZ3RoIGhpbnTigJ0geWV0IEkNCmRpZCBub3Qgc2VlIGluIHNl Y3Rpb24gMy4yIHRoYXQgdGhlIHNlcnZlciBjYW4gcHJvdmlkZSBhIGxvbmdlcg0KcHJlZml4Lg0K DQpbVGlhbnhpYW5nXSBUaGlzIHdhcyBtZW50aW9uZWQgaW4gdGhlIGxhc3Qgc2VudGVuY2Ugb2Yg c2VjdGlvbiAzLjI6DQoNCiJJZiB0aGUgcmVxdWVzdGVkIHByZWZpeCBpcyBub3QgYXZhaWxhYmxl IGluIHRoZSBzZXJ2ZXIncyBwcmVmaXggcG9vbCwgYW5kIHRoZSBjbGllbnQgYWxzbyBpbmNsdWRl ZCBhIHByZWZpeC1sZW5ndGggaGludCBpbiB0aGUgc2FtZSBJQV9QRCBvcHRpb24sIHRoZW4gdGhl IHNlcnZlciBTSE9VTEQgdHJ5IHRvIHByb3ZpZGUgYSBwcmVmaXggbWF0Y2hpbmcgdGhlIHByZWZp eC1sZW5ndGggdmFsdWUsIG9yIHRoZSBwcmVmaXggd2l0aCB0aGUgc2hvcnRlc3QgbGVuZ3RoIHBv c3NpYmxlIHdoaWNoIGlzIGNsb3Nlc3QgdG8gdGhlIHByZWZpeC1sZW5ndGggaGludCB2YWx1ZS4i DQpbUm9uaSBFdmVuXSBJIHVuZGVyc3Rvb2QgZnJvbSAzLjIgdGhhdCBpdCBzaG91bGQgcHJvdmlk ZSBhIHNob3J0ZXIgbGVuZ3RoIHByZWZpeCAgY2xvc2VyIHRvIHRoZSByZXF1ZXN0IG1heWJlIOKA nG9yIHRoZSBwcmVmaXggd2l0aCB0aGUgY2xvc2VzdCBwb3NzaWJsZSBsZW5ndGggdG8gdGhlIHBy ZWZpeC1sZW5ndGggaGludCB2YWx1ZeKAnQ0KDQpbVGlhbnhpYW5nMl0gVGhlIG9yaWdpbmFsIHNl bnRlbmNlIHdhcyBhIGJpdCBjb25mdXNpbmcsIHBlcmhhcHMgd2UgY291bGQgY2hhbmdlIGl0IGxp a2UgdGhpczoNCg0KT0xEOiAiSWYgdGhlIHJlcXVlc3RlZCBwcmVmaXggaXMgbm90IGF2YWlsYWJs ZSBpbiB0aGUgc2VydmVyJ3MgcHJlZml4IHBvb2wsIGFuZCB0aGUgY2xpZW50IGFsc28gaW5jbHVk ZWQgYSBwcmVmaXgtbGVuZ3RoIGhpbnQgaW4gdGhlIHNhbWUgSUFfUEQgb3B0aW9uLCB0aGVuIHRo ZSBzZXJ2ZXIgU0hPVUxEIHRyeSB0byBwcm92aWRlIGEgcHJlZml4IG1hdGNoaW5nIHRoZSBwcmVm aXgtbGVuZ3RoIHZhbHVlLCBvciB0aGUgcHJlZml4IHdpdGggdGhlIHNob3J0ZXN0IGxlbmd0aCBw b3NzaWJsZSB3aGljaCBpcyBjbG9zZXN0IHRvIHRoZSBwcmVmaXgtbGVuZ3RoIGhpbnQgdmFsdWUu Ig0KDQpORVc6IklmIHRoZSByZXF1ZXN0ZWQgcHJlZml4IGlzIG5vdCBhdmFpbGFibGUgaW4gdGhl IHNlcnZlcidzIHByZWZpeCBwb29sLCBhbmQgdGhlIGNsaWVudCBhbHNvIGluY2x1ZGVkIGEgcHJl Zml4LWxlbmd0aCBoaW50IGluIHRoZSBzYW1lIElBX1BEIG9wdGlvbiwgdGhlbiB0aGUgc2VydmVy IFNIT1VMRCBwcm92aWRlIGEgcHJlZml4IG1hdGNoaW5nIHRoZSBwcmVmaXgtbGVuZ3RoIGhpbnQs IG9yIGEgcHJlZml4IHdoaWNoIGlzIGxlbmd0aCBpcyBzaG9ydGVyIGFuZCBhcyBjbG9zZSBhcyBw b3NzaWJsZSB0byB0aGUgcHJlZml4LWxlbmd0aCBoaW50LiBJZiB0aGUgc2VydmVyIGNvdWxkIG5v dCBwcm92aWRlIGEgcHJlZml4IHdoaWNoIGxlbmd0aCBpcyBzaG9ydGVyIG9yIGVxdWFsIHRvIHRo ZSBwcmVmaXgtbGVuZ3RoIGhpbnQsIHRoZSBzZXJ2ZXIgU0hPVUxEIHByb3ZpZGUgdGhlIHByZWZp eCB3aGljaCBsZW5ndGggaXMgbG9uZ2VyIGFuZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUg cHJlZml4LWxlbmd0aCBoaW50LiINCg0KW1JvbmkgRXZlbl0gSSBoYXZlIG5vIHByb2JsZW0gd2l0 aCB0aGlzIHRleHQgc2luY2UgaXQgd2lsbCBhbHNvIHdvcmsgd2l0aCB0aGUgcmVzdCBvZiB0aGUg ZG9jdW1lbnQgYnV0IGlzIGl0IHdoYXQgd2FzIHJlYWxseSBtZWFudA0KDQpBbHNvIGEgbml0DQoN CuKAnG9yIGEgcHJlZml4IHdoaWNoIGlzIGxlbmd0aCBpcyBzaG9ydGVyIGFuZCBhcyBjbG9zZSBh cyBwb3NzaWJsZSB0byB0aGUgcHJlZml4LWxlbmd0aCBoaW50LiBJZiB0aGUgc2VydmVyIGNvdWxk IG5vdCBwcm92aWRlIGEgcHJlZml4IHdoaWNoIGxlbmd0aCBpcyBzaG9ydGVyIG9yIGVxdWFsIHRv IHRoZSBwcmVmaXgtbGVuZ3RoIGhpbnQsIHRoZSBzZXJ2ZXIgU0hPVUxEIHByb3ZpZGUgdGhlIHBy ZWZpeCB3aGljaCBsZW5ndGggaXMgbG9uZ2VyIGFuZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0 aGUgcHJlZml4LWxlbmd0aCBoaW504oCdDQoNCnRvDQoNCuKAnG9yIGEgcHJlZml4IHdob3NlIGxl bmd0aCBpcyBzaG9ydGVyIGFuZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgcHJlZml4LWxl bmd0aCBoaW50LiBJZiB0aGUgc2VydmVyIGNvdWxkIG5vdCBwcm92aWRlIGEgcHJlZml4IHdpdGgg YSBzaG9ydGVyIG9yIGVxdWFsIGxlbmd0aCAgdG8gdGhlIHByZWZpeC1sZW5ndGggaGludCwgdGhl IHNlcnZlciBTSE9VTEQgcHJvdmlkZSBhIHByZWZpeCB3aG9zZSBsZW5ndGggaXMgbG9uZ2VyIGFu ZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgcHJlZml4LWxlbmd0aCBoaW504oCdDQoNCg0K W1RpYW54aWFuZ10gVGhlIGlkZWEgd2FzIHRvIGxpc3QgYWxsIHRoZSBvcHRpb25zLCBhbmQgZGlz Y3VzcyB0aGVpciBjb25zZXF1ZW5jZXMuIEFuZCB0aGUgc2VydmVyIGNvdWxkIGRlY2lkZSB3aGlj aCBvcHRpb24gdG8gdXNlIGRlcGVuZGluZyBvbiBpdHMgcG9saWN5Lg0KDQpPcHRpb24gMyBhdm9p ZHMgdGhlIGNvbXBsZXhpdHkgb2YgaGFuZGxpbmcgbXVsdGlwbGUgZGVsZWdhdGVkIHByZWZpeGVz LCBkZXNwaXRlIG9mIGJyZWFraW5nIHVwIGFsbCBjb25uZWN0aW9ucy4gT3B0aW9uIDQgYWxsb3dz IHRvIHNlcnZlciB0byBjb25maWd1cmUgYSB2YWxpZC1saWZldGltZSBmb3IgdGhlIG9sZCBwcmVm aXggZGVwZW5kaW5nIG9uIGFjdHVhbCByZXF1aXJlbWVudHMsIHJhdGhlciB0aGFuIGxldCB0aGUg b2xkIHByZWZpeCBleHBpcmUgb24gaXRzIG93bi4NCltSb25pIEV2ZW5dIE9LLCBzdGlsbCBvcHRp b24gNCBtYXkgaGF2ZSBzaW1pbGFyIHJlc3VsdCB0byAzIHNpbmNlIOKAnGEgc2hvcnQgbm9uLXpl cm/igJ0gbWF5IGJlIHRvbyBzaG9ydC4gV2h5IG5vdCBhZGQgYSByZWNvbW1lbmRlZCB2YWx1ZT8N Cg0KW1RpYW54aWFuZzJdIEFncmVlLCBhcyB0aGlzIG1heSB2YXJ5IGZvciBkaWZmZXJlbnQgc2Vy dmljZXMsIHdlIGNvdWxkIGNoYW5nZSB0aGUgdGV4dCB0byBzYXkgImEgc3BlY2lmaWMgdmFsaWQt bGlmZXRpbWUgZGVwZW5kaW5nIG9uIHRoZSBhY3R1YWwgcmVxdWlyZW1lbnQiLg0KW1JvbmkgRXZl bl0gT0sNCg0KDQoNCg0KTml0cy9lZGl0b3JpYWwgY29tbWVudHM6DQoNCg0KDQo= --_000_6E58094ECC8D8344914996DAD28F1CCD771622DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4ubS02MDYwNzI2OTc5NTM2MDAzMTE5Z21haWwtbS02NTI0ODAyMTEyMjA3 MDQ5MjQ2Z21haWwtDQoJe21zby1zdHlsZS1uYW1lOm1fLTYwNjA3MjY5Nzk1MzYwMDMxMTlnbWFp bC1tXy02NTI0ODAyMTEyMjA3MDQ5MjQ2Z21haWwtO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgd2lsbCBsZWF2ZSBvbmx5IHRoZSBpdGVtcyB0aGF0IG5lZWRlZCBteSBy ZXNwb25zZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj43LiZuYnNwOyAmbmJzcDsgJm5ic3A7IElu IHNlY3Rpb24gMy40IOKAnElmIHRoZSBjbGllbnQgZGVjaWRlZCB0byB1c2UmbmJzcDsgdGhlIHBy ZWZpeCBwcm92aWRlZDxicj4NCmJ5IHRoZSBzZXJ2ZXIgZGVzcGl0ZSBiZWluZyBsb25nZXIgdGhh biB0aGUmbmJzcDsgcHJlZml4LWxlbmd0aCBoaW504oCdIHlldCBJPGJyPg0KZGlkIG5vdCBzZWUg aW4gc2VjdGlvbiAzLjIgdGhhdCB0aGUgc2VydmVyIGNhbiBwcm92aWRlIGEgbG9uZ2VyPGJyPg0K cHJlZml4LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPltUaWFueGlhbmddIFRoaXMgd2FzIG1lbnRpb25lZCBpbiB0aGUgbGFz dCBzZW50ZW5jZSBvZiBzZWN0aW9uIDMuMjombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O0lmIHRoZSByZXF1ZXN0ZWQg cHJlZml4IGlzIG5vdCBhdmFpbGFibGUgaW4gdGhlIHNlcnZlcidzIHByZWZpeCBwb29sLCBhbmQg dGhlIGNsaWVudCBhbHNvIGluY2x1ZGVkIGEgcHJlZml4LWxlbmd0aCBoaW50IGluIHRoZSBzYW1l IElBX1BEIG9wdGlvbiwgdGhlbiB0aGUgc2VydmVyIFNIT1VMRCB0cnkgdG8NCiBwcm92aWRlIGEg cHJlZml4IG1hdGNoaW5nIHRoZSBwcmVmaXgtbGVuZ3RoIHZhbHVlLCBvciB0aGUgcHJlZml4IHdp dGggdGhlIHNob3J0ZXN0IGxlbmd0aCBwb3NzaWJsZSB3aGljaCBpcyBjbG9zZXN0IHRvIHRoZSBw cmVmaXgtbGVuZ3RoIGhpbnQgdmFsdWUuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5bUm9uaSBFdmVuXSBJIHVuZGVyc3Rvb2QgZnJvbSAzLjIgdGhhdCBpdCBzaG91bGQgcHJv dmlkZSBhIHNob3J0ZXIgbGVuZ3RoIHByZWZpeCAmbmJzcDtjbG9zZXIgdG8NCiB0aGUgcmVxdWVz dCBtYXliZSDigJw8L3NwYW4+PC9pPjwvYj5vciB0aGUgcHJlZml4IHdpdGggdGhlIGNsb3Nlc3Qg cG9zc2libGUgbGVuZ3RoIHRvIHRoZSBwcmVmaXgtbGVuZ3RoIGhpbnQgdmFsdWXigJ08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b VGlhbnhpYW5nMl0gVGhlIG9yaWdpbmFsIHNlbnRlbmNlIHdhcyBhIGJpdCBjb25mdXNpbmcsIHBl cmhhcHMgd2UgY291bGQgY2hhbmdlIGl0IGxpa2UgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0xEOiZuYnNwOyZxdW90O0lmIHRoZSBy ZXF1ZXN0ZWQgcHJlZml4IGlzIG5vdCBhdmFpbGFibGUgaW4gdGhlIHNlcnZlcidzIHByZWZpeCBw b29sLCBhbmQgdGhlIGNsaWVudCBhbHNvIGluY2x1ZGVkIGEgcHJlZml4LWxlbmd0aCBoaW50IGlu IHRoZSBzYW1lIElBX1BEIG9wdGlvbiwgdGhlbiB0aGUgc2VydmVyIFNIT1VMRCB0cnkgdG8gcHJv dmlkZSBhIHByZWZpeCBtYXRjaGluZyB0aGUgcHJlZml4LWxlbmd0aCB2YWx1ZSwgb3INCiB0aGUg cHJlZml4IHdpdGggdGhlIHNob3J0ZXN0IGxlbmd0aCBwb3NzaWJsZSB3aGljaCBpcyBjbG9zZXN0 IHRvIHRoZSBwcmVmaXgtbGVuZ3RoIGhpbnQgdmFsdWUuJnF1b3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5FVzomcXVvdDtJZiB0aGUgcmVx dWVzdGVkIHByZWZpeCBpcyBub3QgYXZhaWxhYmxlIGluIHRoZSBzZXJ2ZXIncyBwcmVmaXggcG9v bCwgYW5kIHRoZSBjbGllbnQgYWxzbyBpbmNsdWRlZCBhIHByZWZpeC1sZW5ndGggaGludCBpbiB0 aGUgc2FtZSBJQV9QRCBvcHRpb24sIHRoZW4gdGhlIHNlcnZlciBTSE9VTEQgcHJvdmlkZSBhIHBy ZWZpeCBtYXRjaGluZyB0aGUgcHJlZml4LWxlbmd0aCBoaW50LCBvciBhIHByZWZpeA0KIHdoaWNo IGlzIGxlbmd0aCBpcyBzaG9ydGVyIGFuZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgcHJl Zml4LWxlbmd0aCBoaW50LiBJZiB0aGUgc2VydmVyIGNvdWxkIG5vdCBwcm92aWRlIGEgcHJlZml4 IHdoaWNoIGxlbmd0aCBpcyBzaG9ydGVyIG9yIGVxdWFsIHRvIHRoZSBwcmVmaXgtbGVuZ3RoIGhp bnQsIHRoZSBzZXJ2ZXIgU0hPVUxEIHByb3ZpZGUgdGhlIHByZWZpeCB3aGljaCBsZW5ndGggaXMg bG9uZ2VyIGFuZCBhcyBjbG9zZSBhcw0KIHBvc3NpYmxlIHRvIHRoZSBwcmVmaXgtbGVuZ3RoIGhp bnQuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1JvbmkgRXZlbl0gSSBoYXZlIG5vIHBy b2JsZW0gd2l0aCB0aGlzIHRleHQgc2luY2UgaXQgd2lsbCBhbHNvIHdvcmsgd2l0aCB0aGUgcmVz dCBvZiB0aGUgZG9jdW1lbnQgYnV0IGlzIGl0IHdoYXQgd2FzIHJlYWxseSBtZWFudDxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsc28gYSBuaXQ8bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnG9yIGEgcHJlZml4IHdoaWNoIGlzIGxl bmd0aCBpcyBzaG9ydGVyIGFuZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgcHJlZml4LWxl bmd0aCBoaW50LiBJZiB0aGUgc2VydmVyIGNvdWxkIG5vdCBwcm92aWRlIGEgcHJlZml4IHdoaWNo IGxlbmd0aCBpcyBzaG9ydGVyIG9yIGVxdWFsIHRvIHRoZSBwcmVmaXgtbGVuZ3RoIGhpbnQsIHRo ZSBzZXJ2ZXIgU0hPVUxEIHByb3ZpZGUgdGhlIHByZWZpeCB3aGljaA0KIGxlbmd0aCBpcyBsb25n ZXIgYW5kIGFzIGNsb3NlIGFzIHBvc3NpYmxlIHRvIHRoZSBwcmVmaXgtbGVuZ3RoIGhpbnTigJ08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcb3Ig YSBwcmVmaXggd2hvc2UgbGVuZ3RoIGlzIHNob3J0ZXIgYW5kIGFzIGNsb3NlIGFzIHBvc3NpYmxl IHRvIHRoZSBwcmVmaXgtbGVuZ3RoIGhpbnQuIElmIHRoZSBzZXJ2ZXIgY291bGQgbm90IHByb3Zp ZGUgYSBwcmVmaXggd2l0aCBhIHNob3J0ZXIgb3IgZXF1YWwgbGVuZ3RoICZuYnNwO3RvIHRoZSBw cmVmaXgtbGVuZ3RoIGhpbnQsIHRoZSBzZXJ2ZXIgU0hPVUxEIHByb3ZpZGUgYSBwcmVmaXggd2hv c2UgbGVuZ3RoDQogaXMgbG9uZ2VyIGFuZCBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgcHJl Zml4LWxlbmd0aCBoaW504oCdPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPltUaWFueGlhbmddIFRoZSBpZGVhIHdhcyB0 byBsaXN0IGFsbCB0aGUgb3B0aW9ucywgYW5kIGRpc2N1c3MgdGhlaXIgY29uc2VxdWVuY2VzLiBB bmQgdGhlIHNlcnZlciBjb3VsZCBkZWNpZGUgd2hpY2ggb3B0aW9uIHRvIHVzZSBkZXBlbmRpbmcg b24gaXRzIHBvbGljeS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9wdGlvbiAzIGF2b2lkcyB0aGUgY29tcGxleGl0eSBvZiBo YW5kbGluZyBtdWx0aXBsZSBkZWxlZ2F0ZWQgcHJlZml4ZXMsIGRlc3BpdGUgb2YgYnJlYWtpbmcg dXAgYWxsIGNvbm5lY3Rpb25zLiBPcHRpb24gNCBhbGxvd3MgdG8gc2VydmVyIHRvIGNvbmZpZ3Vy ZSBhIHZhbGlkLWxpZmV0aW1lIGZvciB0aGUgb2xkDQogcHJlZml4IGRlcGVuZGluZyBvbiBhY3R1 YWwgcmVxdWlyZW1lbnRzLCByYXRoZXIgdGhhbiBsZXQgdGhlIG9sZCBwcmVmaXggZXhwaXJlIG9u IGl0cyBvd24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUm9uaSBFdmVuXSBPSywg c3RpbGwgb3B0aW9uIDQgbWF5IGhhdmUgc2ltaWxhciByZXN1bHQgdG8gMyBzaW5jZSDigJxhIHNo b3J0IG5vbi16ZXJv4oCdIG1heSBiZQ0KIHRvbyBzaG9ydC4gV2h5IG5vdCBhZGQgYSByZWNvbW1l bmRlZCB2YWx1ZT88L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5bVGlhbnhpYW5nMl0gQWdyZWUsIGFzIHRoaXMgbWF5IHZhcnkgZm9y IGRpZmZlcmVudCBzZXJ2aWNlcywgd2UgY291bGQgY2hhbmdlIHRoZSB0ZXh0IHRvIHNheSAmcXVv dDthIHNwZWNpZmljIHZhbGlkLWxpZmV0aW1lIGRlcGVuZGluZyBvbiB0aGUgYWN0dWFsIHJlcXVp cmVtZW50JnF1b3Q7LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltSb25pIEV2 ZW5dIE9LPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQpOaXRzL2VkaXRvcmlhbCBjb21tZW50czo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD771622DGGEMM506MBXchina_-- From nobody Thu Feb 2 06:44:16 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B180129416; Thu, 2 Feb 2017 06:44:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148604665210.13944.15621944233917718081.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 06:44:12 -0800 Archived-At: Cc: dhc-chairs@ietf.org, volz@cisco.com, draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org Subject: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-dhcpv6-failover-protocol-04=3A_=28with_COMMENT=29?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:44:12 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dhc-dhcpv6-failover-protocol-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few questions that are not fully clear to me and maybe need some additional explanation in the draft (or maybe it's just me...): - It's not fully clear to me when a TCP connection is opened or closed. Are the two servers supposed to have one long-lived connection? And if that connection is terminated for any reason, should the primary server try to re-open immediately? And if a (new) connection is (re-)open do I always need to send a CONNECT first, or only if I didn't have any connection with this server before? And if the secondary server goes down and comes up in RECOVER state (sec 8.5.1.), should it open a TCP connection to the primary server, or will always the primary server be the one that opens the connection (and if so when will it do it)? - Also not really clear to me is why OPTION_F_MAX_UNACKED_BNDUPD is needed and how the server should know the right value. I guess you would want to calculate this based on the send buffer, however, not all message have the same size and as such I don't know how to calculate that. And is that really needed? If messages will not be accepted by the receiver-side server, the receive window will be zero and the socket on the sending side will be blocked; no additional message can be send. What will be different if the sender knows in advance when it could potentially happen (but also might not if the other end processes the messages quickly and there is no excessive loss). From nobody Thu Feb 2 07:26:05 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ACD12946D; Thu, 2 Feb 2017 07:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LqguKZ3bEL2p; Thu, 2 Feb 2017 07:26:03 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17AC2129457; Thu, 2 Feb 2017 07:26:03 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id f9so14190592otd.1; Thu, 02 Feb 2017 07:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DnF+s4vIkTb7fBFANeAtifhEqUtodV4CLlUYBpBZ9DM=; b=EnYUbYoIXvZn9mq5UPZ8uPAbZsooOixyLXPRRyWv89QRbsf6ICrWH/EucCzvXsTnk5 RuksITqGSVU7z4eSR9MDCLWPohw3e2xI4zd3zMqlQYlHOa+ouDJR8sp9IudaFUGhGbGu 5WQOKjJvHzkUxODHO/xjcAG03cY6sI3sY4XjWpcOGDMhRCPBrslxRU+B+O2+tMedm4YX XK6M+lP5YRj/iTEKcoULSAQNSQwq0/uJyCFG30ZTblm8cgByZDYnq1Hw/RdrR9O2TQXh S8LCHXUy6kjAURyo9xCiWABvFcxEu9W5SLYVwfossitw1i1RhO4hznjUDEmPQqGf/cY6 Y07Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DnF+s4vIkTb7fBFANeAtifhEqUtodV4CLlUYBpBZ9DM=; b=Pi/C7EOa1LZIVaLRIEUoRcUG/XaizSpvavV4aMPGfm15s8YtPnHSJw2WxDfuyiSVlv r5YYaZ8cx8SntJt0l+xlDmUao2zx+e6TroCjJcd7hPe9xqlj1+PJ6SujJLRIs3LmX6rB nfqAmaTKQgt/YAPm8mFJWm5PPXV8izMttnosSPufTVAUzp+ZRDihFmwA6tglFXuS48Ub 2lxpB0RTCv/z7Dke5RJ/KruCGAMkTp0terXJTLkvJzIbZiMxShcWPfeeqf15PCxu3MaR m5bNQTxFQZRgnU4AqZMkbk5oFUgGVyaftrlluDELxNSh60S6t8ujXVPoYHp9HCoxK3cX S68Q== X-Gm-Message-State: AMke39llhjmuR/0ba06CoHmy9S5aIfn5/6xzkzLsKVPnUDYWudZwzD84B3F0VLlyLlusqpD8lLz7tjzafkJUsg== X-Received: by 10.157.60.149 with SMTP id z21mr4074859otc.34.1486049162280; Thu, 02 Feb 2017 07:26:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.1.202 with HTTP; Thu, 2 Feb 2017 07:25:21 -0800 (PST) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD771622@DGGEMM506-MBX.china.huawei.com> References: <148568056700.24536.11691583944564362484.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD770018@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD771622@DGGEMM506-MBX.china.huawei.com> From: tianxiang li Date: Thu, 2 Feb 2017 23:25:21 +0800 Message-ID: To: Roni Even Content-Type: multipart/alternative; boundary=94eb2c19018e6fc61805478dc8b4 Archived-At: Cc: dhcwg , "gen-art@ietf.org" , Roni Even , "ietf@ietf.org" , "draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@ietf.org" Subject: Re: [dhcwg] [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:26:04 -0000 --94eb2c19018e6fc61805478dc8b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Roni, Thank you for comments, we'll add the changes to the document in our next updated version. Please see inline. Cheers, Tianxiang 2017-02-02 14:42 GMT+08:00 Roni Even : > Hi, > > I will leave only the items that needed my response > > > > 7. In section 3.4 =E2=80=9CIf the client decided to use the prefix = provided > by the server despite being longer than the prefix-length hint=E2=80=9D = yet I > did not see in section 3.2 that the server can provide a longer > prefix. > > > > [Tianxiang] This was mentioned in the last sentence of section 3.2: > > > > "If the requested prefix is not available in the server's prefix pool, an= d > the client also included a prefix-length hint in the same IA_PD option, > then the server SHOULD try to provide a prefix matching the prefix-length > value, or the prefix with the shortest length possible which is closest t= o > the prefix-length hint value." > > *[Roni Even] I understood from 3.2 that it should provide a shorter lengt= h > prefix closer to the request maybe =E2=80=9C*or the prefix with the clos= est > possible length to the prefix-length hint value=E2=80=9D > > > > [Tianxiang2] The original sentence was a bit confusing, perhaps we could > change it like this: > > > > OLD: "If the requested prefix is not available in the server's prefix > pool, and the client also included a prefix-length hint in the same IA_PD > option, then the server SHOULD try to provide a prefix matching the > prefix-length value, or the prefix with the shortest length possible whic= h > is closest to the prefix-length hint value." > > > > NEW:"If the requested prefix is not available in the server's prefix pool= , > and the client also included a prefix-length hint in the same IA_PD optio= n, > then the server SHOULD provide a prefix matching the prefix-length hint, = or > a prefix which is length is shorter and as close as possible to the > prefix-length hint. If the server could not provide a prefix which length > is shorter or equal to the prefix-length hint, the server SHOULD provide > the prefix which length is longer and as close as possible to the > prefix-length hint." > > > > *[Roni Even] I have no problem with this text since it will also work wit= h > the rest of the document but is it what was really meant* > > > [Tianxiang3] This was the intended meaning of the original sentence, if the server could not honor the hint, it should provide a prefix closest to the hint, the client could then decide whether to accept or neglect this prefix= . > *Also a nit* > > > > =E2=80=9Cor a prefix which is length is shorter and as close as possible = to the > prefix-length hint. If the server could not provide a prefix which length > is shorter or equal to the prefix-length hint, the server SHOULD provide > the prefix which length is longer and as close as possible to the > prefix-length hint=E2=80=9D > > > > to > > > > =E2=80=9Cor a prefix whose length is shorter and as close as possible to = the > prefix-length hint. If the server could not provide a prefix with a short= er > or equal length to the prefix-length hint, the server SHOULD provide a > prefix whose length is longer and as close as possible to the prefix-leng= th > hint=E2=80=9D > [Tianxiang3] Thanks for the suggestion, we will edit this sentence accordingly. > > > > > Nits/editorial comments: > > > > > --94eb2c19018e6fc61805478dc8b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Roni,

Thank you for comments, we'= ;ll add the changes to the document in our next updated version.
= Please see inline.=C2=A0

Cheers,
Tianxia= ng

2017-02-0= 2 14:42 GMT+08:00 Roni Even <roni.even@huawei.com>:

Hi,<= /p>

I will leave only the ite= ms that needed my response

=C2=A0

7.=C2=A0 =C2=A0 =C2=A0 In section 3.4 =E2=80=9CIf th= e client decided to use=C2=A0 the prefix provided
by the server despite being longer than the=C2=A0 prefix-length hint=E2=80= =9D yet I
did not see in section 3.2 that the server can provide a longer
prefix.

=C2=A0

[Tianxiang] This was mentioned in the last sentence = of section 3.2:=C2=A0

=C2=A0

"If the requested prefix is not available in th= e server's prefix pool, and the client also included a prefix-length hi= nt in the same IA_PD option, then the server SHOULD try to provide a prefix matching the prefix-length value, or the prefix with the = shortest length possible which is closest to the prefix-length hint value.&= quot;

[Roni Even] I under= stood from 3.2 that it should provide a shorter length prefix =C2=A0closer = to the request maybe =E2=80=9Cor the prefix with the closest p= ossible length to the prefix-length hint value=E2=80=9D

=C2=A0

[Tianxiang2] The original sentence was a bit confusi= ng, perhaps we could change it like this:

=C2=A0

OLD:=C2=A0"If the requested prefix is not avail= able in the server's prefix pool, and the client also included a prefix= -length hint in the same IA_PD option, then the server SHOULD try to provid= e a prefix matching the prefix-length value, or the prefix with the shortest length possible which is closest to the prefi= x-length hint value."

=C2=A0

NEW:"If the requested prefix is not available i= n the server's prefix pool, and the client also included a prefix-lengt= h hint in the same IA_PD option, then the server SHOULD provide a prefix ma= tching the prefix-length hint, or a prefix which is length is shorter and as close as possible to the prefix-length h= int. If the server could not provide a prefix which length is shorter or eq= ual to the prefix-length hint, the server SHOULD provide the prefix which l= ength is longer and as close as possible to the prefix-length hint."

=C2=A0

[Roni Even] = I have no problem with this text since it will also work with the rest of t= he document but is it what was really meant

=C2=A0

[T= ianxiang3] This was the intended meaning of the original sentence, if the s= erver could not honor the hint, it should provide a prefix closest to the h= int, the client could then decide whether to accept or neglect this prefix.=
=C2=A0

=

Also a nit

=C2=A0

=E2=80=9Cor a prefix which is length is shorter and = as close as possible to the prefix-length hint. If the server could not pro= vide a prefix which length is shorter or equal to the prefix-length hint, t= he server SHOULD provide the prefix which length is longer and as close as possible to the prefix-length hint=E2=80= =9D

=C2=A0

to

=C2=A0

=E2=80=9Cor a prefix whose length is shorter and as = close as possible to the prefix-length hint. If the server could not provid= e a prefix with a shorter or equal length =C2=A0to the prefix-length hint, = the server SHOULD provide a prefix whose length is longer and as close as possible to the prefix-length hint=E2=80=9D

<= /div>

[= Tianxiang3] Thanks for the suggestion, we will edit this sentence according= ly.=C2=A0

=C2=A0



Nits/editorial comments:

=C2=A0

=C2=A0


--94eb2c19018e6fc61805478dc8b4-- From nobody Thu Feb 2 07:28:23 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A9D12966F; Thu, 2 Feb 2017 07:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 uAySzByEUBmI; Thu, 2 Feb 2017 07:28:16 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD82012966C; Thu, 2 Feb 2017 07:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3404; q=dns/txt; s=iport; t=1486049296; x=1487258896; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Z/2cop4PRCHGySr0Ee4eWvT/j5bPGnMPbQFoDPkrGG4=; b=hRFk0pMvtESOVq+cC7vQkF0HB+RDNTLaFgdUlqfomYO+1aTXEJxAtAIY 7FPcsef5XTnF4oNf38oLgxquI7lzmR10U8Mjj0x5ediFKcgC1jyYTFTOO z5bhWPpi5kSwOF8qRinrZU3LZ86i4JlqTsWhIDtC9A2QQ7CInAEA7ry6g Q=; X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208";a="380588381" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2017 15:28:15 +0000 Received: from [161.44.67.129] ([161.44.67.129]) (authenticated bits=0) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v12FSE8O028361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2017 15:28:14 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: kkinnear In-Reply-To: <148599922705.18700.14648245113952484559.idtracker@ietfa.amsl.com> Date: Thu, 2 Feb 2017 10:28:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2BD6519B-F6AC-4630-8666-13D3ED54054C@cisco.com> References: <148599922705.18700.14648245113952484559.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) X-Authenticated-User: kkinnear@cisco.com Archived-At: Cc: Bernie Volz , dhc-chairs@ietf.org, The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] Stephen Farrell's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:28:17 -0000 Stephen, Thanks for your review! I've responded to your comments, indented, below... > On Feb 1, 2017, at 8:33 PM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-dhc-dhcpv6-failover-protocol-04: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - I support Ben's discuss about "secure mode" - a few > more details are needed, in particular how a pair > decide to use/not-use TLS - are there different ports > or a STARTTLS equivalent - I can't see that defined > here. (Is it inherited from RFC7653? If so, maybe you > need to say?) Yes, Section 9.1 of RFC 7653 discusses exactly this issue (in part due to your review comments from July 2015, as it happens). I believe the discussion there is sufficient. I substantially enhanced the Security Considerations section as a result of Ben Campbell's comments. One paragraph that I added discussed secure and insecure mode. I will expand that paragraph to point in more detail towards RFC 7653 as follows: "DHCPv6 failover can operate in secure or insecure mode. Secure mode (using TLS) would be indicated when the TCP connection between failover partners is open to external monitoring or interception. Insecure mode should only be used when the TCP connection between failover partners remains within set of protected systems. Details of such protections are beyond the scope of this document. Failover servers MUST use the approach documented in Section 9.1 of [RFC7653] to decide to use or not to use TLS." >=20 > - For the DNS update stuff - is there no need to use > TSIG secrets? If there is, how is that sync'd between > the pair of DHCP servers? If it is sync'd then don't > you need to say that TLS is a MUST for such > connections? If there is no support for TSIG, is that > likely to work? >=20 >=20 Surely, TSIG is important. Each DHCP server in a failover pair has its own relationship with the relevant DNS servers, and needs to be configured with the correct TSIG secrets to update those DNS servers. The configuration of a DHCP server to communicate with a DNS server is a configuration issue, and outside of the scope of the failover protocol. =20 In the (now blessedly distant) past, we spent years working on the DHCPv4 failover protocol trying to shoehorn configuration information into the protocol, and it never worked. DHCP servers need *lots* of configuration, and we have most consciously decided that synchronizing that configuration between failover partners is not the purpose of the DHCPv6 failover protocol. Thanks again for your review! Kim From nobody Thu Feb 2 07:31:12 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FA9129662; Thu, 2 Feb 2017 07:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 lNOPfdRWriXq; Thu, 2 Feb 2017 07:31:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CFC129468; Thu, 2 Feb 2017 07:31:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39B23BE5D; Thu, 2 Feb 2017 15:31:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qIelSqgeAcR; Thu, 2 Feb 2017 15:31:00 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2E139BE38; Thu, 2 Feb 2017 15:31:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486049460; bh=aAHD3t2PWgmJOiEJRvJMZzahDWKKITZfBfWZMuLciPQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=JT4ITfTMriW7NBrDOkU6ti4jVDwTYqt1gRNYRaj0hqVHJfLl62vTqCf0ndukwLnQL wiNfM0Kqy8UEa6pIS7MNX/3qFhsmnDCG+2HWjuofvPtG62sX03wHVCgmb9gfSFj0mj 5Ym+z+ixIfXSbbzdfFO86s2kpeFRtfPa17qyBIH8= To: kkinnear References: <148599922705.18700.14648245113952484559.idtracker@ietfa.amsl.com> <2BD6519B-F6AC-4630-8666-13D3ED54054C@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <8f0ee693-8fd9-0202-209d-09b503f2231b@cs.tcd.ie> Date: Thu, 2 Feb 2017 15:30:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <2BD6519B-F6AC-4630-8666-13D3ED54054C@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070607020000020900010208" Archived-At: Cc: dhc-chairs@ietf.org, dhcwg@ietf.org, Bernie Volz , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, The IESG Subject: Re: [dhcwg] Stephen Farrell's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:31:11 -0000 This is a cryptographically signed message in MIME format. --------------ms070607020000020900010208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kim, On 02/02/17 15:28, kkinnear wrote: > In the (now blessedly distant) past, we spent years working on > the DHCPv4 failover protocol trying to shoehorn configuration > information into the protocol, and it never worked. DHCP > servers need *lots* of configuration, and we have most > consciously decided that synchronizing that configuration > between failover partners is not the purpose of the DHCPv6 > failover protocol. Thanks - that'd have helped me as a reader but if implementers would know it for sure, then I guess it's fine as-is. Thanks, S. --------------ms070607020000020900010208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDIx NTMwNTlaMC8GCSqGSIb3DQEJBDEiBCCqVE16oJ5/7imCQ9bZ1YQweAVtCqhF4EG58ILTbEWQ 5zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAMyHOUDS4ibtJz4WFrIDs5uODbuMo9XJrq7t6xR3qY0QLYMPyVcmiI qTZ+X3D8TebKqH55/S2CuPy7+25CQFi2N/Pbc/sUsSz088HqmHW/44u61fxn3B02sXzsvLIG +h5DwtMhDFu1Mw4TPY0Go6VOc8uuq6PDSRV1WDRWY5yGEGbe0Z9m2Dx5LsrEdMOrgiWKURp0 wozj2HHfXQhvXU5E+WCXTewCim0UmQ1MdpNoVDhQ0OG9bFRArfhp/8yuil2ebH2mAEszNhT0 Kc724C7d0NLHD01H1XamO4wyjEUS81kvOOI49g2DB3YKulrRvWvBVyqHAAh92KlXsvT50rMO AAAAAAAA --------------ms070607020000020900010208-- From nobody Thu Feb 2 08:26:07 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DB812969F; Thu, 2 Feb 2017 08:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 iqY4C9St0JmP; Thu, 2 Feb 2017 08:25:58 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F80412943F; Thu, 2 Feb 2017 08:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4938; q=dns/txt; s=iport; t=1486052757; x=1487262357; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aOtgjqBr5VLX0CINbwZLtgV9/lMCkFoMdgwAtN6DETQ=; b=hbEb8MbQE0V3A8idaL4+OrFsxEsf+L9+dRl0rGdFfd1+T+ob0BM94Buc gNf/upw/nljEg94xvYMMfrMJ0DB0KaZOKQBS6ysQFGJFfygSO0KLKCrXd ZHuFnkdhXcvTXwd7HrkRjCBt9aJRG3/42X1KDprd8qHbWqGHlwVkP649v g=; X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208";a="380435301" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2017 16:25:56 +0000 Received: from [161.44.67.129] ([161.44.67.129]) (authenticated bits=0) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v12GPtHa023833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2017 16:25:56 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: kkinnear In-Reply-To: <148604665210.13944.15621944233917718081.idtracker@ietfa.amsl.com> Date: Thu, 2 Feb 2017 11:25:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148604665210.13944.15621944233917718081.idtracker@ietfa.amsl.com> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3124) X-Authenticated-User: kkinnear@cisco.com Archived-At: Cc: Bernie Volz , dhc-chairs@ietf.org, The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-dhcpv6-failover-protocol-04=3A_=28with_COMMENT=29?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:26:00 -0000 Mirja, Thanks for your review. I'll respond to your questions directly, indented, below... > On Feb 2, 2017, at 9:44 AM, Mirja Kuehlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-dhc-dhcpv6-failover-protocol-04: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > A few questions that are not fully clear to me and maybe need some > additional explanation in the draft (or maybe it's just me...): >=20 > - It's not fully clear to me when a TCP connection is opened or = closed. > Are the two servers supposed to have one long-lived connection? And if > that connection is terminated for any reason, should the primary = server > try to re-open immediately? And if a (new) connection is (re-)open do = I > always need to send a CONNECT first, or only if I didn't have any > connection with this server before? And if the secondary server goes = down > and comes up in RECOVER state (sec 8.5.1.), should it open a TCP > connection to the primary server, or will always the primary server be > the one that opens the connection (and if so when will it do it)? I would have thought that this was spelled out, but as I look at the draft I see that it isn't all that explicit. While I could answer your questions directly, let me instead offer a new paragraph which tries to answer these questions for not just you but other readers of the document: 6. Connection Management Communication between failover partners takes place over a long-lived TCP connection. This connection is always initiated by the primary server, and if the long-lived connection is lost it is the responsibility of the primary server to attempt to reconnect to the secondary server. The detailed process used by the primary server when initiating a connection and by the secondary server when responding to a connection attempt documented in Section 6.1 is followed each time a connection is established, regardless of any previous connection between the failover partners. 6.1. Creating Connections >=20 > - Also not really clear to me is why OPTION_F_MAX_UNACKED_BNDUPD is > needed and how the server should know the right value. I guess you = would > want to calculate this based on the send buffer, however, not all = message > have the same size and as such I don't know how to calculate that. And = is > that really needed? If messages will not be accepted by the = receiver-side > server, the receive window will be zero and the socket on the sending > side will be blocked; no additional message can be send. What will be > different if the sender knows in advance when it could potentially = happen > (but also might not if the other end processes the messages quickly = and > there is no excessive loss). >=20 The intent here is to keep the TCP connection unblocked, so that information can flow in both directions. If one direction is is maxed out, it shouldn't keep information from flowing in the other direction. At a TCP level it won't, but at an application level it will. Much of the failover information flow involves one server sending a BNDUPD and then the partner sends a BNDREPLY. If one server server sends more BNDUPD's than the other server can absorb, the TCP connection will block. This will mean that any BNDREPLY's from the server that sent the BNDUPD's will also be blocked. Ideally, the BNDUPD->BNDREPLY flow from each server to the other would be independent, and the OPTION_F_MAX_UNACKED_BNDUPD count is designed to help that be true. Additionally, there are messages other than BNDUPD/BNDREPLY (e.g. STATE, DISCONNECT, UPDDONE) that are important to transmit from one server to the other and not have backed up behind a blocked TCP connection that has been overloaded with BNDUPD's for the partner to process. We could have created a separate TCP connection for these control messages, but the overhead of doing that (and specifying that) was great enough that it seemed like using the application-level flow control of the OPTION_F_MAX_UNACKED_BNDUPD was a good tradeoff. Thanks again for your review! Kim From nobody Thu Feb 2 09:08:06 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F411298C0 for ; Thu, 2 Feb 2017 09:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 R139Rp8foUys for ; Thu, 2 Feb 2017 09:08:01 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CAE81298BF for ; Thu, 2 Feb 2017 09:08:01 -0800 (PST) Received: (qmail 25687 invoked from network); 2 Feb 2017 18:07:57 +0100 Received: from p5dec271a.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.39.26) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Feb 2017 18:07:57 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 2 Feb 2017 18:07:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35D633DF-B240-4CB9-A1DC-A27FD1048213@kuehlewind.net> References: <148604665210.13944.15621944233917718081.idtracker@ietfa.amsl.com> To: kkinnear X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhc-chairs@ietf.org, dhcwg@ietf.org, Bernie Volz , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, The IESG Subject: Re: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-dhcpv6-failover-protocol-04=3A_=28with_COMMENT=29?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 17:08:04 -0000 Hi Kim, thanks for your reply. See below. > Am 02.02.2017 um 17:25 schrieb kkinnear : >=20 > Mirja, >=20 > Thanks for your review. >=20 > I'll respond to your questions directly, indented, below... >=20 >> On Feb 2, 2017, at 9:44 AM, Mirja Kuehlewind = wrote: >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-dhc-dhcpv6-failover-protocol-04: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> A few questions that are not fully clear to me and maybe need some >> additional explanation in the draft (or maybe it's just me...): >>=20 >> - It's not fully clear to me when a TCP connection is opened or = closed. >> Are the two servers supposed to have one long-lived connection? And = if >> that connection is terminated for any reason, should the primary = server >> try to re-open immediately? And if a (new) connection is (re-)open do = I >> always need to send a CONNECT first, or only if I didn't have any >> connection with this server before? And if the secondary server goes = down >> and comes up in RECOVER state (sec 8.5.1.), should it open a TCP >> connection to the primary server, or will always the primary server = be >> the one that opens the connection (and if so when will it do it)? >=20 >=20 > I would have thought that this was spelled out, but as I look > at the draft I see that it isn't all that explicit. While I > could answer your questions directly, let me instead offer a > new paragraph which tries to answer these questions for not > just you but other readers of the document: >=20 >=20 > 6. Connection Management >=20 > Communication between failover partners takes place over a > long-lived TCP connection. This connection is always initiated by > the primary server, and if the long-lived connection is lost it is > the responsibility of the primary server to attempt to reconnect to > the secondary server. The detailed process used by the primary > server when initiating a connection and by the secondary server > when responding to a connection attempt documented in > Section 6.1 is followed each time a connection is established, > regardless of any previous connection between the failover > partners. >=20 Thanks, that=E2=80=99s great! > 6.1. Creating Connections >=20 >=20 >>=20 >> - Also not really clear to me is why OPTION_F_MAX_UNACKED_BNDUPD is >> needed and how the server should know the right value. I guess you = would >> want to calculate this based on the send buffer, however, not all = message >> have the same size and as such I don't know how to calculate that. = And is >> that really needed? If messages will not be accepted by the = receiver-side >> server, the receive window will be zero and the socket on the sending >> side will be blocked; no additional message can be send. What will be >> different if the sender knows in advance when it could potentially = happen >> (but also might not if the other end processes the messages quickly = and >> there is no excessive loss). >>=20 >=20 >=20 > The intent here is to keep the TCP connection unblocked, so > that information can flow in both directions. If one > direction is is maxed out, it shouldn't keep information from > flowing in the other direction. At a TCP level it won't, but > at an application level it will. Much of the failover > information flow involves one server sending a BNDUPD and then > the partner sends a BNDREPLY. If one server server sends more > BNDUPD's than the other server can absorb, the TCP connection > will block. This will mean that any BNDREPLY's from the > server that sent the BNDUPD's will also be blocked. Ideally, > the BNDUPD->BNDREPLY flow from each server to the other would > be independent, and the OPTION_F_MAX_UNACKED_BNDUPD count is > designed to help that be true. So you mean this is purely an application parameter saying I will not = process more than X messages at once (before sending out a BNDREPLY). So = this is rather independent of any socket buffer configuration, expect = that the buffer needs to be large enough to at least handle X (max-size) = messages which maybe is a good thing to notice as well. However, this basically means that you at sender-side anyway need a way = to cache BNDUPD message that you are not allowed to send out yet. Why = don=E2=80=99t you just basically set this value implicitly always to 1 = and say you can=E2=80=99t send another BNDUPD if an BNDREPLY is still = outstanding=E2=80=A6? I would guess it=E2=80=99s anyway rather unlikely = that you need to send more than one message at once, no? >=20 > Additionally, there are messages other than BNDUPD/BNDREPLY > (e.g. STATE, DISCONNECT, UPDDONE) that are important to > transmit from one server to the other and not have backed up > behind a blocked TCP connection that has been overloaded with > BNDUPD's for the partner to process. >=20 > We could have created a separate TCP connection for these > control messages, but the overhead of doing that (and > specifying that) was great enough that it seemed like using > the application-level flow control of the > OPTION_F_MAX_UNACKED_BNDUPD was a good tradeoff. I would actually say that the overhead is rather low. Maybe one should = discuss this option at least as one potential implementation = possibility. The only hard requirement is that the receiver side would = be able to process message coming from different connections from the = same endpoint, which I assume would be easy given you anyway have to = handle different connections from different endpoints, no? Thanks! Mirja >=20 >=20 > Thanks again for your review! >=20 > Kim >=20 >=20 >=20 >=20 >=20 From nobody Thu Feb 2 09:43:56 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74950129958; Thu, 2 Feb 2017 09:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 kva88jT21-r7; Thu, 2 Feb 2017 09:43:50 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9EE12994F; Thu, 2 Feb 2017 09:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5236; q=dns/txt; s=iport; t=1486057426; x=1487267026; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VDcxvvoTKDQlcqHSKbOSllVY3hMyXunmyTTMj885grU=; b=EjATLC8EdbW5MIN7nF3y5P7PaxQjpfO3yCV3GTV440HZJKhVYNqVLjxH QdDPZDwzVveSiDIiXeEiQ9oO7ZkvPGh2lHQqA1CQnvnGyYkuJt8CeNxlo fLSk9F5yQ0dnbHPeOS6+DIwyIZDz0iAbZxlo6UtOLkDrZODFIgvsQiJwi s=; X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208";a="202001882" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2017 17:43:45 +0000 Received: from [161.44.67.129] ([161.44.67.129]) (authenticated bits=0) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v12HhiY7031624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2017 17:43:45 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: kkinnear In-Reply-To: <35D633DF-B240-4CB9-A1DC-A27FD1048213@kuehlewind.net> Date: Thu, 2 Feb 2017 12:43:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0EB0E49E-B201-441B-834B-47A050EDA757@cisco.com> References: <148604665210.13944.15621944233917718081.idtracker@ietfa.amsl.com> <35D633DF-B240-4CB9-A1DC-A27FD1048213@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3124) X-Authenticated-User: kkinnear@cisco.com Archived-At: Cc: Bernie Volz , dhc-chairs@ietf.org, The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-dhcpv6-failover-protocol-04=3A_=28with_COMMENT=29?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 17:43:51 -0000 Mirja, More comments, below... > On Feb 2, 2017, at 12:07 PM, Mirja Kuehlewind (IETF) = wrote: >=20 > [... removed already handled issue -- Kim] >=20 >> 6.1. Creating Connections >>=20 >>=20 >>>=20 >>> - Also not really clear to me is why OPTION_F_MAX_UNACKED_BNDUPD is >>> needed and how the server should know the right value. I guess you = would >>> want to calculate this based on the send buffer, however, not all = message >>> have the same size and as such I don't know how to calculate that. = And is >>> that really needed? If messages will not be accepted by the = receiver-side >>> server, the receive window will be zero and the socket on the = sending >>> side will be blocked; no additional message can be send. What will = be >>> different if the sender knows in advance when it could potentially = happen >>> (but also might not if the other end processes the messages quickly = and >>> there is no excessive loss). >>>=20 >>=20 >>=20 >> The intent here is to keep the TCP connection unblocked, so >> that information can flow in both directions. If one >> direction is is maxed out, it shouldn't keep information from >> flowing in the other direction. At a TCP level it won't, but >> at an application level it will. Much of the failover >> information flow involves one server sending a BNDUPD and then >> the partner sends a BNDREPLY. If one server server sends more >> BNDUPD's than the other server can absorb, the TCP connection >> will block. This will mean that any BNDREPLY's from the >> server that sent the BNDUPD's will also be blocked. Ideally, >> the BNDUPD->BNDREPLY flow from each server to the other would >> be independent, and the OPTION_F_MAX_UNACKED_BNDUPD count is >> designed to help that be true. >=20 > So you mean this is purely an application parameter saying I will not = process more than X messages at once (before sending out a BNDREPLY). So = this is rather independent of any socket buffer configuration, expect = that the buffer needs to be large enough to at least handle X (max-size) = messages which maybe is a good thing to notice as well. This is an application parameter saying that I can accept up to X messages at once without blocking the TCP connection. That isn't in conflict with what you said, but is focused a bit differently. It is independent of any socket buffer configuration -- this is application level flow control. >=20 > However, this basically means that you at sender-side anyway need a = way to cache BNDUPD message that you are not allowed to send out yet. = Why don=E2=80=99t you just basically set this value implicitly always to = 1 and say you can=E2=80=99t send another BNDUPD if an BNDREPLY is still = outstanding=E2=80=A6? I would guess it=E2=80=99s anyway rather unlikely = that you need to send more than one message at once, no? Servers frequently need send far more than one BNDUPD at once. The most extreme typical case is when one server is updating a partner which has been down with information about what has been happening while the partner was down. This will generate thousands to tens of thousands of BNDUPD's. When one server has lost its stable storage completely and needs to essentially be initialized by the other server, millions of BNDUPD's may need to flow across the link. Doing them one at a time, while technically correct, typically leaves a lot of performance on the table and could easily extend the time before the servers synchronize from seconds to tens of minutes (and possibly hours). Many DHCP servers are multi-threaded and can process multiple BNDUPD's at the same time (though they may batch up the writes to the disk). Thus, we would expect that most servers implementing this protocol would set this value to something substantial. >=20 >>=20 >> Additionally, there are messages other than BNDUPD/BNDREPLY >> (e.g. STATE, DISCONNECT, UPDDONE) that are important to >> transmit from one server to the other and not have backed up >> behind a blocked TCP connection that has been overloaded with >> BNDUPD's for the partner to process. >>=20 >> We could have created a separate TCP connection for these >> control messages, but the overhead of doing that (and >> specifying that) was great enough that it seemed like using >> the application-level flow control of the >> OPTION_F_MAX_UNACKED_BNDUPD was a good tradeoff. >=20 > I would actually say that the overhead is rather low. Maybe one should = discuss this option at least as one potential implementation = possibility. The only hard requirement is that the receiver side would = be able to process message coming from different connections from the = same endpoint, which I assume would be easy given you anyway have to = handle different connections from different endpoints, no? Having different implementation possibilities in something as basic as connection management in a protocol already this complex is something we have tried hard to avoid, and we could only justify it if it were necessary to solve a very pressing problem. Thanks -- Kim From nobody Thu Feb 2 10:49:20 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3501129958; Thu, 2 Feb 2017 10:49:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148606135892.13926.17576770867962404412.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 10:49:18 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-protocol-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:49:19 -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 of the IETF. Title : DHCPv6 Failover Protocol Authors : Tomasz Mrugalski Kim Kinnear Filename : draft-ietf-dhc-dhcpv6-failover-protocol-05.txt Pages : 94 Date : 2017-02-02 Abstract: DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" (RFC3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC7031). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-failover-protocol-05 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 Feb 2 10:58:30 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FDD1294F2; Thu, 2 Feb 2017 10:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 oFoHfUFHpkG1; Thu, 2 Feb 2017 10:58:27 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A2A129511; Thu, 2 Feb 2017 10:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2259; q=dns/txt; s=iport; t=1486061907; x=1487271507; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RNDr2/rKbgqFjLpCSp70kJ/aWh9SUt2uiDGtQrVW6sU=; b=MJX9twSBSnuVf1dMaHamBUm1iGxXiJHIGKfm0YRizZM2Fhfxp0W/SDRC LApW/HmKtHsSVyxiGksIW9aF68qB1MFhWV/xypOpeSGJA0bfEMYSRNvaP W47VnpaQ9HX0DN1G4o/k1USH1VQdOgLs11ODn452Vqw83KqAH31tKw8wi o=; X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208";a="379919429" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2017 18:58:26 +0000 Received: from [161.44.67.129] ([161.44.67.129]) (authenticated bits=0) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v12IwObv013283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2017 18:58:25 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: kkinnear In-Reply-To: <8f0ee693-8fd9-0202-209d-09b503f2231b@cs.tcd.ie> Date: Thu, 2 Feb 2017 13:58:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <74FB30F1-234A-4D1C-BF3C-ED4DAA4C3F4E@cisco.com> References: <148599922705.18700.14648245113952484559.idtracker@ietfa.amsl.com> <2BD6519B-F6AC-4630-8666-13D3ED54054C@cisco.com> <8f0ee693-8fd9-0202-209d-09b503f2231b@cs.tcd.ie> To: dhc-chairs@ietf.org, The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, "" , Bernie Volz X-Mailer: Apple Mail (2.3124) X-Authenticated-User: kkinnear@cisco.com Archived-At: Cc: Kim Kinnear Subject: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-failover-protocol-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:58:28 -0000 I have submitted a new version of the DHCPv6 Failover Protocol: draft-ietf-dhc-dhcpv6-failover-protocol-05 = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ = which reflects changes resulting from the IESG and directorate reviews to date. All of these changes are to explain things more clearly or explicitly. None of them alter the intended operation of the protocol. * Added a sentence at the end of the Security Considerations section saying that if authentication of failover partners is desired, that TLS SHOULD be employed. [Kathleen Moriarty] * Significantly expanded the Security Considerations section to discuss some of the threats and when you might use secure and insecure mode. [Ben Campbell] * Added clarification as to the use of the OPTION_F_PROTOCOL_VERSION option in the CONNECT and CONNECTREPLY message. [Ben Campbell] * Added information at the beginning of the Introduction describing the failover protocol and pointing to the DHCPv6 Failover Requirements, RFC 7031. [Christer Holmberg] * Included a reference to RFC 3315 when the DHCPv6 server is first mentioned. [Christer Holmberg] * Removed the term "DHCP service" from the Introduction as well as one other section of the draft, replacing it with "a service to DHCP clients". [Christer Holmberg] * Added text to the beginning of Section 4 Failover Concepts and Mechanisms, that clarifies that these concept and mechanisms are not present in RFC 3315, are required for failover, and are supported by the failover protocol. [Christer Holmberg] * Changed all instances of "this protocol" to be "the failover protocol". [Christer Holmberg] * Added a pointer in the Security Considerations section to Section 9.1 of RFC7653 which describes how two DHCPv6 servers can decide to use or not use TLS when connecting. [Stephen Farrell] * Added a paragraph in Section 6, Connection Management giving an overview of how connections are created and used by the failover protocol. [Mirja Kuhlewind] Regards -- Kim =20 =20 From nobody Thu Feb 2 12:07:34 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8860B1299AE; Thu, 2 Feb 2017 12:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Hb3r0U4i9bvK; Thu, 2 Feb 2017 12:07:31 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30C2129552; Thu, 2 Feb 2017 12:07:30 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id x49so49491893qtc.2; Thu, 02 Feb 2017 12:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JVg9FL6wIHuBp/e44/kAB+F2KpumXUj9iYBD2vC8qq8=; b=iF+YP1imN57+pR1u3HCtHG4BqRn+LGwK+aat97e9qjrBzOz1FhL3P5yEGHcsiVILO/ +ddxSrB15gDMm+wKJ1YbopOziFSbR0SFzXbxVd1ZT+aDmFZMMhABkpzMEGO8AyDBAiun 4ganWJUQyoCdNPu1wMHU732VpDvPHpDDPD4YKMNeS9iMIJhmfYNxXuKax1yUG/mVVWty 373folEqkghYFQ7uQUZOKcaQcUSHa8h8sU6XJmJoIo0G6KLp6tIfWRDYYoFSFc56NRFe QsJtsEHx90Sd5Sp3zxzkXY+xwUTW2kU2X1TqbKLg4tOfyObKRSP8BD4LdPjutbqjLA6f bE/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JVg9FL6wIHuBp/e44/kAB+F2KpumXUj9iYBD2vC8qq8=; b=PSJ4IAiG09SelEezES/n38/XREaeBqITIO0NNlfXC2uMGB+0AEkvy0slWfLOtnZRgP UxwiKyMQRc+PfqIPbCy5VgbacPgrZ+cLukrslDinqYIs1CKYJzxI81RILKvzHDnEFPPh aefNqLA4UBV/POxjCPBMatfzRqICJ2wSJHbXZZvOEIU8Zn5CeCZ7rVD65Jpy9Yy0bbym s7habOjnRz2ZtzFPm//FHIbCAr8Gi7ZcpTlqtJohuoAE4NlTJH9Zg/KtZRQdcJxoUoss zPzgqcmmTG0h+SNAhcXXL5n6WpGFWGgOe4g5JVBYOAZUv0GD+CjSFGZLzOsYG5wRe3bf u6wA== X-Gm-Message-State: AIkVDXKnZ9NyGcQVOtruhRkJTDrETBPBc1FgTMns0WPRkACdfL7NN/SiFZuQPXomdsSBQHCty0M6vHCE0pEckA== X-Received: by 10.200.55.230 with SMTP id e35mr9852614qtc.30.1486066049289; Thu, 02 Feb 2017 12:07:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Thu, 2 Feb 2017 12:07:28 -0800 (PST) In-Reply-To: References: <148589004659.5913.10170408064364078877.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 2 Feb 2017 15:07:28 -0500 Message-ID: To: kkinnear Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" , "" , The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, Bernie Volz Subject: Re: [dhcwg] Kathleen Moriarty's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 20:07:32 -0000 Hi Kim, Thanks for your response, inline. On Tue, Jan 31, 2017 at 4:46 PM, kkinnear wrote: > Kathleen, > > Thanks for your comments. My responses are indented below. > >> On Jan 31, 2017, at 2:14 PM, Kathleen Moriarty wrote: >> >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-dhc-dhcpv6-failover-protocol-04: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I have 2 questions that I would like to chat about and should be easy >> enough to resolve. >> >> 1. I know we've discussed in the past why there is no MUST for TLS and it >> having to do with DHCPv6 use on private networks or isolated. Is there >> text in one of the more recent RFCs that covers this explanation that can >> be cited? I'd like to make sure that's enough too. > > To the best of my knowledge the justifications for both a secure > and an insecure mode have been kept out of the RFC's themselves, > and are scattered over a variety of issues raised for different > drafts. A pretty succinct summary came from you for the DHCPv4 > Active Leasequery draft (the bottom of this page): > > https://datatracker.ietf.org/doc/rfc7724/ballot/ > > I can go back to the email surrounding the DHCPv6 Active Leasequery > draft and try to pull that together into something longer, but > essentially it is going to say pretty much what you have summarized > at the above URL. Hmm, it's too bad nothing has been documented on this, can we fix that for future draft references? >> >> 2. The Security Considerations section says not to use Authentication >> from RFC3316. SHould authentication instead be done within TLS or how >> will the session be authenticated. Did I miss something? I'm not >> finding the term authentication elsewhere in the draft and can infer >> things, but wanted to make sure since nothing is stated explicitly. >> > > Interesting point. Yes, if you care about authentication you > should use TLS. And the discussion on authentication in TLS > is in Section 9.1 of the DHCPv6 Active Leasequery draft, RFC > 7653. That section is not otherwise referenced here in the > failover draft. I will add the following to the end of the > Security Considerations section, immediately after: > >>> Authentication for DHCPv6 messages [RFC3315 ] MUST NOT be used to >>> attempt to secure transmission of the messages described in this >>> document. > > > "If authentication is desired, TLS SHOULD be employed > as described in Sections 8.2 and 9.1 of [RFC7653] ." Thank you. > > Thanks for catching this! > > Regards -- Kim > > > > > -- Best regards, Kathleen From nobody Thu Feb 2 12:22:41 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949F812954A; Thu, 2 Feb 2017 12:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 YXIYCTKdwmrh; Thu, 2 Feb 2017 12:22:23 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B1E1294FB; Thu, 2 Feb 2017 12:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4739; q=dns/txt; s=iport; t=1486066942; x=1487276542; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=iUYhU0CSSoBb2hKfuhZml33sgyErwnPE0CZJ9KyH+u4=; b=GSejmRBDJw3okGhDLwC3Lg79DKUONFUvJtjEtWfpDr8Rd7GRssnkVyNu t4aN7Ug3rbi6FBp0JK0OhSWWxiKYLw148RCp4Wk0dWEGri4rA3xnMAatP OYjINqsthve1EzMpfST0l4Fxr4ldH33q8KxGovabrYtbOjxKEZT9IF/6E k=; X-IronPort-AV: E=Sophos;i="5.33,326,1477958400"; d="scan'208";a="379170464" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2017 20:22:22 +0000 Received: from [161.44.67.129] ([161.44.67.129]) (authenticated bits=0) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v12KMLnh031703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2017 20:22:21 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: kkinnear In-Reply-To: Date: Thu, 2 Feb 2017 15:22:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148589004659.5913.10170408064364078877.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) X-Authenticated-User: kkinnear@cisco.com Archived-At: Cc: Bernie Volz , "" , The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, "" , Kim Kinnear Subject: Re: [dhcwg] Kathleen Moriarty's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 20:22:24 -0000 Kathleen, See my response below, inline... > On Feb 2, 2017, at 3:07 PM, Kathleen Moriarty = wrote: >=20 > Hi Kim, >=20 > Thanks for your response, inline. >=20 > On Tue, Jan 31, 2017 at 4:46 PM, kkinnear wrote: >> Kathleen, >>=20 >> Thanks for your comments. My responses are indented below. >>=20 >>> On Jan 31, 2017, at 2:14 PM, Kathleen Moriarty = wrote: >>>=20 >>> Kathleen Moriarty has entered the following ballot position for >>> draft-ietf-dhc-dhcpv6-failover-protocol-04: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> I have 2 questions that I would like to chat about and should be = easy >>> enough to resolve. >>>=20 >>> 1. I know we've discussed in the past why there is no MUST for TLS = and it >>> having to do with DHCPv6 use on private networks or isolated. Is = there >>> text in one of the more recent RFCs that covers this explanation = that can >>> be cited? I'd like to make sure that's enough too. >>=20 >> To the best of my knowledge the justifications for both a = secure >> and an insecure mode have been kept out of the RFC's = themselves, >> and are scattered over a variety of issues raised for = different >> drafts. A pretty succinct summary came from you for the = DHCPv4 >> Active Leasequery draft (the bottom of this page): >>=20 >> https://datatracker.ietf.org/doc/rfc7724/ballot/ = >>=20 >> I can go back to the email surrounding the DHCPv6 Active = Leasequery >> draft and try to pull that together into something longer, but >> essentially it is going to say pretty much what you have = summarized >> at the above URL. >=20 > Hmm, it's too bad nothing has been documented on this, can we fix that > for future draft references? >=20 Subsequent to our discussion, I have added the following to the Security Considerations section at the behest of Ben Campbell: DHCPv6 failover can operate in secure or insecure mode. Secure mode (using TLS) would be indicated when the TCP connection between failover partners is open to external monitoring or interception. Insecure mode should only be used when the TCP connection between failover partners remains within [a] set of protected systems. = Details of such protections are beyond the scope of this document. Failover servers MUST use the approach documented in Section=C2=A09.1 of = [RFC7653] to decide to use or not to use TLS when connecting with the failover partner. The threats created by using failover directly mirror those from using DHCPv6 itself: information leakage through monitoring, and disruption of address assignment and configuration. Monitoring the failover TCP connection provides no additional data beyond that available from monitoring the interactions between DHCPv6 clients and the DHCPv6 server. Likewise, manipulating the data flow between failover servers provides no additional opportunities to disrupt address assignment and configuration beyond that provided by acting as a counterfeit DHCP server. Protection from both threats is easier than with basic DHCPv6, as only a single TCP connection needs to be protected. Either use secure mode to protect that TCP connection or ensure that it can only exist with a set of protected systems. I hope that helps. Here is the entire Security Considerations section in the -05 version of the draft (which is maybe 90 minutes old): = https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-05#pag= e-88 = I also just noticed a typo in the first new paragraph which I will fix at the next opportunity. Thanks -- Kim From nobody Thu Feb 2 13:41:41 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B7B1294B6; Thu, 2 Feb 2017 13:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EuMQKb1kAXev; Thu, 2 Feb 2017 13:41:38 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A14E129431; Thu, 2 Feb 2017 13:41:38 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id k15so1647620qtg.3; Thu, 02 Feb 2017 13:41:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qu9kX7QNQIjyhQ18SdWYAqeIeK93EjSTWEWVm5OrT0E=; b=mkPUsvABUDr3wLXuV/EvSWM4IeR0TT9b4JpqmVnY1boz6Lr397L9N6ZvPykCIX7/+h vboDhpFE5yOuXn65/931mRY6erOzXIUoQAJsIn7BNtMiDSqv2/oB3V8KQcNMDa4NZ/hY ltH+60bxH07eGXvls6oV09D16afcSP8+nZZkAcWjqwVWsFdIyW3XNCv6umTqHr98iI3p N1+oY9paTdcAyxvTYLgjmo4d5kmMlm4CuJ6jftqXBvNJJLtY/QLauPh7Bjk+5QTQIzBh fr/rEzrHoaFDBBWiBqi/w7Gs0/KHaTXz6LtSbJ9YKlqfPqoKkJh3RR2b7JxfUXCh/hz4 +VrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qu9kX7QNQIjyhQ18SdWYAqeIeK93EjSTWEWVm5OrT0E=; b=g4rDk+WdWKdi5jJdEfIqJEhmQnsZPUf1uzgMYUPZTbof0ioA1h+gvhFgZbc4OnJmqU Bju0725Hvwl4h0tj9dXKmBZ2Aax8OkBPc9mOwDHFlNLaVyfllYFGYpMBh/3EtRqInzti kLrH7rWUVK260DhHIczHIWJz38LLCLa6TlN9tXqsrNJfpBLyg0jlQj0RkCtqM6NpYLUQ fGXyTS/O7treF4x0Gm+dG0cU3RO6kuTvADMECoJJWZRFhSE1OQwLNdzMdyEkyCz6zKaE EbYuRJfNbjn1rCr/kcGeL+2KmzqT+oe+PSgDxBtES3IRQ45rWC6hR6nOUqp7P8vnM7F/ IEcw== X-Gm-Message-State: AIkVDXL7OzGMmMpkLS5+9Tnmteuz33+xEM8723g78uycZ4017ncV/K3NfU8kI9ZLLnxBiQ/3tPupyDu+r13YbQ== X-Received: by 10.237.41.36 with SMTP id s33mr9812196qtd.139.1486071697404; Thu, 02 Feb 2017 13:41:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Thu, 2 Feb 2017 13:41:37 -0800 (PST) In-Reply-To: References: <148589004659.5913.10170408064364078877.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 2 Feb 2017 16:41:37 -0500 Message-ID: To: kkinnear Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" , "" , The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, Bernie Volz Subject: Re: [dhcwg] Kathleen Moriarty's No Objection on draft-ietf-dhc-dhcpv6-failover-protocol-04: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 21:41:40 -0000 On Thu, Feb 2, 2017 at 3:22 PM, kkinnear wrote: > Kathleen, > > See my response below, inline... > >> On Feb 2, 2017, at 3:07 PM, Kathleen Moriarty wrote: >> >> Hi Kim, >> >> Thanks for your response, inline. >> >> On Tue, Jan 31, 2017 at 4:46 PM, kkinnear wrote: >>> Kathleen, >>> >>> Thanks for your comments. My responses are indented below. >>> >>>> On Jan 31, 2017, at 2:14 PM, Kathleen Moriarty wrote: >>>> >>>> Kathleen Moriarty has entered the following ballot position for >>>> draft-ietf-dhc-dhcpv6-failover-protocol-04: No Objection >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I have 2 questions that I would like to chat about and should be easy >>>> enough to resolve. >>>> >>>> 1. I know we've discussed in the past why there is no MUST for TLS and it >>>> having to do with DHCPv6 use on private networks or isolated. Is there >>>> text in one of the more recent RFCs that covers this explanation that can >>>> be cited? I'd like to make sure that's enough too. >>> >>> To the best of my knowledge the justifications for both a secure >>> and an insecure mode have been kept out of the RFC's themselves, >>> and are scattered over a variety of issues raised for different >>> drafts. A pretty succinct summary came from you for the DHCPv4 >>> Active Leasequery draft (the bottom of this page): >>> >>> https://datatracker.ietf.org/doc/rfc7724/ballot/ >>> >>> I can go back to the email surrounding the DHCPv6 Active Leasequery >>> draft and try to pull that together into something longer, but >>> essentially it is going to say pretty much what you have summarized >>> at the above URL. >> >> Hmm, it's too bad nothing has been documented on this, can we fix that >> for future draft references? >> > > Subsequent to our discussion, I have added the following to > the Security Considerations section at the behest of Ben > Campbell: > > DHCPv6 failover can operate in secure or insecure mode. Secure mode > (using TLS) would be indicated when the TCP connection between > failover partners is open to external monitoring or interception. > Insecure mode should only be used when the TCP connection between > failover partners remains within [a] set of protected systems. Details > of such protections are beyond the scope of this document. Failover > servers MUST use the approach documented in Section 9.1 of [RFC7653] > to decide to use or not to use TLS when connecting with the failover > partner. > > The threats created by using failover directly mirror those from > using DHCPv6 itself: information leakage through monitoring, and > disruption of address assignment and configuration. Monitoring the > failover TCP connection provides no additional data beyond that > available from monitoring the interactions between DHCPv6 clients and > the DHCPv6 server. Likewise, manipulating the data flow between > failover servers provides no additional opportunities to disrupt > address assignment and configuration beyond that provided by acting > as a counterfeit DHCP server. Protection from both threats is easier > than with basic DHCPv6, as only a single TCP connection needs to be > protected. Either use secure mode to protect that TCP connection or > ensure that it can only exist with a set of protected systems. > > I hope that helps. Yes, thank you. This is very helpful and can be referenced in future drafts. Best regards, Kathleen > > Here is the entire Security Considerations section in the > -05 version of the draft (which is maybe 90 minutes old): > > https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-05#page-88 > > I also just noticed a typo in the first new paragraph which I > will fix at the next opportunity. > > Thanks -- Kim > > > > > > > > -- Best regards, Kathleen From nobody Fri Feb 3 13:21:11 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E78A12955A; Fri, 3 Feb 2017 13:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LoeMQ0Dpb9T7; Fri, 3 Feb 2017 13:21:04 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264AE12955C; Fri, 3 Feb 2017 13:21:04 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id f144so2285433pfa.2; Fri, 03 Feb 2017 13:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pfEJMlRY2Mcj5WxL+uAuO8hZF+cfpD6oPUzeg7QQTcs=; b=Hcj7bvp4waOEWZUbFWL60bH1WFXGU/MPJ9IqLyK/YjQWad/k6y+UYDbzOmS/3EmHko f7CxrAYNDSNcgppN955zmiegOUqRdZfIQwp5Yi/drzuxT7zzXKpAoEcWKcHi3Z3JrLZ0 g4Mu5dhmRjsERiFTc4icgItgJ5qaen9aC/BNcHKG855a0H3LeWDJpj/NHKuY0WIiWCd0 d5HmBcklHy/UqMfPRMc2+CwPFJvSgP1UVuiUCJE5hq4RAatpa3uPxJT8S1Bb1p13Ghbt t1gPYHyeLA+P7YQK4m9Hc3Y50QBzfFqCjKo26UsYPwfnwdADL9oi37nUjoh99N+BkrTz c2fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pfEJMlRY2Mcj5WxL+uAuO8hZF+cfpD6oPUzeg7QQTcs=; b=iRlZXno8e7owqvzKtKuUUNByk02MCbE3O9+mvEgtjEP4tkHV5mDsg9qUYgEzY7YbDC p7nn0xHdL0AMjuaAe+1ZATl5AgNDzBKXHOfFbgEaqLHSZrYjcWeOtnatjlk3oeCOsGBk +nTONJEmLdb4Hp/J+4xdVPA9VZYGmSGITq5WZ9XgrkJhOMr5CSUgZOGaiIZEoS+NEc5n L5UMaFUhvVZlv5qhPsUd68NYCK6pEnuAazDP2pjlxjiCI2WRg5mWOl0D7/m6FA+fuo0O mG73zt0UVyTNTrYupFXBadzOASpEBHS8O7LMKbgNN5qdfi/s7k42/+4lvbV6A3Dn/o+R 25xw== X-Gm-Message-State: AIkVDXL/HRrPiNDE/xNAPpfZt1MpYN4KSOzrNiFIRs4zpIAAS9Pd0hGXwf6/D1Tg9lz1Tw== X-Received: by 10.84.173.4 with SMTP id o4mr24172926plb.106.1486156863695; Fri, 03 Feb 2017 13:21:03 -0800 (PST) Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id c204sm69321855pfb.51.2017.02.03.13.21.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 13:21:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "jouni.nospam" In-Reply-To: Date: Fri, 3 Feb 2017 13:21:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <28EBB7A8-92FB-4308-9413-CFF7F449A2AA@gmail.com> References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Bernie Volz , "int-dir@ietf.org" , Ted Lemon , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" Subject: Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:21:05 -0000 Suresh, > On Feb 1, 2017, at 11:56 AM, Suresh Krishnan = wrote: >=20 > Hi Jouni, > Thanks for the review.=20 >=20 >> On Jan 27, 2017, at 3:20 PM, jouni.nospam = wrote: >>=20 >>=20 >>> On Jan 26, 2017, at 11:27 AM, Ted Lemon wrote: >>>=20 >>> On Jan 26, 2017, at 1:58 PM, jouni.nospam = wrote: >>>> No. But in this case there are pieces of text that change specific = places in the original document from SHOULDs to MUSTs, musts to MUSTs, = and adds few pieces of new stuff, etc. Now how that in not updating? = Changes or =E2=80=9Cextensions=E2=80=9D like that would be nice to = follow from the base document. >>>=20 >>> Okay, I see your point. But suppose the document were changed so = that rather than "updating" the document as you suggest, it simply = referenced the sections in question and then made the SHOULDs into MUSTs = that way? Wouldn't that mean "implementations of this extension MUST," = and wouldn't that be perfectly reasonable? >>>=20 >>=20 >> I would still argue that it updates specifically if the document here = is going to be standards track. If this document here would be more of a = recommendation e.g., BCP I would be fine without the =E2=80=9Cupdating=E2=80= =9D part (as I remember the MUST for IPsec in RFC3315bis was not = endorsed by the WG). >=20 > I think the other two items in your review need to be fixed. But I = have a slightly different take on this specific issue. In my view this = document needs to stay on Standards track, and it should be made clear = that it is an (optional) extension to RFC3315. This allows people who = have implemented encryption for server-relay communications to claim = compliance to RFC3315 and this document. For RFC3315bis, I think it = should be discussed in the WG whether to mandate encryption or not as = there are backward compatibility related considerations to be made. I guess that works for me. In this case IMHO = *-dhc-relay-server-security-* would be more of a profile for RFC3315 = IPsec based security. I would find that useful. Can you explain what is the real difference between extends vs. updates? - Jouni >=20 > Regards > Suresh >=20 From nobody Mon Feb 6 14:09:51 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8B812947D; Mon, 6 Feb 2017 14:09:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148641899015.18910.12808171519982854350.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 14:09:50 -0800 Archived-At: Cc: dhc-chairs@ietf.org, tomasz.mrugalski@eti.pg.gda.pl, dhcwg@ietf.org Subject: [dhcwg] dhc - New Meeting Session Request for IETF 98 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 22:09:50 -0000 A new meeting session request has just been submitted by Tomek Mrugalski, a Chair of the dhc working group. --------------------------------------------------------- Working Group Name: Dynamic Host Configuration Area Name: Internet Area Session Requester: Tomek Mrugalski Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: v6ops 6man softwire homenet Second Priority: dane sunset4 dnssd dnsop intarea People who must be present: Suresh Krishnan Bernie Volz Tomek Mrugalski Resources Requested: Meetecho support in room Special Requests: We got Friday afternoon slot in Seoul. We'd like to get a different one this time if possible. --------------------------------------------------------- From nobody Tue Feb 7 07:45:36 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EA3129422; Tue, 7 Feb 2017 07:45:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148648233413.16188.1096005061921603374.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2017 07:45:34 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-server-security-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 15:45:34 -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 of the IETF. Title : Security of Messages Exchanged Between Servers and Relay Agents Authors : Bernie Volz Yogendra Pal Filename : draft-ietf-dhc-relay-server-security-03.txt Pages : 8 Date : 2017-02-07 Abstract: The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents, but does not require encryption. And, with recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay to relay and relay to server communication for DHCPv6 and relay to server communication for DHCPv4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-relay-server-security-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-relay-server-security-03 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 Feb 7 07:50:41 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234F0129C9C for ; Tue, 7 Feb 2017 07:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 CP-EMTarQ_eR for ; Tue, 7 Feb 2017 07:50:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895561279EB for ; Tue, 7 Feb 2017 07:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2428; q=dns/txt; s=iport; t=1486482634; x=1487692234; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nzfIi6qibazMGKKido2bQ7S0BBJEPI3GclNRxHuQKaI=; b=kamonF9THQbEVvBGnVuRHICpoN++t4u0pmxUFFo9SX6AeIM5kuDfHI65 uR/htpH2I+XaoPmchn93ad+/kNSgXMEOUBbmPTveAw13VgEqiUyKlWALq QV02ZyxgLfbPu+RF4ywPUW1MmQFB09NxlWiTPcs/0q4Cy+LWkKvDAAfKB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQCF7JlY/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVmSD5U2ggwfDYV2AoJSPxgBAgEBAQEBAQFiHQuEaQE?= =?us-ascii?q?BAQQBATg0FwQCAQgRBAEBHwkHJwsUCQgCBBMIiWsOshCLWgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2LO4MXgSABAQVIhTMFm2sBhmmLG4IEU4REiXGIKYplAR84fk8?= =?us-ascii?q?VGCSGQnUBhkaBIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="205772382" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2017 15:50:05 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v17Fo4ok020356 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Feb 2017 15:50:04 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Feb 2017 09:50:04 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 7 Feb 2017 09:50:04 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-server-security-03.txt Thread-Index: AQHSgVk+uhY2BNPi5ESs9BBChIwpqaFdr+Yw Date: Tue, 7 Feb 2017 15:50:04 +0000 Message-ID: <1087f7cb6aad4840bdbe17757b8579c8@XCH-ALN-003.cisco.com> References: <148648233413.16188.1096005061921603374.idtracker@ietfa.amsl.com> In-Reply-To: <148648233413.16188.1096005061921603374.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-server-security-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 15:50:36 -0000 Hi: This update is based on the Int-Dir review (https://www.ietf.org/iesg/direc= torate/intarea.html) and fixes a few nits and adjusts the text in section = 3 (first paragraphs). For more details, see https://www.ietf.org/mail-archive/web/dhcwg/current/m= sg17859.html and the discussion related to this review. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Tuesday, February 07, 2017 10:46 AM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-server-security-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : Security of Messages Exchanged Between Servers an= d Relay Agents Authors : Bernie Volz Yogendra Pal Filename : draft-ietf-dhc-relay-server-security-03.txt Pages : 8 Date : 2017-02-07 Abstract: The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents, but does not require encryption. And, with recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay to relay and relay to server communication for DHCPv6 and relay to server communication for DHCPv4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-relay-server-security-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-server-security-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Tue Feb 7 08:25:34 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BBA129D0F for ; Tue, 7 Feb 2017 08:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 lz9iJbco4E12 for ; Tue, 7 Feb 2017 08:25:30 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48573129D02 for ; Tue, 7 Feb 2017 08:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1645; q=dns/txt; s=iport; t=1486484730; x=1487694330; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ScW0US0rQvV7WDtNmIFiHnAsMKahtF1z30oqsHik1VE=; b=HICe4Qnco0nowPhxmJQylvO619f3jAC9CElGh3HSn7k82tBOuDCII4K1 03tf+5WJDyoptQMjfGN8kUg3P+GXrB1qmoyRoakAoxAFn30rRn/BzRNoh 8huXYW5fhjj3IrQGOGxMU5ZB00G1ySM/l4KUvidSXPjUpeT7Eg4J89T4E w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQCF9JlY/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVmSD5U2ggwfC4V4AoJSPxgBAgEBAQEBAQFiHQuEaQE?= =?us-ascii?q?BBgE4NBcGARkEAQEfCS4LFAkJAQQTCIlrDp93kiaLTgEBAQEBAQQBAQEBAQEBH?= =?us-ascii?q?AWLO4E8AYh8BZtrAYFMhR2LG4IEhReJcZMOAR84OkRPFTyGQnWHaIEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="203961681" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Feb 2017 16:25:02 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v17GP2OI022215 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Feb 2017 16:25:02 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Feb 2017 10:25:01 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 7 Feb 2017 10:25:01 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Reminder for IETF'98 (Chicago) DHC WG Session Agenda Requests Thread-Index: AdKBXmsUQsNQZAr+S6C7Z2fR8Ylu8A== Date: Tue, 7 Feb 2017 16:25:01 +0000 Message-ID: <4572354606504e4a8be1abec244bf13d@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Reminder for IETF'98 (Chicago) DHC WG Session Agenda Requests X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 16:25:32 -0000 Hi: The current draft agenda is at https://github.com/dhcwg/wg/wiki/IETF-98-(Ch= icago)-DHC-WG-Agenda. Based on the current requests, Tomek and I decided on and submitted a reque= st a 1 hour session for Chicago (IETF-98). If there are additional requests for time, please let us know ASAP. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Tuesday, January 24, 2017 7:49 AM To: dhcwg@ietf.org Subject: [dhcwg] Reminder for IETF'98 (Chicago) DHC WG Session Agenda Reque= sts - by January 31, 2017! Hi, This is a remainder for people who would like to present in Chicago to subm= it slot request. The meeting still 2 months away, so we don't expect the re= quests to be super detailed. Nevertheless Bernie and I need it to assess ho= w much time we need for the DHC meeting. This is not a bookkeeping exercise= only. We're supposed to justify any time we request. Given that Seoul meet= ing took only 40 minutes and we have received only 2 slots (with one of the= m being a recurring one - dhcpv6bis), we do not have enough presentations t= o get a long slot. In fact Bernie and I discussed whether we need to have a meeting in Chicago= at all. So far we're leaning towards requesting a very small slot (30 mins= ? 1h?), but we haven't made any decisions yet. This means that if you want = to present something, but won't express your intent soon, you'll likely not= get a slot later. Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Feb 8 13:38:05 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C401295D2 for ; Wed, 8 Feb 2017 13:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uAklsL6_I1fm for ; Wed, 8 Feb 2017 13:38:02 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3F3129501 for ; Wed, 8 Feb 2017 13:38:01 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id w20so173681494qtb.1 for ; Wed, 08 Feb 2017 13:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZeiRFwJGdwPOl+v6s5ijQXEu3BkowGlk8iqlK8pEOMk=; b=iga/lnGZJu/p/KgFTwIY7/w/eBf4hECmL6XxlerJ9EA0peypxgNSOCkfaXnyarDuNu sFZl+s+n/EBfvcCQICcAksoAKD0eXrASaXyLRsm9yTKzesTE6rkZk4Ea4wz14m7NevqD tS/M2f2YI6x8jsojmvFsS3c12NuTKx7J69T+R2E2wbVBDCFrR9DdKLX4LaK42ylZcB9A BcM0blx41Y4ZMzrd6R0n9gCI6tDAN/dSPyOVprbaKpAQNZFAVdGeTRk8WcOOmNGqrBrI zhwjlhuEHMeU33iwf4CftDkgMNspyotQPVGIlYttlHuUrFiKstUHbI26mKZFl8+qlf2n kNNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZeiRFwJGdwPOl+v6s5ijQXEu3BkowGlk8iqlK8pEOMk=; b=nIK8bBIJ8mYj5trsdGXyWYBpMHnStnnqIsYX6QJRIK8otXrP8VZvvwB/gdgsJp7Z2R T4WHEa7NMPORUAxFUqzl9sTFdGPXy7rYVgq+ZwMqjXl/T1ByqWBpQBp+JGUOYNLkL2GP wQiEQbndJIU6lP3/K5Au1+WROVAf5bx0o43rbyqewjkzAsabzFwAvjN7JK8dLmH3VHoR 0rcY0Zx2MnYIeZkQmgL/O3N4MZ3PkzNtDrOWjqGu4CUPJDG0W4zetDEZ2H1GlcPbDTXE jp3IiOGDCeoT0CmcWSO7NySo9wZnkg817cr2mSn4BOcrLUkDTLexplm9P6u5WRUfDDBw WXYw== X-Gm-Message-State: AMke39k4X25hzqiDEYWBQKRrXoNX4DmRx5BEU7pORyWvvpUJC7n11jvT+5y5eso7QMuz6RAopySjfCVFCOohjQ== X-Received: by 10.200.2.8 with SMTP id k8mr21014145qtg.163.1486589880590; Wed, 08 Feb 2017 13:38:00 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Wed, 8 Feb 2017 13:38:00 -0800 (PST) In-Reply-To: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 8 Feb 2017 13:38:00 -0800 X-Google-Sender-Auth: Fhw4xqCHilAJAtbxbDW95dqw8IM Message-ID: To: Lishan Li Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:38:04 -0000 At Mon, 16 Jan 2017 17:10:26 +0800, Lishan Li wrote: > We have submitted a new version of secure DHCPv6. Thanks a lot for Bernie's > valuable comment. I apologize for having been inactive on this draft, especially despite being listed as a coauthor. I've finally found time to take a closer look at it. I see the 20 version has been improved a lot; it's much more readable than (some of the) older versions and many of the technical questions I raised before seem to be addressed. I personally think we still need to discuss and address some more technical details, but IMO this version is now much closer to WGLC. ...with one big reservation: I'd very much like to see at least one attempt of implementing the spec. This is a quite complicated protocol specification, and no matter how hard we review the paper spec, I'm quite sure that an actual implementation attempt will find many more unclear points or protocol defects. Although I understand that's not a requirement for a WGLC or even for an RFC (the spirit of "believing in running code" has been the thing of past at the IETF, sadly) but I still hope we won't end up shipping a protocol spec with full of defects mainly because there is not even an attempt of implementing it before publishing it. Specific comments on the 20 version follow. There is one thing that I guess needs broader attention, so I'm noting it here: I think we need more discussion on the meaning and justification of "Non-SigAlg" and "Non-EncryAlg" (especially the latter). See below for more details. - general: it's still not clear to me how we use this mechanism for Reconfigure. - Section 1 [...] Such communications are already protected using the mechanism described in section 21.1 in [RFC3315]. Perhaps a better reference today would be draft-ietf-dhc-relay-server-security. - Section 1 [...] The Algorithm, Certificate, Signature, and Increasing-number options are used for authentication. The Encryption-Query message, Encryption- Response message, Encrypted-message option and Encryption-Key-Tag option are used for encryption. I suspect this is not 100% accurate. Except for the signature option, everything can also be used for (or related to) encryption. - Section 5.3 [...] The same client and server SHOULD use the same algorithm in a single communication session. Shouldn't this be a MUST? Especially now that the client and the server negotiate and fix a specific set of algorithms initially, I don't see any possibility for an exception to this requirement. - Section 5.3 The sender can offer a set of algorithms, and then the receiver selects one algorithm for the future communication. s/sender/client/ and s/receiver/server/. Only the client offers an algorithm set using the algorithm option. - Section 5.5: s/The One/One/ The One feasible environment in an early deployment stage would be enterprise networks. - Section 5.5 In enterprise networks, the client is manually pre-configured with the trusted servers' public key and the server is also manually pre- configured with the trusted clients' public keys. I suggest s/is (also) manually/can (also) be manually/ since manual configuration wouldn't be the absolute only option. - Section 6 And then the client first checks acknowledged hash, signature and encryption algorithms that the server supports. If the hash algorithm field is zero, then it indicates that the hash algorithm is fixed according to the corresponding signature algorithm. The client also uses the acknowledged algorithms in the return messages. It's not clear to me from this text how the client checks the algorithms. By examining the certification option for the signature/encryption algorithms and examining the signature option for the hash ID? If so, I think it should be clearly described. I'd note that the signature ID in the certificate must be equal to the signature ID of the signature option. And, generalizing this, what if the client doesn't support these algorithms? (This shouldn't happen as long as the server handles the algorithm option correctly, so this is basically a bug of the server implementation). The description of zero hash algorithm field seems to suggest the signature and hash algorithms are tightly related in practice. So it may be better to define the algorithm option so that signature/hash algorithms are listed as pairs. - Section 6: s/return/subsequent/ [...] The client also uses the acknowledged algorithms in the return messages. - Section 6 The first DHCPv6 message sent from the client to the server, such as Solicit message, MUST contain the Certificate option, Signature option and Increasing-number option for client authentication.[...] [...] One and only one Increasing-number option SHOULD be contained, Isn't there a MUST vs SHOULD conflict here? - Section 6 [...] In this document, it is assumed that the client uses only one certificate for the encrypted DHCPv6 configuration. So, the corresponding private key is used for decryption. I'm not sure if this is okay. And, in fact, Section 11 talks about a case where multiple key pairs (so multiple certificates) are used: If the client tries more than one cert for client authentication, the server can easily get a client that implements this to enumerate its entire cert list and probably learn a lot about a client that way. Perhaps this is intended to handle encrypted Reconfigure? If that's the only reason for this limitation, I think we should address the reconfigure case in some other way and keep the general specification more flexible. - Section 7 [...] If it is the target server, according to the Encryption-Key-Tag option, the server identifies the used public/ private key pair and decrypts the Encrypted-message option using the corresponding private key. The key tag is not necessarily unique for different public keys (so different key pairs), even if it should normally be unique in practice. If multiple public keys share the same tag value, the server MUST try all corresponding key pairs. Also, since the key tag option isn't covered by a signature, it may have been forged by an intermediate attacker. We may want to describe what the server should do in such a case (just discarding it is probably okay as it's forged anyway, but the server could also try all possible keys just in case the key tag is the only forged field). - Section 7 The server validates the client's certificate through the local pre- configured trusted certificates list. I'm not sure if this paragraph covers the "opportunistic encryption" mode, i.e, when the server doesn't know the certificate but chooses to use it for encryption only. (I'm assuming our intent is to support such mode, right?). - Section 7 To provide the replay protection, the Increasing-number option can be contained in the encrypted DHCPv6 message. Shouldn't this be either SHOULD or MUST to be consistent with other part of this spec? (see also the possible SHOULD vs MUST conflict commented above). - Section 9.1 [...] And the client can forget the increasing number information after the transaction is finished. The client's initial locally stored increasing number is set to zero. I'm not sure if I understand it and I'm not sure if it's okay whatever it means...does this mean the server can (or always does?) reset the increasing number to 0 for messages it sends to the server at the beginning of a new DHCPv6 session? Doesn't it lead to an easy replay attack? Or is the assumption that the server first sends an error and the client will resend the message with an adjusted increasing number? - Section 10.1.1 The mandatory encryption algorithms MUST be included. Which algorithm is it? - Section 10.1.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EA-id | SA-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Certificate . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This seems to assume a single certificate (which I assume means a single public key) can be used for both encryption and signature. Is my understanding correct? If so, can we always assume that? - Section 10.1.2 It should be noticed that the scenario where the values of EA-id and SA-id are both 0 makes no sense and the client MUST discard a message with such values. The 0 EA-id/SA-id values are not described earlier in this document. I think it should explicitly define its semantics before this text (perhaps in Section 10.1.1). And, from the description of Section 12: Non-SigAlg | 0x00 | this document Non-EncryAlg | 0x00 | this document I guess it means the signature is (effectively) not provided and the message is (effectively) not encrypted, respectively. If my understanding is correct, is it okay to allow that, especially about encryption? I vaguely recall a discussion about someone hoping to introduce a non-encryption mode, but I thought we rejected the idea because it would be against the "always encrypt" consensus. - Section 10.1.5 encryption key tag A variable length field containing the encryption key tag sent from the client to server to identify the used public/private key pair. The encryption key tag is calculated from the public key data, like fingerprint of a specific public key. How to generate the encryption key tag adopts the method define in Appendix B in [RFC4034] and section 5.5 in [RFC6840]. The data of the public key is used as input of the generation function. If we derive the tag calculation from RFC4034, the length is not variable: it's fixed to 16 bits. Also, I don't think we have to mention RFC6840 section 5.5. We'd only use the method described in Appendix B of RFC4034 for algorithms other than type 1. And, although it may be quite straightforward, I don't think this description is enough to actually calculate the tag value for a given public key. We should provide some more specific here. - Section 11 [RFC6273] has analyzed possible threats to the hash algorithms used in SEND. Since Secure DHCPv6 defined in this document uses the same hash algorithms in similar way to SEND, analysis results could be applied as well: [...] Does this matter even when the hash value is in an encrypted message? - Section 11 I think we should also discuss a few more security issues in this section: - Since the algorithm option isn't protected by a signature, the list can be forged without detection, which can lead to a downgrade attack. - Likewise, since the Encryption-Key-Tag Option isn't protected, an attacker that can intercept the message can forge the value without detection (see also the relevant comment on Section 7). - Section 12 Hash Algorithm for Secure DHCPv6. The values in this table are 8-bit unsigned integers. Shouldn't this be 16-bit? It's defined as an 16-bit value for the HA-id field of various options. Same for the signature algorithm and encryption algorithm. -- JINMEI, Tatuya From nobody Wed Feb 8 13:46:58 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA85D1293FF for ; Wed, 8 Feb 2017 13:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 CFjtsW5vZ-sa for ; Wed, 8 Feb 2017 13:46:55 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8081293FB for ; Wed, 8 Feb 2017 13:46:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HJAgCCkJtY/xUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBBgXGDUp8ukAqCD4IMhiICgm9BFgECAQEBAQEBAQNfKIRsARU?= =?us-ascii?q?PAVcSARUMAwYfAzQmAQQBDQ0aiVIBkmSSbIpdAYIpJgKLKAEBAQEGAQEBAQEBA?= =?us-ascii?q?SGBCIVFhiqDAhiDATGCMQWbcAGTdAGIcoYvkxMmAy86RE8Vhn6IZwGBCwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2HJAgCCkJtY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?BgXGDUp8ukAqCD4IMhiICgm9BFgECAQEBAQEBAQNfKIRsARUPAVcSARUMAwYfA?= =?us-ascii?q?zQmAQQBDQ0aiVIBkmSSbIpdAYIpJgKLKAEBAQEGAQEBAQEBASGBCIVFhiqDAhi?= =?us-ascii?q?DATGCMQWbcAGTdAGIcoYvkxMmAy86RE8Vhn6IZwGBCwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,348,1484024400"; d="scan'208";a="227333479" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Feb 2017 16:46:53 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2017 16:46:55 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 16:46:52 -0500 From: "Mudric, Dusan (Dusan)" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , Lishan Li Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQ== Date: Wed, 8 Feb 2017 21:46:49 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:46:57 -0000 Hi, Can DECLINE definition be extended beyond the DAD usage? I think DECLINE sh= ould be used every time DHCPV6 client decides not to assign the offered add= ress, for any reason, not just the address is duplicate. When receiving DEC= LINE, DHCPV6 server should be able to immediately make the same address ava= ilable in the address pool for the other clients. Regards, Dusan. From nobody Wed Feb 8 13:57:28 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFD41295FD for ; Wed, 8 Feb 2017 13:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 lv6r_wCxndef for ; Wed, 8 Feb 2017 13:57:26 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36FF128874 for ; Wed, 8 Feb 2017 13:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1346; q=dns/txt; s=iport; t=1486591045; x=1487800645; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fmvlvxrGt+Vi3Cu6qLGeSYubygEr+BuW4qjjGeqed0M=; b=PxC9/2+IuhYqFfy7CfyzL8TWlZKdZcI+8UVXY28dMUMWNvg5SjEoWVhn XQmXKat5aW3IHNV6JGc5BWKSZg6V200UX8lxp564GILojYmhg513b9uWC c+S4jf1XYlAlHcK6HJ2fU/4FTm0GE5pautCxDS6OD6whu1FWnWboiiPYO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQD9k5tY/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1KKCJIJiAyNKoIMHwuFeAKCbz8YAQIBAQEBAQEBYii?= =?us-ascii?q?EaQEBAQQBAR8BTAsMBAIBCBEEAQECAwsYAgMCIQYLFAkIAQEEAQ0FCIlUAxUOk?= =?us-ascii?q?l+dSQGCKYc5DYQKAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBCIozgTyBFYFtgxm?= =?us-ascii?q?CYgWbODgBjXiEEJEOhW2ER4heAR84OkRPFTyGQnWGQgeBKYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,348,1484006400"; d="scan'208";a="206416469" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2017 21:57:04 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v18Lv4J6022137 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Feb 2017 21:57:04 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 15:57:03 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Wed, 8 Feb 2017 15:57:03 -0600 From: "Bernie Volz (volz)" To: "Mudric, Dusan (Dusan)" , =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , Lishan Li Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQA Date: Wed, 8 Feb 2017 21:57:03 +0000 Message-ID: <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.56] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:57:27 -0000 Dusan: DECLINE is used after a REPLY, not after an ADVERTISE. A client has not been assigned an address until it receives the REPLY (at w= hich point it does DAD and may send a DECLINE). There is no mechanism for a client to indicate to a server "I don't want yo= ur Advertised address(es)", except by not proceeding to send a REQUEST. The server may have held the address "reserved" for a short period of time,= but does that really matter? IPv6 addresses are not in short supply. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mudric, Dusan (Dus= an) Sent: Wednesday, February 08, 2017 4:47 PM To: =1B$B?@L@C#:H=1B(B ; Lishan Li Cc: dhcwg Subject: [dhcwg] RFC3315 DECLINE definition Hi, Can DECLINE definition be extended beyond the DAD usage? I think DECLINE sh= ould be used every time DHCPV6 client decides not to assign the offered add= ress, for any reason, not just the address is duplicate. When receiving DEC= LINE, DHCPV6 server should be able to immediately make the same address ava= ilable in the address pool for the other clients. Regards, Dusan. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Feb 8 14:19:29 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEECE129EBB for ; Wed, 8 Feb 2017 14:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 pD7mcyO6UMma for ; Wed, 8 Feb 2017 14:19:26 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6630129EB3 for ; Wed, 8 Feb 2017 14:19:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GfAACKmJtY/yYyC4ddGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBBYYEJB4NSigiSCYgMixuCD4FJQyaFfAKCbz8YAQIBAQEBAQE?= =?us-ascii?q?BA18ogls9BgcvAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAxIPAUwLDAQCAQgNB?= =?us-ascii?q?AQBAQIDBgUYAgMCIREUCQgBAQQOBQgaiToDFQGScJJsil0BgikmAocRDYQKAQE?= =?us-ascii?q?BAQEBAQECAQEBAQEBAQEBAQEdgQiFRYRugTyBFYFtGIMBMYIxBZs4OAGGbIcLA?= =?us-ascii?q?YZniAiGL4VthEeIXx85OkRPFTyGQnWGQgeBKQGBCwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2GfAACKmJtY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?BYYEJB4NSigiSCYgMixuCD4FJQyaFfAKCbz8YAQIBAQEBAQEBA18ogls9BgcvA?= =?us-ascii?q?QEBAQEBAQEBAQEBARwCD0EBARgBAQEBAxIPAUwLDAQCAQgNBAQBAQIDBgUYAgM?= =?us-ascii?q?CIREUCQgBAQQOBQgaiToDFQGScJJsil0BgikmAocRDYQKAQEBAQEBAQECAQEBA?= =?us-ascii?q?QEBAQEBAQEdgQiFRYRugTyBFYFtGIMBMYIxBZs4OAGGbIcLAYZniAiGL4VthEe?= =?us-ascii?q?IXx85OkRPFTyGQnWGQgeBKQGBCwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,348,1484024400"; d="scan'208";a="189999738" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Feb 2017 17:19:22 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2017 17:19:22 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 17:19:22 -0500 From: "Mudric, Dusan (Dusan)" To: "Bernie Volz (volz)" Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iA= Date: Wed, 8 Feb 2017 22:19:20 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> In-Reply-To: <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 22:19:27 -0000 Hi Bernie, I am talking about DECLINE after REPLY. What I am proposing is to use DECL= INE for "I don't want your Advertised address(es)". I think this will be mu= ch cleaner then to let the server timeout the advertised addresses, which c= an take long. Thanks, Dusan -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, February 08, 2017 4:57 PM To: Mudric, Dusan (Dusan); =1B$B?@L@C#:H=1B(B; Lishan Li Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Dusan: DECLINE is used after a REPLY, not after an ADVERTISE. A client has not been assigned an address until it receives the REPLY (at w= hich point it does DAD and may send a DECLINE). There is no mechanism for a client to indicate to a server "I don't want yo= ur Advertised address(es)", except by not proceeding to send a REQUEST. The server may have held the address "reserved" for a short period of time,= but does that really matter? IPv6 addresses are not in short supply. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mudric, Dusan (Dus= an) Sent: Wednesday, February 08, 2017 4:47 PM To: =1B$B?@L@C#:H=1B(B ; Lishan Li Cc: dhcwg Subject: [dhcwg] RFC3315 DECLINE definition Hi, Can DECLINE definition be extended beyond the DAD usage? I think DECLINE sh= ould be used every time DHCPV6 client decides not to assign the offered add= ress, for any reason, not just the address is duplicate. When receiving DEC= LINE, DHCPV6 server should be able to immediately make the same address ava= ilable in the address pool for the other clients. Regards, Dusan. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dhcwg&d=3DDQIFJg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3DdSOZR4dOvOIFlrJUO0ra9EaHoccrAjAiWycX_Y4vnRQ&= s=3De5wK-WS09BIx0RKDTBE_iEdUlrK_bP6gv4TfQaMTPiU&e=3D=20 From nobody Wed Feb 8 14:28:34 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170DB12A03E for ; Wed, 8 Feb 2017 14:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 AsGVhyvk6NXv for ; Wed, 8 Feb 2017 14:28:31 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF0812A03D for ; Wed, 8 Feb 2017 14:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3467; q=dns/txt; s=iport; t=1486592911; x=1487802511; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WfMzONzcY4pBbjaOrs7ZL7aY6+EOCSqmzxtsPouUmKU=; b=BP24RetVmWE++gu3eIiDseLqlWKsG3bMuj6fr52OOp7L7N18Rfcvimtg 8YE+hixrdgEij4PG0sZl0xDlhfxYEM6GnpBsmMou0IT85usgS5G5ezxVt oX3G4UTh3BuvaCY2GTVld81T7qd12LY2GIn+6bvJZuRMMAZ/AwOWZfU3D U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQAcmptY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1KKCJIJiAyLG4IPggwmhXwCgm8/GAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQEEIQFMCwwEAgEIEQQBAQIDCxgCAwIhERQJCAEBBA4FCIlUAxWSZZ1JA?= =?us-ascii?q?YIphzkNhAoBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQiKM4E8gRWBbYMZgmIFmzg?= =?us-ascii?q?4AYZshwyEEIJXjjeFbYRHiF4BHzg6RE8VPIZCdYZCB4EpgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,348,1484006400"; d="scan'208";a="383256358" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2017 22:28:30 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v18MST8Q016557 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Feb 2017 22:28:30 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 16:28:29 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Wed, 8 Feb 2017 16:28:29 -0600 From: "Bernie Volz (volz)" To: "Mudric, Dusan (Dusan)" Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgA== Date: Wed, 8 Feb 2017 22:28:29 +0000 Message-ID: <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.56] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 22:28:33 -0000 I'm confused ... advertised vs assigned addresses. Once a Reply is received= , the address is assigned -- no longer advertised. DECLINE means that the address is in use. If the client DECLINEs it and jus= t makes it available immediately, the next client to get that address assig= ned and does DAD will also find a conflict ... so what=1B$B!G=1B(Bs the val= ue of that. Generally, declined addresses should not be used for a while (that is polic= y dependent) since it means some other device is using the address. I thought you were trying to say a Decline sent in response to an Advertise= would tell the server "I don't want those addresses". But that is not mean= ingful and why would a client even try to do that. Also, an Advertise is ju= st that -- and advertisement; it is not a commitment to assigned those addr= esses -- the client can only use the addresses in the Reply. (DHCPv4 is a b= it different in this respect -- the address in the Offer must be same as in= the Ack. DHCPv6 has no such hard requirement -- it usually is, but that's = not required.) - Bernie -----Original Message----- From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]=20 Sent: Wednesday, February 08, 2017 5:19 PM To: Bernie Volz (volz) Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Hi Bernie, I am talking about DECLINE after REPLY. What I am proposing is to use DECL= INE for "I don't want your Advertised address(es)". I think this will be mu= ch cleaner then to let the server timeout the advertised addresses, which c= an take long. Thanks, Dusan -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, February 08, 2017 4:57 PM To: Mudric, Dusan (Dusan); =1B$B?@L@C#:H=1B(B; Lishan Li Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Dusan: DECLINE is used after a REPLY, not after an ADVERTISE. A client has not been assigned an address until it receives the REPLY (at w= hich point it does DAD and may send a DECLINE). There is no mechanism for a client to indicate to a server "I don't want yo= ur Advertised address(es)", except by not proceeding to send a REQUEST. The server may have held the address "reserved" for a short period of time,= but does that really matter? IPv6 addresses are not in short supply. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mudric, Dusan (Dus= an) Sent: Wednesday, February 08, 2017 4:47 PM To: =1B$B?@L@C#:H=1B(B ; Lishan Li Cc: dhcwg Subject: [dhcwg] RFC3315 DECLINE definition Hi, Can DECLINE definition be extended beyond the DAD usage? I think DECLINE sh= ould be used every time DHCPV6 client decides not to assign the offered add= ress, for any reason, not just the address is duplicate. When receiving DEC= LINE, DHCPV6 server should be able to immediately make the same address ava= ilable in the address pool for the other clients. Regards, Dusan. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dhcwg&d=3DDQIFJg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3DdSOZR4dOvOIFlrJUO0ra9EaHoccrAjAiWycX_Y4vnRQ&= s=3De5wK-WS09BIx0RKDTBE_iEdUlrK_bP6gv4TfQaMTPiU&e=3D=20 From nobody Wed Feb 8 14:38:05 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE2E12A06C for ; Wed, 8 Feb 2017 14:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 2Gc8uE55b6QL for ; Wed, 8 Feb 2017 14:38:01 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E317012A06B for ; Wed, 8 Feb 2017 14:38:00 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GfAABjnZtY/yYyC4ddGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBBYYEJB4NSigiSCYgMixuCD4FJQyaFfAKCbz8YAQIBAQEBAQE?= =?us-ascii?q?BA18ogls9BgcvAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAxIPAUwLDAQCAQgNB?= =?us-ascii?q?AQBAQIDBgUYAgMCIREUCQgBAQQOBQgaiToDFQGSYJJsil0BgikmAocQDYQKAQE?= =?us-ascii?q?BAQEBAQECAQEBAQEBAQEBAQEdgQiFRYRugTyBFYFtGIMBMYIxBZs4OAGGbIcLA?= =?us-ascii?q?YZniAiGL4VthEeIXx85OkRPFTyGQnWGQgeBKQGBCwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2GfAABjnZtY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?BYYEJB4NSigiSCYgMixuCD4FJQyaFfAKCbz8YAQIBAQEBAQEBA18ogls9BgcvA?= =?us-ascii?q?QEBAQEBAQEBAQEBARwCD0EBARgBAQEBAxIPAUwLDAQCAQgNBAQBAQIDBgUYAgM?= =?us-ascii?q?CIREUCQgBAQQOBQgaiToDFQGSYJJsil0BgikmAocQDYQKAQEBAQEBAQECAQEBA?= =?us-ascii?q?QEBAQEBAQEdgQiFRYRugTyBFYFtGIMBMYIxBZs4OAGGbIcLAYZniAiGL4VthEe?= =?us-ascii?q?IXx85OkRPFTyGQnWGQgeBKQGBCwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,348,1484024400"; d="scan'208";a="190001019" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Feb 2017 17:37:57 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2017 17:37:56 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 17:37:56 -0500 From: "Mudric, Dusan (Dusan)" To: "Bernie Volz (volz)" Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQ Date: Wed, 8 Feb 2017 22:37:55 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> In-Reply-To: <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 22:38:03 -0000 Understand the concern. The client should be able to DECLINE addresses in b= oth ADVERTISE and REPLY. Receiving the REPLY does not mean that a unique ad= dress must be assigned to the interface. If a client DECLINEs the ADVERTISE= d or REPLIEd address, DHCPV6 server should be able to advertise another add= ress. The client should also be able to tell that is does not want another addres= s. For example, if RENEW/REBIND returns a new address, the client should be= able to DECLINE it. Regards, Dusan. -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, February 08, 2017 5:28 PM To: Mudric, Dusan (Dusan) Cc: dhcwg Subject: RE: RFC3315 DECLINE definition I'm confused ... advertised vs assigned addresses. Once a Reply is received= , the address is assigned -- no longer advertised. DECLINE means that the address is in use. If the client DECLINEs it and jus= t makes it available immediately, the next client to get that address assig= ned and does DAD will also find a conflict ... so what=1B$B!G=1B(Bs the val= ue of that. Generally, declined addresses should not be used for a while (that is polic= y dependent) since it means some other device is using the address. I thought you were trying to say a Decline sent in response to an Advertise= would tell the server "I don't want those addresses". But that is not mean= ingful and why would a client even try to do that. Also, an Advertise is ju= st that -- and advertisement; it is not a commitment to assigned those addr= esses -- the client can only use the addresses in the Reply. (DHCPv4 is a b= it different in this respect -- the address in the Offer must be same as in= the Ack. DHCPv6 has no such hard requirement -- it usually is, but that's = not required.) - Bernie -----Original Message----- From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]=20 Sent: Wednesday, February 08, 2017 5:19 PM To: Bernie Volz (volz) Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Hi Bernie, I am talking about DECLINE after REPLY. What I am proposing is to use DECL= INE for "I don't want your Advertised address(es)". I think this will be mu= ch cleaner then to let the server timeout the advertised addresses, which c= an take long. Thanks, Dusan -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, February 08, 2017 4:57 PM To: Mudric, Dusan (Dusan); =1B$B?@L@C#:H=1B(B; Lishan Li Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Dusan: DECLINE is used after a REPLY, not after an ADVERTISE. A client has not been assigned an address until it receives the REPLY (at w= hich point it does DAD and may send a DECLINE). There is no mechanism for a client to indicate to a server "I don't want yo= ur Advertised address(es)", except by not proceeding to send a REQUEST. The server may have held the address "reserved" for a short period of time,= but does that really matter? IPv6 addresses are not in short supply. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mudric, Dusan (Dus= an) Sent: Wednesday, February 08, 2017 4:47 PM To: =1B$B?@L@C#:H=1B(B ; Lishan Li Cc: dhcwg Subject: [dhcwg] RFC3315 DECLINE definition Hi, Can DECLINE definition be extended beyond the DAD usage? I think DECLINE sh= ould be used every time DHCPV6 client decides not to assign the offered add= ress, for any reason, not just the address is duplicate. When receiving DEC= LINE, DHCPV6 server should be able to immediately make the same address ava= ilable in the address pool for the other clients. Regards, Dusan. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dhcwg&d=3DDQIFJg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3DdSOZR4dOvOIFlrJUO0ra9EaHoccrAjAiWycX_Y4vnRQ&= s=3De5wK-WS09BIx0RKDTBE_iEdUlrK_bP6gv4TfQaMTPiU&e=3D=20 From nobody Wed Feb 8 14:52:02 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E32912A095 for ; Wed, 8 Feb 2017 14:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 D6EDYCFa9QCd for ; Wed, 8 Feb 2017 14:51:56 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B259D12A094 for ; Wed, 8 Feb 2017 14:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4674; q=dns/txt; s=iport; t=1486594316; x=1487803916; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=d77DuQC/B3QpajV+rcRcMVuoR2Xu2akasdMwKMHmJpY=; b=CP+iPD7CSHzOkF8RwfiM5syRuYlZh5XOPy206KJ0OZU6+uFCKIX9+B90 cUGyHLR2pl+dVSHywAtU26+V6v5K3omh7AUrG2R+vZ8hz6N9KT897J8My xTmWXAdlJt38YgSP+MjCL+i36s3duSkCf/boVt4wTrlWnthfSfpDoz4BH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQCTn5tY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1KKCJIJiAyLG4IPggwmhXwCgm8/GAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBAQEEIQFMCwwEAgEIEQQBAQIDCxgCAwIhERQJCAEBBA4FCIlUAxWSZp1JA?= =?us-ascii?q?YIphzgNhAoBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQiKM4E8gRWBbYMZgmIFmzg?= =?us-ascii?q?4AYZshwyEEIJXjjeFbYRHiF4BHzg6RE8VPIZCdYZCB4EpgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,348,1484006400"; d="scan'208";a="206435510" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2017 22:51:55 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v18Mpt5l023007 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Feb 2017 22:51:55 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 16:51:54 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Wed, 8 Feb 2017 16:51:54 -0600 From: "Bernie Volz (volz)" To: "Mudric, Dusan (Dusan)" Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeA= Date: Wed, 8 Feb 2017 22:51:54 +0000 Message-ID: References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.56] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 22:52:01 -0000 No. DECLINE means address is bad (duplicated). DECLINE is only valid after Repl= y, not after Advertise.=20 RELEASE means client does not want to use the address provided. I don't see any benefit to change this. - Bernie -----Original Message----- From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]=20 Sent: Wednesday, February 08, 2017 5:38 PM To: Bernie Volz (volz) Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Understand the concern. The client should be able to DECLINE addresses in b= oth ADVERTISE and REPLY. Receiving the REPLY does not mean that a unique ad= dress must be assigned to the interface. If a client DECLINEs the ADVERTISE= d or REPLIEd address, DHCPV6 server should be able to advertise another add= ress. The client should also be able to tell that is does not want another addres= s. For example, if RENEW/REBIND returns a new address, the client should be= able to DECLINE it. Regards, Dusan. -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, February 08, 2017 5:28 PM To: Mudric, Dusan (Dusan) Cc: dhcwg Subject: RE: RFC3315 DECLINE definition I'm confused ... advertised vs assigned addresses. Once a Reply is received= , the address is assigned -- no longer advertised. DECLINE means that the address is in use. If the client DECLINEs it and jus= t makes it available immediately, the next client to get that address assig= ned and does DAD will also find a conflict ... so what=1B$B!G=1B(Bs the val= ue of that. Generally, declined addresses should not be used for a while (that is polic= y dependent) since it means some other device is using the address. I thought you were trying to say a Decline sent in response to an Advertise= would tell the server "I don't want those addresses". But that is not mean= ingful and why would a client even try to do that. Also, an Advertise is ju= st that -- and advertisement; it is not a commitment to assigned those addr= esses -- the client can only use the addresses in the Reply. (DHCPv4 is a b= it different in this respect -- the address in the Offer must be same as in= the Ack. DHCPv6 has no such hard requirement -- it usually is, but that's = not required.) - Bernie -----Original Message----- From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]=20 Sent: Wednesday, February 08, 2017 5:19 PM To: Bernie Volz (volz) Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Hi Bernie, I am talking about DECLINE after REPLY. What I am proposing is to use DECL= INE for "I don't want your Advertised address(es)". I think this will be mu= ch cleaner then to let the server timeout the advertised addresses, which c= an take long. Thanks, Dusan -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, February 08, 2017 4:57 PM To: Mudric, Dusan (Dusan); =1B$B?@L@C#:H=1B(B; Lishan Li Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Dusan: DECLINE is used after a REPLY, not after an ADVERTISE. A client has not been assigned an address until it receives the REPLY (at w= hich point it does DAD and may send a DECLINE). There is no mechanism for a client to indicate to a server "I don't want yo= ur Advertised address(es)", except by not proceeding to send a REQUEST. The server may have held the address "reserved" for a short period of time,= but does that really matter? IPv6 addresses are not in short supply. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mudric, Dusan (Dus= an) Sent: Wednesday, February 08, 2017 4:47 PM To: =1B$B?@L@C#:H=1B(B ; Lishan Li Cc: dhcwg Subject: [dhcwg] RFC3315 DECLINE definition Hi, Can DECLINE definition be extended beyond the DAD usage? I think DECLINE sh= ould be used every time DHCPV6 client decides not to assign the offered add= ress, for any reason, not just the address is duplicate. When receiving DEC= LINE, DHCPV6 server should be able to immediately make the same address ava= ilable in the address pool for the other clients. Regards, Dusan. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dhcwg&d=3DDQIFJg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3DdSOZR4dOvOIFlrJUO0ra9EaHoccrAjAiWycX_Y4vnRQ&= s=3De5wK-WS09BIx0RKDTBE_iEdUlrK_bP6gv4TfQaMTPiU&e=3D=20 From nobody Thu Feb 9 05:58:05 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC83129A11 for ; Thu, 9 Feb 2017 05:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 N3gJtz3Xd6v3 for ; Thu, 9 Feb 2017 05:58:00 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33061129A2A for ; Thu, 9 Feb 2017 05:57:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GfAABSdJxY/xUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBBYYEJB4NSigiSCogMixuCD4FJQyaFfAKCaj8YAQIBAQEBAQE?= =?us-ascii?q?BA18ogls9BgcvAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAxIPAUwLDAQCAQgNB?= =?us-ascii?q?AQBAQIDBgUYAgMCIREUCQgCBA4FCBqJOgMVAZIdkmyKXQGCKSYChwgNhAoBAQE?= =?us-ascii?q?BAQEBAQIBAQEBAQEBAQEBAR2BCIVFhG6BPIEVgW0YgwExgjEFmzg4AYZshwsBh?= =?us-ascii?q?meICIYvhW2ER4hfHzk6RE8VPIZCdYZCB4EpAYELAQEB?= X-IPAS-Result: =?us-ascii?q?A2GfAABSdJxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?BYYEJB4NSigiSCogMixuCD4FJQyaFfAKCaj8YAQIBAQEBAQEBA18ogls9BgcvA?= =?us-ascii?q?QEBAQEBAQEBAQEBARwCD0EBARgBAQEBAxIPAUwLDAQCAQgNBAQBAQIDBgUYAgM?= =?us-ascii?q?CIREUCQgCBA4FCBqJOgMVAZIdkmyKXQGCKSYChwgNhAoBAQEBAQEBAQIBAQEBA?= =?us-ascii?q?QEBAQEBAR2BCIVFhG6BPIEVgW0YgwExgjEFmzg4AYZshwsBhmeICIYvhW2ER4h?= =?us-ascii?q?fHzk6RE8VPIZCdYZCB4EpAYELAQEB?= X-IronPort-AV: E=Sophos;i="5.35,349,1484024400"; d="scan'208";a="227416266" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Feb 2017 08:57:58 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 08:57:59 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 08:57:57 -0500 From: "Mudric, Dusan (Dusan)" To: "Bernie Volz (volz)" Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcA== Date: Thu, 9 Feb 2017 13:57:57 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 13:58:02 -0000 Hi Bernie, I agree with the definition: " DECLINE means address is bad". What I am say= ing is that "bad" does not only mean "duplicated". Applications and devices= can have other reasons to thing about the offered address to be "bad". If = they find the address is "bad" for any reason, they can send DECLINE. Even= the current DHCPv6 protocol does not prevent the DHCPv6 client to send DEC= LINE for ADVERTISE and REPLY. It is the server that should use it efficient= ly. Regards, Dusan. -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, February 08, 2017 5:52 PM To: Mudric, Dusan (Dusan) Cc: dhcwg Subject: RE: RFC3315 DECLINE definition No. DECLINE means address is bad (duplicated). DECLINE is only valid after Repl= y, not after Advertise.=20 RELEASE means client does not want to use the address provided. I don't see any benefit to change this. - Bernie -----Original Message----- From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]=20 Sent: Wednesday, February 08, 2017 5:38 PM To: Bernie Volz (volz) Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Understand the concern. The client should be able to DECLINE addresses in b= oth ADVERTISE and REPLY. Receiving the REPLY does not mean that a unique ad= dress must be assigned to the interface. If a client DECLINEs the ADVERTISE= d or REPLIEd address, DHCPV6 server should be able to advertise another add= ress. The client should also be able to tell that is does not want another addres= s. For example, if RENEW/REBIND returns a new address, the client should be= able to DECLINE it. Regards, Dusan. -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, February 08, 2017 5:28 PM To: Mudric, Dusan (Dusan) Cc: dhcwg Subject: RE: RFC3315 DECLINE definition I'm confused ... advertised vs assigned addresses. Once a Reply is received= , the address is assigned -- no longer advertised. DECLINE means that the address is in use. If the client DECLINEs it and jus= t makes it available immediately, the next client to get that address assig= ned and does DAD will also find a conflict ... so what=1B$B!G=1B(Bs the val= ue of that. Generally, declined addresses should not be used for a while (that is polic= y dependent) since it means some other device is using the address. I thought you were trying to say a Decline sent in response to an Advertise= would tell the server "I don't want those addresses". But that is not mean= ingful and why would a client even try to do that. Also, an Advertise is ju= st that -- and advertisement; it is not a commitment to assigned those addr= esses -- the client can only use the addresses in the Reply. (DHCPv4 is a b= it different in this respect -- the address in the Offer must be same as in= the Ack. DHCPv6 has no such hard requirement -- it usually is, but that's = not required.) - Bernie -----Original Message----- From: Mudric, Dusan (Dusan) [mailto:dmudric@avaya.com]=20 Sent: Wednesday, February 08, 2017 5:19 PM To: Bernie Volz (volz) Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Hi Bernie, I am talking about DECLINE after REPLY. What I am proposing is to use DECL= INE for "I don't want your Advertised address(es)". I think this will be mu= ch cleaner then to let the server timeout the advertised addresses, which c= an take long. Thanks, Dusan -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Wednesday, February 08, 2017 4:57 PM To: Mudric, Dusan (Dusan); =1B$B?@L@C#:H=1B(B; Lishan Li Cc: dhcwg Subject: RE: RFC3315 DECLINE definition Dusan: DECLINE is used after a REPLY, not after an ADVERTISE. A client has not been assigned an address until it receives the REPLY (at w= hich point it does DAD and may send a DECLINE). There is no mechanism for a client to indicate to a server "I don't want yo= ur Advertised address(es)", except by not proceeding to send a REQUEST. The server may have held the address "reserved" for a short period of time,= but does that really matter? IPv6 addresses are not in short supply. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mudric, Dusan (Dus= an) Sent: Wednesday, February 08, 2017 4:47 PM To: =1B$B?@L@C#:H=1B(B ; Lishan Li Cc: dhcwg Subject: [dhcwg] RFC3315 DECLINE definition Hi, Can DECLINE definition be extended beyond the DAD usage? I think DECLINE sh= ould be used every time DHCPV6 client decides not to assign the offered add= ress, for any reason, not just the address is duplicate. When receiving DEC= LINE, DHCPV6 server should be able to immediately make the same address ava= ilable in the address pool for the other clients. Regards, Dusan. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dhcwg&d=3DDQIFJg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3DdSOZR4dOvOIFlrJUO0ra9EaHoccrAjAiWycX_Y4vnRQ&= s=3De5wK-WS09BIx0RKDTBE_iEdUlrK_bP6gv4TfQaMTPiU&e=3D=20 From nobody Thu Feb 9 06:06:02 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9548129A35 for ; Thu, 9 Feb 2017 06:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 KMWzjuHmmJW0 for ; Thu, 9 Feb 2017 06:05:59 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A89E129535 for ; Thu, 9 Feb 2017 06:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7956; q=dns/txt; s=iport; t=1486649159; x=1487858759; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7clymGqzao0ujv3EsR0WpfyXEISGJY4mMd7J1S7KFz8=; b=L3TqmiHD5ga23DCJpQEReilsJKKpTOdBptXY+xa8odLN3GIOQxHIj3Y6 rU+mUn2SuctVKtIVwQlLhcTppsLiTnmb0Ii+qbYkTPqVwGDnBmHZjac7R mnhP8GR7KORYib1HrR2I8v+P6vAdl9JKgscexqoR42qj+0GOL3k1Xqas0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQCtdpxY/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1KKCJIKiAyLG4IPggwmhXwCGoJQPxgBAgEBAQEBAQF?= =?us-ascii?q?iKIRpAQEBBCMROgsMBAIBBgIRBAEBAwIjAwICAh8RFAEICAIEDgWJXAMVkiCdT?= =?us-ascii?q?oIlhzANhAoBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQuHRoJqgTyBFYFtFoMGLoI?= =?us-ascii?q?xAQSbODgBhmyHDIQZgk6ON4VthEeIXgEfOH5PFTwRAYQ/gXF1hkIHgSmBDAEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.35,349,1484006400"; d="scan'208";a="196310909" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2017 14:05:58 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v19E5wxk007283 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Feb 2017 14:05:58 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Feb 2017 08:05:57 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 9 Feb 2017 08:05:57 -0600 From: "Bernie Volz (volz)" To: "Mudric, Dusan (Dusan)" Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKA Date: Thu, 9 Feb 2017 14:05:57 +0000 Message-ID: <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.204] Content-Type: text/plain; charset="utf-8" Content-ID: <8DB9D61EEAA35D42A33E806DA0E02565@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:06:00 -0000 QWdhaW4sIERFQ0xJTkUgSXMgb25seSBhZnRlciBSRVBMWSByZWNlaXZlZC4gTm90IEFkdmVydGlz ZS4NCg0KLSBCZXJuaWUNCg0KT24gMi85LzE3LCA4OjU3IEFNLCAiTXVkcmljLCBEdXNhbiAoRHVz YW4pIiA8ZG11ZHJpY0BhdmF5YS5jb20+IHdyb3RlOg0KDQogICAgSGkgQmVybmllLA0KICAgIA0K ICAgIEkgYWdyZWUgd2l0aCB0aGUgZGVmaW5pdGlvbjogIiBERUNMSU5FIG1lYW5zIGFkZHJlc3Mg aXMgYmFkIi4gV2hhdCBJIGFtIHNheWluZyBpcyB0aGF0ICJiYWQiIGRvZXMgbm90IG9ubHkgbWVh biAiZHVwbGljYXRlZCIuIEFwcGxpY2F0aW9ucyBhbmQgZGV2aWNlcyBjYW4gaGF2ZSBvdGhlciBy ZWFzb25zIHRvIHRoaW5nIGFib3V0IHRoZSBvZmZlcmVkIGFkZHJlc3MgdG8gYmUgImJhZCIuIElm IHRoZXkgZmluZCB0aGUgYWRkcmVzcyAgaXMgImJhZCIgZm9yIGFueSByZWFzb24sIHRoZXkgY2Fu IHNlbmQgREVDTElORS4gRXZlbiB0aGUgY3VycmVudCBESENQdjYgcHJvdG9jb2wgZG9lcyBub3Qg cHJldmVudCB0aGUgREhDUHY2IGNsaWVudCB0byBzZW5kIERFQ0xJTkUgZm9yIEFEVkVSVElTRSBh bmQgUkVQTFkuIEl0IGlzIHRoZSBzZXJ2ZXIgdGhhdCBzaG91bGQgdXNlIGl0IGVmZmljaWVudGx5 Lg0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgRHVzYW4uDQogICAgDQogICAgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBCZXJuaWUgVm9seiAodm9seikgW21haWx0bzp2b2x6 QGNpc2NvLmNvbV0gDQogICAgU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyA1OjUy IFBNDQogICAgVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKQ0KICAgIENjOiBkaGN3Zw0KICAgIFN1 YmplY3Q6IFJFOiBSRkMzMzE1IERFQ0xJTkUgZGVmaW5pdGlvbg0KICAgIA0KICAgIE5vLg0KICAg IA0KICAgIERFQ0xJTkUgbWVhbnMgYWRkcmVzcyBpcyBiYWQgKGR1cGxpY2F0ZWQpLiBERUNMSU5F IGlzIG9ubHkgdmFsaWQgYWZ0ZXIgUmVwbHksIG5vdCBhZnRlciBBZHZlcnRpc2UuIA0KICAgIA0K ICAgIFJFTEVBU0UgbWVhbnMgY2xpZW50IGRvZXMgbm90IHdhbnQgdG8gdXNlIHRoZSBhZGRyZXNz IHByb3ZpZGVkLg0KICAgIA0KICAgIEkgZG9uJ3Qgc2VlIGFueSBiZW5lZml0IHRvIGNoYW5nZSB0 aGlzLg0KICAgIA0KICAgIC0gQmVybmllDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCiAgICBGcm9tOiBNdWRyaWMsIER1c2FuIChEdXNhbikgW21haWx0bzpkbXVkcmljQGF2 YXlhLmNvbV0gDQogICAgU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyA1OjM4IFBN DQogICAgVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+DQogICAgQ2M6IGRo Y3dnIDxkaGN3Z0BpZXRmLm9yZz4NCiAgICBTdWJqZWN0OiBSRTogUkZDMzMxNSBERUNMSU5FIGRl ZmluaXRpb24NCiAgICANCiAgICBVbmRlcnN0YW5kIHRoZSBjb25jZXJuLiBUaGUgY2xpZW50IHNo b3VsZCBiZSBhYmxlIHRvIERFQ0xJTkUgYWRkcmVzc2VzIGluIGJvdGggQURWRVJUSVNFIGFuZCBS RVBMWS4gUmVjZWl2aW5nIHRoZSBSRVBMWSBkb2VzIG5vdCBtZWFuIHRoYXQgYSB1bmlxdWUgYWRk cmVzcyBtdXN0IGJlIGFzc2lnbmVkIHRvIHRoZSBpbnRlcmZhY2UuIElmIGEgY2xpZW50IERFQ0xJ TkVzIHRoZSBBRFZFUlRJU0VkIG9yIFJFUExJRWQgYWRkcmVzcywgREhDUFY2IHNlcnZlciBzaG91 bGQgYmUgYWJsZSB0byBhZHZlcnRpc2UgYW5vdGhlciBhZGRyZXNzLg0KICAgIA0KICAgIFRoZSBj bGllbnQgc2hvdWxkIGFsc28gYmUgYWJsZSB0byB0ZWxsIHRoYXQgaXMgZG9lcyBub3Qgd2FudCBh bm90aGVyIGFkZHJlc3MuIEZvciBleGFtcGxlLCBpZiBSRU5FVy9SRUJJTkQgcmV0dXJucyBhIG5l dyBhZGRyZXNzLCB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIERFQ0xJTkUgaXQuDQogICAg DQogICAgUmVnYXJkcywNCiAgICBEdXNhbi4NCiAgICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KICAgIEZyb206IEJlcm5pZSBWb2x6ICh2b2x6KSBbbWFpbHRvOnZvbHpAY2lzY28u Y29tXSANCiAgICBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDE3IDU6MjggUE0NCiAg ICBUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pDQogICAgQ2M6IGRoY3dnDQogICAgU3ViamVjdDog UkU6IFJGQzMzMTUgREVDTElORSBkZWZpbml0aW9uDQogICAgDQogICAgSSdtIGNvbmZ1c2VkIC4u LiBhZHZlcnRpc2VkIHZzIGFzc2lnbmVkIGFkZHJlc3Nlcy4gT25jZSBhIFJlcGx5IGlzIHJlY2Vp dmVkLCB0aGUgYWRkcmVzcyBpcyBhc3NpZ25lZCAtLSBubyBsb25nZXIgYWR2ZXJ0aXNlZC4NCiAg ICANCiAgICBERUNMSU5FIG1lYW5zIHRoYXQgdGhlIGFkZHJlc3MgaXMgaW4gdXNlLiBJZiB0aGUg Y2xpZW50IERFQ0xJTkVzIGl0IGFuZCBqdXN0IG1ha2VzIGl0IGF2YWlsYWJsZSBpbW1lZGlhdGVs eSwgdGhlIG5leHQgY2xpZW50IHRvIGdldCB0aGF0IGFkZHJlc3MgYXNzaWduZWQgYW5kIGRvZXMg REFEIHdpbGwgYWxzbyBmaW5kIGEgY29uZmxpY3QgLi4uIHNvIHdoYXTigJlzIHRoZSB2YWx1ZSBv ZiB0aGF0Lg0KICAgIA0KICAgIEdlbmVyYWxseSwgZGVjbGluZWQgYWRkcmVzc2VzIHNob3VsZCBu b3QgYmUgdXNlZCBmb3IgYSB3aGlsZSAodGhhdCBpcyBwb2xpY3kgZGVwZW5kZW50KSBzaW5jZSBp dCBtZWFucyBzb21lIG90aGVyIGRldmljZSBpcyB1c2luZyB0aGUgYWRkcmVzcy4NCiAgICANCiAg ICANCiAgICBJIHRob3VnaHQgeW91IHdlcmUgdHJ5aW5nIHRvIHNheSBhIERlY2xpbmUgc2VudCBp biByZXNwb25zZSB0byBhbiBBZHZlcnRpc2Ugd291bGQgdGVsbCB0aGUgc2VydmVyICJJIGRvbid0 IHdhbnQgdGhvc2UgYWRkcmVzc2VzIi4gQnV0IHRoYXQgaXMgbm90IG1lYW5pbmdmdWwgYW5kIHdo eSB3b3VsZCBhIGNsaWVudCBldmVuIHRyeSB0byBkbyB0aGF0LiBBbHNvLCBhbiBBZHZlcnRpc2Ug aXMganVzdCB0aGF0IC0tIGFuZCBhZHZlcnRpc2VtZW50OyBpdCBpcyBub3QgYSBjb21taXRtZW50 IHRvIGFzc2lnbmVkIHRob3NlIGFkZHJlc3NlcyAtLSB0aGUgY2xpZW50IGNhbiBvbmx5IHVzZSB0 aGUgYWRkcmVzc2VzIGluIHRoZSBSZXBseS4gKERIQ1B2NCBpcyBhIGJpdCBkaWZmZXJlbnQgaW4g dGhpcyByZXNwZWN0IC0tIHRoZSBhZGRyZXNzIGluIHRoZSBPZmZlciBtdXN0IGJlIHNhbWUgYXMg aW4gdGhlIEFjay4gREhDUHY2IGhhcyBubyBzdWNoIGhhcmQgcmVxdWlyZW1lbnQgLS0gaXQgdXN1 YWxseSBpcywgYnV0IHRoYXQncyBub3QgcmVxdWlyZWQuKQ0KICAgIA0KICAgIC0gQmVybmllDQog ICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBNdWRyaWMsIER1 c2FuIChEdXNhbikgW21haWx0bzpkbXVkcmljQGF2YXlhLmNvbV0gDQogICAgU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAwOCwgMjAxNyA1OjE5IFBNDQogICAgVG86IEJlcm5pZSBWb2x6ICh2b2x6 KSA8dm9sekBjaXNjby5jb20+DQogICAgQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4NCiAgICBT dWJqZWN0OiBSRTogUkZDMzMxNSBERUNMSU5FIGRlZmluaXRpb24NCiAgICANCiAgICANCiAgICBI aSBCZXJuaWUsDQogICAgDQogICAgSSBhbSB0YWxraW5nIGFib3V0IERFQ0xJTkUgYWZ0ZXIgUkVQ TFkuIFdoYXQgSSBhbSAgcHJvcG9zaW5nIGlzIHRvIHVzZSBERUNMSU5FIGZvciAiSSBkb24ndCB3 YW50IHlvdXIgQWR2ZXJ0aXNlZCBhZGRyZXNzKGVzKSIuIEkgdGhpbmsgdGhpcyB3aWxsIGJlIG11 Y2ggY2xlYW5lciB0aGVuIHRvIGxldCB0aGUgc2VydmVyIHRpbWVvdXQgdGhlIGFkdmVydGlzZWQg YWRkcmVzc2VzLCB3aGljaCBjYW4gdGFrZSBsb25nLg0KICAgIA0KICAgIFRoYW5rcywNCiAgICAN CiAgICBEdXNhbg0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJv bTogQmVybmllIFZvbHogKHZvbHopIFttYWlsdG86dm9sekBjaXNjby5jb21dIA0KICAgIFNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMDgsIDIwMTcgNDo1NyBQTQ0KICAgIFRvOiBNdWRyaWMsIER1 c2FuIChEdXNhbik7IOelnuaYjumBlOWTiTsgTGlzaGFuIExpDQogICAgQ2M6IGRoY3dnDQogICAg U3ViamVjdDogUkU6IFJGQzMzMTUgREVDTElORSBkZWZpbml0aW9uDQogICAgDQogICAgRHVzYW46 DQogICAgDQogICAgREVDTElORSBpcyB1c2VkIGFmdGVyIGEgUkVQTFksIG5vdCBhZnRlciBhbiBB RFZFUlRJU0UuDQogICAgDQogICAgQSBjbGllbnQgaGFzIG5vdCBiZWVuIGFzc2lnbmVkIGFuIGFk ZHJlc3MgdW50aWwgaXQgcmVjZWl2ZXMgdGhlIFJFUExZIChhdCB3aGljaCBwb2ludCBpdCBkb2Vz IERBRCBhbmQgbWF5IHNlbmQgYSBERUNMSU5FKS4NCiAgICANCiAgICBUaGVyZSBpcyBubyBtZWNo YW5pc20gZm9yIGEgY2xpZW50IHRvIGluZGljYXRlIHRvIGEgc2VydmVyICJJIGRvbid0IHdhbnQg eW91ciBBZHZlcnRpc2VkIGFkZHJlc3MoZXMpIiwgZXhjZXB0IGJ5IG5vdCBwcm9jZWVkaW5nIHRv IHNlbmQgYSBSRVFVRVNULg0KICAgIA0KICAgIFRoZSBzZXJ2ZXIgbWF5IGhhdmUgaGVsZCB0aGUg YWRkcmVzcyAicmVzZXJ2ZWQiIGZvciBhIHNob3J0IHBlcmlvZCBvZiB0aW1lLCBidXQgZG9lcyB0 aGF0IHJlYWxseSBtYXR0ZXI/IElQdjYgYWRkcmVzc2VzIGFyZSBub3QgaW4gc2hvcnQgc3VwcGx5 Lg0KICAgIA0KICAgIC0gQmVybmllDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCiAgICBGcm9tOiBkaGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBNdWRyaWMsIER1c2FuIChEdXNhbikNCiAgICBTZW50OiBXZWRuZXNkYXksIEZlYnJ1 YXJ5IDA4LCAyMDE3IDQ6NDcgUE0NCiAgICBUbzog56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5h ZC5qcD47IExpc2hhbiBMaSA8bGlsaXNoYW40OEBnbWFpbC5jb20+DQogICAgQ2M6IGRoY3dnIDxk aGN3Z0BpZXRmLm9yZz4NCiAgICBTdWJqZWN0OiBbZGhjd2ddIFJGQzMzMTUgREVDTElORSBkZWZp bml0aW9uDQogICAgDQogICAgSGksDQogICAgDQogICAgQ2FuIERFQ0xJTkUgZGVmaW5pdGlvbiBi ZSBleHRlbmRlZCBiZXlvbmQgdGhlIERBRCB1c2FnZT8gSSB0aGluayBERUNMSU5FIHNob3VsZCBi ZSB1c2VkIGV2ZXJ5IHRpbWUgREhDUFY2IGNsaWVudCBkZWNpZGVzIG5vdCB0byBhc3NpZ24gdGhl IG9mZmVyZWQgYWRkcmVzcywgZm9yIGFueSByZWFzb24sIG5vdCBqdXN0IHRoZSBhZGRyZXNzIGlz IGR1cGxpY2F0ZS4gV2hlbiByZWNlaXZpbmcgREVDTElORSwgREhDUFY2IHNlcnZlciBzaG91bGQg YmUgYWJsZSB0byBpbW1lZGlhdGVseSBtYWtlIHRoZSBzYW1lIGFkZHJlc3MgYXZhaWxhYmxlIGlu IHRoZSBhZGRyZXNzIHBvb2wgZm9yIHRoZSBvdGhlciBjbGllbnRzLg0KICAgIA0KICAgIFJlZ2Fy ZHMsDQogICAgRHVzYW4uDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICBkaGN3ZyBtYWlsaW5nIGxpc3QNCiAgICBkaGN3Z0BpZXRm Lm9yZw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fZGhjd2cmZD1EUUlGSmcmYz1CRnBX UXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlz TVFHUTJrWSZtPWRTT1pSNGRPdk9JRmxySlVPMHJhOUVhSG9jY3JBakFpV3ljWF9ZNHZuUlEmcz1l NXdLLVdTMDlCSXgwUktEVEJFX2lFZFVscktfYlA2Z3Y0VGZRYU1UUGlVJmU9IA0KICAgIA0KDQo= From nobody Thu Feb 9 06:34:25 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76938129A6C for ; Thu, 9 Feb 2017 06:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 V986v7S0xhjB for ; Thu, 9 Feb 2017 06:34:22 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC340129A7A for ; Thu, 9 Feb 2017 06:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10552; q=dns/txt; s=iport; t=1486650851; x=1487860451; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ld/FJBcxyW2m3zc3Lk3nf8iLNHgklSNawJIRO9OydeI=; b=kdXLNk0PrhLSmbT/HYiT38AZaXreKwtWPd9wqx6wlc/fppyArzNA5RF1 3oCLM7N8RD6UOIZvCaPoKHYcFdPULx8X9GryE096HQTgZ0bTXRc2ZmsO3 E7MhECNiaZdCw98SU8cN6HkK8y45ftfd87tm5UMCt9ytOVYHC13GEYSq9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQDAfJxY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHg1KKCJIJiAyLG4IPggwqhXgCGoJQPxgBAgEBAQEBAQF?= =?us-ascii?q?iKIRpAQEBBCMROgsMBAIBBgIRBAEBAwIjAwICAh8RFAEICAIEDgWJXAMVDpIYn?= =?us-ascii?q?U6CJYcvDYQKAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELh0aCaoE8gRWBbYMcLoI?= =?us-ascii?q?xBZs4OAGGbIcMhBmCTo43hW2ER4heAR84fk8VPBEBhD+BcXUBAYZAB4EpgQwBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.35,349,1484006400"; d="scan'208";a="383377987" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 14:34:10 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v19EYADK021687 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Feb 2017 14:34:10 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Feb 2017 08:34:10 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 9 Feb 2017 08:34:09 -0600 From: "Bernie Volz (volz)" To: "Mudric, Dusan (Dusan)" Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAA== Date: Thu, 9 Feb 2017 14:34:09 +0000 Message-ID: <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.204] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:34:24 -0000 SSBhbSBnb2luZyB0byBnaXZlIHVwIG9uIHRoaXMgZGViYXRlIHdpdGggeW91Lg0KDQpUaGVyZSBh cmUgbm8gcGxhbnMgdG8gY2hhbmdlIGFueSBvZiB0aGlzLiBQZXJoYXBzIGFub3RoZXIgUkZDMzMx NWJpcyBhdXRob3Igd2lsbCB0YWtlIHRoaXMgdXAgd2l0aCB5b3UuDQoNCi0gQmVybmllDQoNCk9u IDIvOS8xNywgOTozMSBBTSwgIk11ZHJpYywgRHVzYW4gKER1c2FuKSIgPGRtdWRyaWNAYXZheWEu Y29tPiB3cm90ZToNCg0KICAgIEhpIEJlcm5pZSwNCiAgICANCiAgICBUaGF0IGlzIHRoZSBjdXJy ZW50IHVzZSBvZiBERUNMSU5FIChvbmx5IGZvciBEQUQpLiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMzMxNSNzZWN0aW9uLTE3LjEuMyBvbmx5IGZvY3VzZXMgb24gdGhlIHNlcnZlciBz ZWxlY3Rpb24gYWZ0ZXIgQURWRVJUSVNFIGlzIHJlY2VpdmVkLiBJdCBkb2VzIG5vdCBtZW50aW9u IHRoYXQgREhDUHY2IGNsaWVudCBtaWdodCBub3QgYmUgaGFwcHkgd2l0aCB0aGUgYWR2ZXJ0aXNl ZCBhZGRyZXNzZXMuIElQdjYgZGVmaW5lcyBkaWZmZXJlbnQga2luZHMgb2YgYWRkcmVzc2VzIGFu ZCBhbGxvd3MgbXVsdGlwbGUgYWRkcmVzc2VzLCBtYWtpbmcgaXQgbW9yZSBjb21wbGV4IHRvIGhh bmRsZS4gSWYgYSBzZXJ2ZXIgb2ZmZXJzIElQdjYgYWRkcmVzcyB0aGF0IGNsaWVudCBjYW5ub3Qg dXNlIChlLmcuIGEgbXVsdGljYXN0IGFkZHJlc3MsIGEgc2Vjb25kIGFkZHJlc3MpLCB0aGUgY2xp ZW50IHNob3VsZCBiZSBhYmxlIHRvIGRlY2xpbmUgaXQuDQogICAgDQogICAgQWdhaW4sIGlmIHRo ZSBzZXJ2ZXIgc2VuZHMgUkVQTFkgb3IgUkVCSU5EIHdpdGggYW4gYWRkcmVzcyB0aGUgY2xpZW50 IGNhbm5vdCB1c2UsIHRoZSBjbGllbnQgc2hvdWxkIGJlIGFibGUgdG8gREVDTElORSBpdC4NCiAg ICANCiAgICBERUNMSU5FIHNob3VsZCBiZSBkZWZpbmVkIGFzIGEgcmVzcG9uc2UgZm9yIHRoZSBh ZGRyZXNzZXMgdGhhdCBjYW5ub3QgYmUgYXNzaWduZWQuIA0KICAgIA0KICAgIFRoZXNlIGFyZSB0 aGUgaXNzdWVzIEkgaWRlbnRpZmllZCBkdXJpbmcgREhDUHY2IHRlc3RpbmcgYW5kIGFuYWx5c2lz IGFuZCB0aGV5IG5lZWQgdG8gYmUgYWRkcmVzc2VkIHdpdGggdGhlIG5ldyBkZWZpbml0aW9uIGZv ciBERUNMSU5FLg0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgRHVzYW4uDQogICAgDQogICAgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBCZXJuaWUgVm9seiAodm9seikgW21h aWx0bzp2b2x6QGNpc2NvLmNvbV0gDQogICAgU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDA5LCAy MDE3IDk6MDYgQU0NCiAgICBUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pDQogICAgQ2M6IGRoY3dn DQogICAgU3ViamVjdDogUmU6IFJGQzMzMTUgREVDTElORSBkZWZpbml0aW9uDQogICAgDQogICAg QWdhaW4sIERFQ0xJTkUgSXMgb25seSBhZnRlciBSRVBMWSByZWNlaXZlZC4gTm90IEFkdmVydGlz ZS4NCiAgICANCiAgICAtIEJlcm5pZQ0KICAgIA0KICAgIE9uIDIvOS8xNywgODo1NyBBTSwgIk11 ZHJpYywgRHVzYW4gKER1c2FuKSIgPGRtdWRyaWNAYXZheWEuY29tPiB3cm90ZToNCiAgICANCiAg ICAgICAgSGkgQmVybmllLA0KICAgICAgICANCiAgICAgICAgSSBhZ3JlZSB3aXRoIHRoZSBkZWZp bml0aW9uOiAiIERFQ0xJTkUgbWVhbnMgYWRkcmVzcyBpcyBiYWQiLiBXaGF0IEkgYW0gc2F5aW5n IGlzIHRoYXQgImJhZCIgZG9lcyBub3Qgb25seSBtZWFuICJkdXBsaWNhdGVkIi4gQXBwbGljYXRp b25zIGFuZCBkZXZpY2VzIGNhbiBoYXZlIG90aGVyIHJlYXNvbnMgdG8gdGhpbmcgYWJvdXQgdGhl IG9mZmVyZWQgYWRkcmVzcyB0byBiZSAiYmFkIi4gSWYgdGhleSBmaW5kIHRoZSBhZGRyZXNzICBp cyAiYmFkIiBmb3IgYW55IHJlYXNvbiwgdGhleSBjYW4gc2VuZCBERUNMSU5FLiBFdmVuIHRoZSBj dXJyZW50IERIQ1B2NiBwcm90b2NvbCBkb2VzIG5vdCBwcmV2ZW50IHRoZSBESENQdjYgY2xpZW50 IHRvIHNlbmQgREVDTElORSBmb3IgQURWRVJUSVNFIGFuZCBSRVBMWS4gSXQgaXMgdGhlIHNlcnZl ciB0aGF0IHNob3VsZCB1c2UgaXQgZWZmaWNpZW50bHkuDQogICAgICAgIA0KICAgICAgICBSZWdh cmRzLA0KICAgICAgICBEdXNhbi4NCiAgICAgICAgDQogICAgICAgIC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQogICAgICAgIEZyb206IEJlcm5pZSBWb2x6ICh2b2x6KSBbbWFpbHRvOnZvbHpA Y2lzY28uY29tXSANCiAgICAgICAgU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyA1 OjUyIFBNDQogICAgICAgIFRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikNCiAgICAgICAgQ2M6IGRo Y3dnDQogICAgICAgIFN1YmplY3Q6IFJFOiBSRkMzMzE1IERFQ0xJTkUgZGVmaW5pdGlvbg0KICAg ICAgICANCiAgICAgICAgTm8uDQogICAgICAgIA0KICAgICAgICBERUNMSU5FIG1lYW5zIGFkZHJl c3MgaXMgYmFkIChkdXBsaWNhdGVkKS4gREVDTElORSBpcyBvbmx5IHZhbGlkIGFmdGVyIFJlcGx5 LCBub3QgYWZ0ZXIgQWR2ZXJ0aXNlLiANCiAgICAgICAgDQogICAgICAgIFJFTEVBU0UgbWVhbnMg Y2xpZW50IGRvZXMgbm90IHdhbnQgdG8gdXNlIHRoZSBhZGRyZXNzIHByb3ZpZGVkLg0KICAgICAg ICANCiAgICAgICAgSSBkb24ndCBzZWUgYW55IGJlbmVmaXQgdG8gY2hhbmdlIHRoaXMuDQogICAg ICAgIA0KICAgICAgICAtIEJlcm5pZQ0KICAgICAgICANCiAgICAgICAgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCiAgICAgICAgRnJvbTogTXVkcmljLCBEdXNhbiAoRHVzYW4pIFttYWlsdG86 ZG11ZHJpY0BhdmF5YS5jb21dIA0KICAgICAgICBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4 LCAyMDE3IDU6MzggUE0NCiAgICAgICAgVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNj by5jb20+DQogICAgICAgIENjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+DQogICAgICAgIFN1Ympl Y3Q6IFJFOiBSRkMzMzE1IERFQ0xJTkUgZGVmaW5pdGlvbg0KICAgICAgICANCiAgICAgICAgVW5k ZXJzdGFuZCB0aGUgY29uY2Vybi4gVGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byBERUNMSU5F IGFkZHJlc3NlcyBpbiBib3RoIEFEVkVSVElTRSBhbmQgUkVQTFkuIFJlY2VpdmluZyB0aGUgUkVQ TFkgZG9lcyBub3QgbWVhbiB0aGF0IGEgdW5pcXVlIGFkZHJlc3MgbXVzdCBiZSBhc3NpZ25lZCB0 byB0aGUgaW50ZXJmYWNlLiBJZiBhIGNsaWVudCBERUNMSU5FcyB0aGUgQURWRVJUSVNFZCBvciBS RVBMSUVkIGFkZHJlc3MsIERIQ1BWNiBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gYWR2ZXJ0aXNl IGFub3RoZXIgYWRkcmVzcy4NCiAgICAgICAgDQogICAgICAgIFRoZSBjbGllbnQgc2hvdWxkIGFs c28gYmUgYWJsZSB0byB0ZWxsIHRoYXQgaXMgZG9lcyBub3Qgd2FudCBhbm90aGVyIGFkZHJlc3Mu IEZvciBleGFtcGxlLCBpZiBSRU5FVy9SRUJJTkQgcmV0dXJucyBhIG5ldyBhZGRyZXNzLCB0aGUg Y2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIERFQ0xJTkUgaXQuDQogICAgICAgIA0KICAgICAgICBS ZWdhcmRzLA0KICAgICAgICBEdXNhbi4NCiAgICAgICAgDQogICAgICAgIC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQogICAgICAgIEZyb206IEJlcm5pZSBWb2x6ICh2b2x6KSBbbWFpbHRvOnZv bHpAY2lzY28uY29tXSANCiAgICAgICAgU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAx NyA1OjI4IFBNDQogICAgICAgIFRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikNCiAgICAgICAgQ2M6 IGRoY3dnDQogICAgICAgIFN1YmplY3Q6IFJFOiBSRkMzMzE1IERFQ0xJTkUgZGVmaW5pdGlvbg0K ICAgICAgICANCiAgICAgICAgSSdtIGNvbmZ1c2VkIC4uLiBhZHZlcnRpc2VkIHZzIGFzc2lnbmVk IGFkZHJlc3Nlcy4gT25jZSBhIFJlcGx5IGlzIHJlY2VpdmVkLCB0aGUgYWRkcmVzcyBpcyBhc3Np Z25lZCAtLSBubyBsb25nZXIgYWR2ZXJ0aXNlZC4NCiAgICAgICAgDQogICAgICAgIERFQ0xJTkUg bWVhbnMgdGhhdCB0aGUgYWRkcmVzcyBpcyBpbiB1c2UuIElmIHRoZSBjbGllbnQgREVDTElORXMg aXQgYW5kIGp1c3QgbWFrZXMgaXQgYXZhaWxhYmxlIGltbWVkaWF0ZWx5LCB0aGUgbmV4dCBjbGll bnQgdG8gZ2V0IHRoYXQgYWRkcmVzcyBhc3NpZ25lZCBhbmQgZG9lcyBEQUQgd2lsbCBhbHNvIGZp bmQgYSBjb25mbGljdCAuLi4gc28gd2hhdOKAmXMgdGhlIHZhbHVlIG9mIHRoYXQuDQogICAgICAg IA0KICAgICAgICBHZW5lcmFsbHksIGRlY2xpbmVkIGFkZHJlc3NlcyBzaG91bGQgbm90IGJlIHVz ZWQgZm9yIGEgd2hpbGUgKHRoYXQgaXMgcG9saWN5IGRlcGVuZGVudCkgc2luY2UgaXQgbWVhbnMg c29tZSBvdGhlciBkZXZpY2UgaXMgdXNpbmcgdGhlIGFkZHJlc3MuDQogICAgICAgIA0KICAgICAg ICANCiAgICAgICAgSSB0aG91Z2h0IHlvdSB3ZXJlIHRyeWluZyB0byBzYXkgYSBEZWNsaW5lIHNl bnQgaW4gcmVzcG9uc2UgdG8gYW4gQWR2ZXJ0aXNlIHdvdWxkIHRlbGwgdGhlIHNlcnZlciAiSSBk b24ndCB3YW50IHRob3NlIGFkZHJlc3NlcyIuIEJ1dCB0aGF0IGlzIG5vdCBtZWFuaW5nZnVsIGFu ZCB3aHkgd291bGQgYSBjbGllbnQgZXZlbiB0cnkgdG8gZG8gdGhhdC4gQWxzbywgYW4gQWR2ZXJ0 aXNlIGlzIGp1c3QgdGhhdCAtLSBhbmQgYWR2ZXJ0aXNlbWVudDsgaXQgaXMgbm90IGEgY29tbWl0 bWVudCB0byBhc3NpZ25lZCB0aG9zZSBhZGRyZXNzZXMgLS0gdGhlIGNsaWVudCBjYW4gb25seSB1 c2UgdGhlIGFkZHJlc3NlcyBpbiB0aGUgUmVwbHkuIChESENQdjQgaXMgYSBiaXQgZGlmZmVyZW50 IGluIHRoaXMgcmVzcGVjdCAtLSB0aGUgYWRkcmVzcyBpbiB0aGUgT2ZmZXIgbXVzdCBiZSBzYW1l IGFzIGluIHRoZSBBY2suIERIQ1B2NiBoYXMgbm8gc3VjaCBoYXJkIHJlcXVpcmVtZW50IC0tIGl0 IHVzdWFsbHkgaXMsIGJ1dCB0aGF0J3Mgbm90IHJlcXVpcmVkLikNCiAgICAgICAgDQogICAgICAg IC0gQmVybmllDQogICAgICAgIA0KICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K ICAgICAgICBGcm9tOiBNdWRyaWMsIER1c2FuIChEdXNhbikgW21haWx0bzpkbXVkcmljQGF2YXlh LmNvbV0gDQogICAgICAgIFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDgsIDIwMTcgNToxOSBQ TQ0KICAgICAgICBUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT4NCiAgICAg ICAgQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4NCiAgICAgICAgU3ViamVjdDogUkU6IFJGQzMz MTUgREVDTElORSBkZWZpbml0aW9uDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgSGkgQmVy bmllLA0KICAgICAgICANCiAgICAgICAgSSBhbSB0YWxraW5nIGFib3V0IERFQ0xJTkUgYWZ0ZXIg UkVQTFkuIFdoYXQgSSBhbSAgcHJvcG9zaW5nIGlzIHRvIHVzZSBERUNMSU5FIGZvciAiSSBkb24n dCB3YW50IHlvdXIgQWR2ZXJ0aXNlZCBhZGRyZXNzKGVzKSIuIEkgdGhpbmsgdGhpcyB3aWxsIGJl IG11Y2ggY2xlYW5lciB0aGVuIHRvIGxldCB0aGUgc2VydmVyIHRpbWVvdXQgdGhlIGFkdmVydGlz ZWQgYWRkcmVzc2VzLCB3aGljaCBjYW4gdGFrZSBsb25nLg0KICAgICAgICANCiAgICAgICAgVGhh bmtzLA0KICAgICAgICANCiAgICAgICAgRHVzYW4NCiAgICAgICAgDQogICAgICAgIC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQogICAgICAgIEZyb206IEJlcm5pZSBWb2x6ICh2b2x6KSBbbWFp bHRvOnZvbHpAY2lzY28uY29tXSANCiAgICAgICAgU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAw OCwgMjAxNyA0OjU3IFBNDQogICAgICAgIFRvOiBNdWRyaWMsIER1c2FuIChEdXNhbik7IOelnuaY jumBlOWTiTsgTGlzaGFuIExpDQogICAgICAgIENjOiBkaGN3Zw0KICAgICAgICBTdWJqZWN0OiBS RTogUkZDMzMxNSBERUNMSU5FIGRlZmluaXRpb24NCiAgICAgICAgDQogICAgICAgIER1c2FuOg0K ICAgICAgICANCiAgICAgICAgREVDTElORSBpcyB1c2VkIGFmdGVyIGEgUkVQTFksIG5vdCBhZnRl ciBhbiBBRFZFUlRJU0UuDQogICAgICAgIA0KICAgICAgICBBIGNsaWVudCBoYXMgbm90IGJlZW4g YXNzaWduZWQgYW4gYWRkcmVzcyB1bnRpbCBpdCByZWNlaXZlcyB0aGUgUkVQTFkgKGF0IHdoaWNo IHBvaW50IGl0IGRvZXMgREFEIGFuZCBtYXkgc2VuZCBhIERFQ0xJTkUpLg0KICAgICAgICANCiAg ICAgICAgVGhlcmUgaXMgbm8gbWVjaGFuaXNtIGZvciBhIGNsaWVudCB0byBpbmRpY2F0ZSB0byBh IHNlcnZlciAiSSBkb24ndCB3YW50IHlvdXIgQWR2ZXJ0aXNlZCBhZGRyZXNzKGVzKSIsIGV4Y2Vw dCBieSBub3QgcHJvY2VlZGluZyB0byBzZW5kIGEgUkVRVUVTVC4NCiAgICAgICAgDQogICAgICAg IFRoZSBzZXJ2ZXIgbWF5IGhhdmUgaGVsZCB0aGUgYWRkcmVzcyAicmVzZXJ2ZWQiIGZvciBhIHNo b3J0IHBlcmlvZCBvZiB0aW1lLCBidXQgZG9lcyB0aGF0IHJlYWxseSBtYXR0ZXI/IElQdjYgYWRk cmVzc2VzIGFyZSBub3QgaW4gc2hvcnQgc3VwcGx5Lg0KICAgICAgICANCiAgICAgICAgLSBCZXJu aWUNCiAgICAgICAgDQogICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgICAg IEZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE11ZHJpYywgRHVzYW4gKER1c2FuKQ0KICAgICAgICBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDA4LCAyMDE3IDQ6NDcgUE0NCiAgICAgICAgVG86IOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUu YWQuanA+OyBMaXNoYW4gTGkgPGxpbGlzaGFuNDhAZ21haWwuY29tPg0KICAgICAgICBDYzogZGhj d2cgPGRoY3dnQGlldGYub3JnPg0KICAgICAgICBTdWJqZWN0OiBbZGhjd2ddIFJGQzMzMTUgREVD TElORSBkZWZpbml0aW9uDQogICAgICAgIA0KICAgICAgICBIaSwNCiAgICAgICAgDQogICAgICAg IENhbiBERUNMSU5FIGRlZmluaXRpb24gYmUgZXh0ZW5kZWQgYmV5b25kIHRoZSBEQUQgdXNhZ2U/ IEkgdGhpbmsgREVDTElORSBzaG91bGQgYmUgdXNlZCBldmVyeSB0aW1lIERIQ1BWNiBjbGllbnQg ZGVjaWRlcyBub3QgdG8gYXNzaWduIHRoZSBvZmZlcmVkIGFkZHJlc3MsIGZvciBhbnkgcmVhc29u LCBub3QganVzdCB0aGUgYWRkcmVzcyBpcyBkdXBsaWNhdGUuIFdoZW4gcmVjZWl2aW5nIERFQ0xJ TkUsIERIQ1BWNiBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gaW1tZWRpYXRlbHkgbWFrZSB0aGUg c2FtZSBhZGRyZXNzIGF2YWlsYWJsZSBpbiB0aGUgYWRkcmVzcyBwb29sIGZvciB0aGUgb3RoZXIg Y2xpZW50cy4NCiAgICAgICAgDQogICAgICAgIFJlZ2FyZHMsDQogICAgICAgIER1c2FuLg0KICAg ICAgICANCiAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICAgICAgZGhjd2cgbWFpbGluZyBsaXN0DQogICAgICAgIGRoY3dnQGlldGYub3Jn DQogICAgICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fZGhjd2cmZD1EUUlGSmcmYz1CRnBX UXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlz TVFHUTJrWSZtPWRTT1pSNGRPdk9JRmxySlVPMHJhOUVhSG9jY3JBakFpV3ljWF9ZNHZuUlEmcz1l NXdLLVdTMDlCSXgwUktEVEJFX2lFZFVscktfYlA2Z3Y0VGZRYU1UUGlVJmU9IA0KICAgICAgICAN CiAgICANCiAgICANCg0K From nobody Thu Feb 9 06:34:42 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36A0129A76 for ; Thu, 9 Feb 2017 06:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 sdv5RU3ZRVcv for ; Thu, 9 Feb 2017 06:34:29 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA6C129A66 for ; Thu, 9 Feb 2017 06:34:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GfAADyfJxY/xUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBBYYEJB4NSigiSCYgMixuCD4FJQyqFeAIaglA/GAECAQEBAQE?= =?us-ascii?q?BAQNfKIJbPQYHLwEBAQEBAQEBAQEBAQEcAg8vEgEBGAEBAQEDEhEROgsMBAIBB?= =?us-ascii?q?gINBAQBAQMCBh0DAgICHxEUAQgIAgQOBQgaiToDFQENkhmSbIpigiUmAocHDYQ?= =?us-ascii?q?KAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELhUKEboE8gRWBbRiDBC6CMQWbODgBh?= =?us-ascii?q?myHCwGGZ4gIhi+FbYRHiF8fOX5PFTyGQnUBAYZAB4EpAYELAQEB?= X-IPAS-Result: =?us-ascii?q?A2GfAADyfJxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?BYYEJB4NSigiSCYgMixuCD4FJQyqFeAIaglA/GAECAQEBAQEBAQNfKIJbPQYHL?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEcAg8vEgEBGAEBAQEDEhEROgsMBAIBBgINBAQBAQMCBh0?= =?us-ascii?q?DAgICHxEUAQgIAgQOBQgaiToDFQENkhmSbIpigiUmAocHDYQKAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYELhUKEboE8gRWBbRiDBC6CMQWbODgBhmyHCwGGZ4gIhi+?= =?us-ascii?q?FbYRHiF8fOX5PFTyGQnUBAYZAB4EpAYELAQEB?= X-IronPort-AV: E=Sophos;i="5.35,349,1484024400"; d="scan'208";a="190077551" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Feb 2017 09:31:54 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 09:31:53 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 09:31:52 -0500 From: "Mudric, Dusan (Dusan)" To: "Bernie Volz (volz)" Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gA= Date: Thu, 9 Feb 2017 14:31:51 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> In-Reply-To: <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:34:40 -0000 SGkgQmVybmllLA0KDQpUaGF0IGlzIHRoZSBjdXJyZW50IHVzZSBvZiBERUNMSU5FIChvbmx5IGZv ciBEQUQpLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzMxNSNzZWN0aW9uLTE3LjEu MyBvbmx5IGZvY3VzZXMgb24gdGhlIHNlcnZlciBzZWxlY3Rpb24gYWZ0ZXIgQURWRVJUSVNFIGlz IHJlY2VpdmVkLiBJdCBkb2VzIG5vdCBtZW50aW9uIHRoYXQgREhDUHY2IGNsaWVudCBtaWdodCBu b3QgYmUgaGFwcHkgd2l0aCB0aGUgYWR2ZXJ0aXNlZCBhZGRyZXNzZXMuIElQdjYgZGVmaW5lcyBk aWZmZXJlbnQga2luZHMgb2YgYWRkcmVzc2VzIGFuZCBhbGxvd3MgbXVsdGlwbGUgYWRkcmVzc2Vz LCBtYWtpbmcgaXQgbW9yZSBjb21wbGV4IHRvIGhhbmRsZS4gSWYgYSBzZXJ2ZXIgb2ZmZXJzIElQ djYgYWRkcmVzcyB0aGF0IGNsaWVudCBjYW5ub3QgdXNlIChlLmcuIGEgbXVsdGljYXN0IGFkZHJl c3MsIGEgc2Vjb25kIGFkZHJlc3MpLCB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIGRlY2xp bmUgaXQuDQoNCkFnYWluLCBpZiB0aGUgc2VydmVyIHNlbmRzIFJFUExZIG9yIFJFQklORCB3aXRo IGFuIGFkZHJlc3MgdGhlIGNsaWVudCBjYW5ub3QgdXNlLCB0aGUgY2xpZW50IHNob3VsZCBiZSBh YmxlIHRvIERFQ0xJTkUgaXQuDQoNCkRFQ0xJTkUgc2hvdWxkIGJlIGRlZmluZWQgYXMgYSByZXNw b25zZSBmb3IgdGhlIGFkZHJlc3NlcyB0aGF0IGNhbm5vdCBiZSBhc3NpZ25lZC4gDQoNClRoZXNl IGFyZSB0aGUgaXNzdWVzIEkgaWRlbnRpZmllZCBkdXJpbmcgREhDUHY2IHRlc3RpbmcgYW5kIGFu YWx5c2lzIGFuZCB0aGV5IG5lZWQgdG8gYmUgYWRkcmVzc2VkIHdpdGggdGhlIG5ldyBkZWZpbml0 aW9uIGZvciBERUNMSU5FLg0KDQpSZWdhcmRzLA0KRHVzYW4uDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBCZXJuaWUgVm9seiAodm9seikgW21haWx0bzp2b2x6QGNpc2NvLmNv bV0gDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDksIDIwMTcgOTowNiBBTQ0KVG86IE11ZHJp YywgRHVzYW4gKER1c2FuKQ0KQ2M6IGRoY3dnDQpTdWJqZWN0OiBSZTogUkZDMzMxNSBERUNMSU5F IGRlZmluaXRpb24NCg0KQWdhaW4sIERFQ0xJTkUgSXMgb25seSBhZnRlciBSRVBMWSByZWNlaXZl ZC4gTm90IEFkdmVydGlzZS4NCg0KLSBCZXJuaWUNCg0KT24gMi85LzE3LCA4OjU3IEFNLCAiTXVk cmljLCBEdXNhbiAoRHVzYW4pIiA8ZG11ZHJpY0BhdmF5YS5jb20+IHdyb3RlOg0KDQogICAgSGkg QmVybmllLA0KICAgIA0KICAgIEkgYWdyZWUgd2l0aCB0aGUgZGVmaW5pdGlvbjogIiBERUNMSU5F IG1lYW5zIGFkZHJlc3MgaXMgYmFkIi4gV2hhdCBJIGFtIHNheWluZyBpcyB0aGF0ICJiYWQiIGRv ZXMgbm90IG9ubHkgbWVhbiAiZHVwbGljYXRlZCIuIEFwcGxpY2F0aW9ucyBhbmQgZGV2aWNlcyBj YW4gaGF2ZSBvdGhlciByZWFzb25zIHRvIHRoaW5nIGFib3V0IHRoZSBvZmZlcmVkIGFkZHJlc3Mg dG8gYmUgImJhZCIuIElmIHRoZXkgZmluZCB0aGUgYWRkcmVzcyAgaXMgImJhZCIgZm9yIGFueSBy ZWFzb24sIHRoZXkgY2FuIHNlbmQgREVDTElORS4gRXZlbiB0aGUgY3VycmVudCBESENQdjYgcHJv dG9jb2wgZG9lcyBub3QgcHJldmVudCB0aGUgREhDUHY2IGNsaWVudCB0byBzZW5kIERFQ0xJTkUg Zm9yIEFEVkVSVElTRSBhbmQgUkVQTFkuIEl0IGlzIHRoZSBzZXJ2ZXIgdGhhdCBzaG91bGQgdXNl IGl0IGVmZmljaWVudGx5Lg0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgRHVzYW4uDQogICAgDQog ICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBCZXJuaWUgVm9seiAodm9s eikgW21haWx0bzp2b2x6QGNpc2NvLmNvbV0gDQogICAgU2VudDogV2VkbmVzZGF5LCBGZWJydWFy eSAwOCwgMjAxNyA1OjUyIFBNDQogICAgVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKQ0KICAgIENj OiBkaGN3Zw0KICAgIFN1YmplY3Q6IFJFOiBSRkMzMzE1IERFQ0xJTkUgZGVmaW5pdGlvbg0KICAg IA0KICAgIE5vLg0KICAgIA0KICAgIERFQ0xJTkUgbWVhbnMgYWRkcmVzcyBpcyBiYWQgKGR1cGxp Y2F0ZWQpLiBERUNMSU5FIGlzIG9ubHkgdmFsaWQgYWZ0ZXIgUmVwbHksIG5vdCBhZnRlciBBZHZl cnRpc2UuIA0KICAgIA0KICAgIFJFTEVBU0UgbWVhbnMgY2xpZW50IGRvZXMgbm90IHdhbnQgdG8g dXNlIHRoZSBhZGRyZXNzIHByb3ZpZGVkLg0KICAgIA0KICAgIEkgZG9uJ3Qgc2VlIGFueSBiZW5l Zml0IHRvIGNoYW5nZSB0aGlzLg0KICAgIA0KICAgIC0gQmVybmllDQogICAgDQogICAgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBNdWRyaWMsIER1c2FuIChEdXNhbikgW21h aWx0bzpkbXVkcmljQGF2YXlhLmNvbV0gDQogICAgU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAw OCwgMjAxNyA1OjM4IFBNDQogICAgVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5j b20+DQogICAgQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4NCiAgICBTdWJqZWN0OiBSRTogUkZD MzMxNSBERUNMSU5FIGRlZmluaXRpb24NCiAgICANCiAgICBVbmRlcnN0YW5kIHRoZSBjb25jZXJu LiBUaGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIERFQ0xJTkUgYWRkcmVzc2VzIGluIGJvdGgg QURWRVJUSVNFIGFuZCBSRVBMWS4gUmVjZWl2aW5nIHRoZSBSRVBMWSBkb2VzIG5vdCBtZWFuIHRo YXQgYSB1bmlxdWUgYWRkcmVzcyBtdXN0IGJlIGFzc2lnbmVkIHRvIHRoZSBpbnRlcmZhY2UuIElm IGEgY2xpZW50IERFQ0xJTkVzIHRoZSBBRFZFUlRJU0VkIG9yIFJFUExJRWQgYWRkcmVzcywgREhD UFY2IHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byBhZHZlcnRpc2UgYW5vdGhlciBhZGRyZXNzLg0K ICAgIA0KICAgIFRoZSBjbGllbnQgc2hvdWxkIGFsc28gYmUgYWJsZSB0byB0ZWxsIHRoYXQgaXMg ZG9lcyBub3Qgd2FudCBhbm90aGVyIGFkZHJlc3MuIEZvciBleGFtcGxlLCBpZiBSRU5FVy9SRUJJ TkQgcmV0dXJucyBhIG5ldyBhZGRyZXNzLCB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIERF Q0xJTkUgaXQuDQogICAgDQogICAgUmVnYXJkcywNCiAgICBEdXNhbi4NCiAgICANCiAgICAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IEJlcm5pZSBWb2x6ICh2b2x6KSBbbWFp bHRvOnZvbHpAY2lzY28uY29tXSANCiAgICBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAy MDE3IDU6MjggUE0NCiAgICBUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pDQogICAgQ2M6IGRoY3dn DQogICAgU3ViamVjdDogUkU6IFJGQzMzMTUgREVDTElORSBkZWZpbml0aW9uDQogICAgDQogICAg SSdtIGNvbmZ1c2VkIC4uLiBhZHZlcnRpc2VkIHZzIGFzc2lnbmVkIGFkZHJlc3Nlcy4gT25jZSBh IFJlcGx5IGlzIHJlY2VpdmVkLCB0aGUgYWRkcmVzcyBpcyBhc3NpZ25lZCAtLSBubyBsb25nZXIg YWR2ZXJ0aXNlZC4NCiAgICANCiAgICBERUNMSU5FIG1lYW5zIHRoYXQgdGhlIGFkZHJlc3MgaXMg aW4gdXNlLiBJZiB0aGUgY2xpZW50IERFQ0xJTkVzIGl0IGFuZCBqdXN0IG1ha2VzIGl0IGF2YWls YWJsZSBpbW1lZGlhdGVseSwgdGhlIG5leHQgY2xpZW50IHRvIGdldCB0aGF0IGFkZHJlc3MgYXNz aWduZWQgYW5kIGRvZXMgREFEIHdpbGwgYWxzbyBmaW5kIGEgY29uZmxpY3QgLi4uIHNvIHdoYXTi gJlzIHRoZSB2YWx1ZSBvZiB0aGF0Lg0KICAgIA0KICAgIEdlbmVyYWxseSwgZGVjbGluZWQgYWRk cmVzc2VzIHNob3VsZCBub3QgYmUgdXNlZCBmb3IgYSB3aGlsZSAodGhhdCBpcyBwb2xpY3kgZGVw ZW5kZW50KSBzaW5jZSBpdCBtZWFucyBzb21lIG90aGVyIGRldmljZSBpcyB1c2luZyB0aGUgYWRk cmVzcy4NCiAgICANCiAgICANCiAgICBJIHRob3VnaHQgeW91IHdlcmUgdHJ5aW5nIHRvIHNheSBh IERlY2xpbmUgc2VudCBpbiByZXNwb25zZSB0byBhbiBBZHZlcnRpc2Ugd291bGQgdGVsbCB0aGUg c2VydmVyICJJIGRvbid0IHdhbnQgdGhvc2UgYWRkcmVzc2VzIi4gQnV0IHRoYXQgaXMgbm90IG1l YW5pbmdmdWwgYW5kIHdoeSB3b3VsZCBhIGNsaWVudCBldmVuIHRyeSB0byBkbyB0aGF0LiBBbHNv LCBhbiBBZHZlcnRpc2UgaXMganVzdCB0aGF0IC0tIGFuZCBhZHZlcnRpc2VtZW50OyBpdCBpcyBu b3QgYSBjb21taXRtZW50IHRvIGFzc2lnbmVkIHRob3NlIGFkZHJlc3NlcyAtLSB0aGUgY2xpZW50 IGNhbiBvbmx5IHVzZSB0aGUgYWRkcmVzc2VzIGluIHRoZSBSZXBseS4gKERIQ1B2NCBpcyBhIGJp dCBkaWZmZXJlbnQgaW4gdGhpcyByZXNwZWN0IC0tIHRoZSBhZGRyZXNzIGluIHRoZSBPZmZlciBt dXN0IGJlIHNhbWUgYXMgaW4gdGhlIEFjay4gREhDUHY2IGhhcyBubyBzdWNoIGhhcmQgcmVxdWly ZW1lbnQgLS0gaXQgdXN1YWxseSBpcywgYnV0IHRoYXQncyBub3QgcmVxdWlyZWQuKQ0KICAgIA0K ICAgIC0gQmVybmllDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBG cm9tOiBNdWRyaWMsIER1c2FuIChEdXNhbikgW21haWx0bzpkbXVkcmljQGF2YXlhLmNvbV0gDQog ICAgU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyA1OjE5IFBNDQogICAgVG86IEJl cm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+DQogICAgQ2M6IGRoY3dnIDxkaGN3Z0Bp ZXRmLm9yZz4NCiAgICBTdWJqZWN0OiBSRTogUkZDMzMxNSBERUNMSU5FIGRlZmluaXRpb24NCiAg ICANCiAgICANCiAgICBIaSBCZXJuaWUsDQogICAgDQogICAgSSBhbSB0YWxraW5nIGFib3V0IERF Q0xJTkUgYWZ0ZXIgUkVQTFkuIFdoYXQgSSBhbSAgcHJvcG9zaW5nIGlzIHRvIHVzZSBERUNMSU5F IGZvciAiSSBkb24ndCB3YW50IHlvdXIgQWR2ZXJ0aXNlZCBhZGRyZXNzKGVzKSIuIEkgdGhpbmsg dGhpcyB3aWxsIGJlIG11Y2ggY2xlYW5lciB0aGVuIHRvIGxldCB0aGUgc2VydmVyIHRpbWVvdXQg dGhlIGFkdmVydGlzZWQgYWRkcmVzc2VzLCB3aGljaCBjYW4gdGFrZSBsb25nLg0KICAgIA0KICAg IFRoYW5rcywNCiAgICANCiAgICBEdXNhbg0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQogICAgRnJvbTogQmVybmllIFZvbHogKHZvbHopIFttYWlsdG86dm9sekBjaXNjby5j b21dIA0KICAgIFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDgsIDIwMTcgNDo1NyBQTQ0KICAg IFRvOiBNdWRyaWMsIER1c2FuIChEdXNhbik7IOelnuaYjumBlOWTiTsgTGlzaGFuIExpDQogICAg Q2M6IGRoY3dnDQogICAgU3ViamVjdDogUkU6IFJGQzMzMTUgREVDTElORSBkZWZpbml0aW9uDQog ICAgDQogICAgRHVzYW46DQogICAgDQogICAgREVDTElORSBpcyB1c2VkIGFmdGVyIGEgUkVQTFks IG5vdCBhZnRlciBhbiBBRFZFUlRJU0UuDQogICAgDQogICAgQSBjbGllbnQgaGFzIG5vdCBiZWVu IGFzc2lnbmVkIGFuIGFkZHJlc3MgdW50aWwgaXQgcmVjZWl2ZXMgdGhlIFJFUExZIChhdCB3aGlj aCBwb2ludCBpdCBkb2VzIERBRCBhbmQgbWF5IHNlbmQgYSBERUNMSU5FKS4NCiAgICANCiAgICBU aGVyZSBpcyBubyBtZWNoYW5pc20gZm9yIGEgY2xpZW50IHRvIGluZGljYXRlIHRvIGEgc2VydmVy ICJJIGRvbid0IHdhbnQgeW91ciBBZHZlcnRpc2VkIGFkZHJlc3MoZXMpIiwgZXhjZXB0IGJ5IG5v dCBwcm9jZWVkaW5nIHRvIHNlbmQgYSBSRVFVRVNULg0KICAgIA0KICAgIFRoZSBzZXJ2ZXIgbWF5 IGhhdmUgaGVsZCB0aGUgYWRkcmVzcyAicmVzZXJ2ZWQiIGZvciBhIHNob3J0IHBlcmlvZCBvZiB0 aW1lLCBidXQgZG9lcyB0aGF0IHJlYWxseSBtYXR0ZXI/IElQdjYgYWRkcmVzc2VzIGFyZSBub3Qg aW4gc2hvcnQgc3VwcGx5Lg0KICAgIA0KICAgIC0gQmVybmllDQogICAgDQogICAgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBkaGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNdWRyaWMsIER1c2FuIChEdXNhbikNCiAgICBTZW50OiBX ZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDE3IDQ6NDcgUE0NCiAgICBUbzog56We5piO6YGU5ZOJ IDxqaW5tZWlAd2lkZS5hZC5qcD47IExpc2hhbiBMaSA8bGlsaXNoYW40OEBnbWFpbC5jb20+DQog ICAgQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4NCiAgICBTdWJqZWN0OiBbZGhjd2ddIFJGQzMz MTUgREVDTElORSBkZWZpbml0aW9uDQogICAgDQogICAgSGksDQogICAgDQogICAgQ2FuIERFQ0xJ TkUgZGVmaW5pdGlvbiBiZSBleHRlbmRlZCBiZXlvbmQgdGhlIERBRCB1c2FnZT8gSSB0aGluayBE RUNMSU5FIHNob3VsZCBiZSB1c2VkIGV2ZXJ5IHRpbWUgREhDUFY2IGNsaWVudCBkZWNpZGVzIG5v dCB0byBhc3NpZ24gdGhlIG9mZmVyZWQgYWRkcmVzcywgZm9yIGFueSByZWFzb24sIG5vdCBqdXN0 IHRoZSBhZGRyZXNzIGlzIGR1cGxpY2F0ZS4gV2hlbiByZWNlaXZpbmcgREVDTElORSwgREhDUFY2 IHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byBpbW1lZGlhdGVseSBtYWtlIHRoZSBzYW1lIGFkZHJl c3MgYXZhaWxhYmxlIGluIHRoZSBhZGRyZXNzIHBvb2wgZm9yIHRoZSBvdGhlciBjbGllbnRzLg0K ICAgIA0KICAgIFJlZ2FyZHMsDQogICAgRHVzYW4uDQogICAgDQogICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBkaGN3ZyBtYWlsaW5nIGxpc3QN CiAgICBkaGN3Z0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fZGhjd2cm ZD1EUUlGSmcmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJ b1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPWRTT1pSNGRPdk9JRmxySlVPMHJhOUVhSG9jY3JBakFp V3ljWF9ZNHZuUlEmcz1lNXdLLVdTMDlCSXgwUktEVEJFX2lFZFVscktfYlA2Z3Y0VGZRYU1UUGlV JmU9IA0KICAgIA0KDQo= From nobody Thu Feb 9 06:41:54 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237D0129A87 for ; Thu, 9 Feb 2017 06:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 f1YmDqsFQBPD for ; Thu, 9 Feb 2017 06:41:52 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790E0129A3D for ; Thu, 9 Feb 2017 06:41:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GfAAAff5xY/yYyC4ddGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBBYYEJB4NSigiSCYgMixuCD4FJQyaFfAIaglA/GAECAQEBAQE?= =?us-ascii?q?BAQNfKIJbPQYHLwEBAQEBAQEBAQEBAQEcAg9BAQEYAQEBAQMSERE6CwwEAgEGA?= =?us-ascii?q?g0EBAEBAwIGHQMCAgIfERQBCAgCBA4FCBqJOgMVAZInkmyKYoIlJgKHCA2ECgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VChG6BPIEVgW0YgwQugjEFlVSFZDgBh?= =?us-ascii?q?myHCwGGZ4gIhi+FbYRHiF8fOX5PFTyGQnWGQgeBKQGBCwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2GfAAAff5xY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?BYYEJB4NSigiSCYgMixuCD4FJQyaFfAIaglA/GAECAQEBAQEBAQNfKIJbPQYHL?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEcAg9BAQEYAQEBAQMSERE6CwwEAgEGAg0EBAEBAwIGHQM?= =?us-ascii?q?CAgIfERQBCAgCBA4FCBqJOgMVAZInkmyKYoIlJgKHCA2ECgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BC4VChG6BPIEVgW0YgwQugjEFlVSFZDgBhmyHCwGGZ4gIhi+?= =?us-ascii?q?FbYRHiF8fOX5PFTyGQnWGQgeBKQGBCwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,349,1484024400"; d="scan'208";a="227422404" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Feb 2017 09:41:51 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 09:41:51 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 09:41:50 -0500 From: "Mudric, Dusan (Dusan)" To: "Bernie Volz (volz)" Thread-Topic: RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9w Date: Thu, 9 Feb 2017 14:41:47 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> In-Reply-To: <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:41:54 -0000 SG93IGNhbiBJIGNvbnRyaWJ1dGUgdG8gUkZDMzMxNWJpcz8gV2hhdCBpcyB0aGUgcHJvY2Vzcz8N Cg0KVGhhbmtzLA0KRHVzYW4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBC ZXJuaWUgVm9seiAodm9seikgW21haWx0bzp2b2x6QGNpc2NvLmNvbV0gDQpTZW50OiBUaHVyc2Rh eSwgRmVicnVhcnkgMDksIDIwMTcgOTozNCBBTQ0KVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKQ0K Q2M6IGRoY3dnDQpTdWJqZWN0OiBSZTogUkZDMzMxNSBERUNMSU5FIGRlZmluaXRpb24NCg0KSSBh bSBnb2luZyB0byBnaXZlIHVwIG9uIHRoaXMgZGViYXRlIHdpdGggeW91Lg0KDQoNCg0KVGhlcmUg YXJlIG5vIHBsYW5zIHRvIGNoYW5nZSBhbnkgb2YgdGhpcy4gUGVyaGFwcyBhbm90aGVyIFJGQzMz MTViaXMgYXV0aG9yIHdpbGwgdGFrZSB0aGlzIHVwIHdpdGggeW91Lg0KDQoNCg0KLSBCZXJuaWUN Cg0KDQoNCk9uIDIvOS8xNywgOTozMSBBTSwgIk11ZHJpYywgRHVzYW4gKER1c2FuKSIgPGRtdWRy aWNAYXZheWEuY29tPiB3cm90ZToNCg0KDQoNCiAgICBIaSBCZXJuaWUsDQoNCiAgICANCg0KICAg IFRoYXQgaXMgdGhlIGN1cnJlbnQgdXNlIG9mIERFQ0xJTkUgKG9ubHkgZm9yIERBRCkuIGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0 Zi5vcmdfaHRtbF9yZmMzMzE1LTIzc2VjdGlvbi0yRDE3LjEuMyZkPURRSUdhUSZjPUJGcFdRdzhi c3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdR MmtZJm09dmExSDNzWTBuWmZkSGM0REdGQ1VLQmliT3ZPYTRMUEljMW9jVUFudVNHRSZzPV94Sm4w cTR6cVg5TEk1cVZKbnRPb0lhS2toZDdUTEF2N084TzNTbVFUT1EmZT0gIG9ubHkgZm9jdXNlcyBv biB0aGUgc2VydmVyIHNlbGVjdGlvbiBhZnRlciBBRFZFUlRJU0UgaXMgcmVjZWl2ZWQuIEl0IGRv ZXMgbm90IG1lbnRpb24gdGhhdCBESENQdjYgY2xpZW50IG1pZ2h0IG5vdCBiZSBoYXBweSB3aXRo IHRoZSBhZHZlcnRpc2VkIGFkZHJlc3Nlcy4gSVB2NiBkZWZpbmVzIGRpZmZlcmVudCBraW5kcyBv ZiBhZGRyZXNzZXMgYW5kIGFsbG93cyBtdWx0aXBsZSBhZGRyZXNzZXMsIG1ha2luZyBpdCBtb3Jl IGNvbXBsZXggdG8gaGFuZGxlLiBJZiBhIHNlcnZlciBvZmZlcnMgSVB2NiBhZGRyZXNzIHRoYXQg Y2xpZW50IGNhbm5vdCB1c2UgKGUuZy4gYSBtdWx0aWNhc3QgYWRkcmVzcywgYSBzZWNvbmQgYWRk cmVzcyksIHRoZSBjbGllbnQgc2hvdWxkIGJlIGFibGUgdG8gZGVjbGluZSBpdC4NCg0KICAgIA0K DQogICAgQWdhaW4sIGlmIHRoZSBzZXJ2ZXIgc2VuZHMgUkVQTFkgb3IgUkVCSU5EIHdpdGggYW4g YWRkcmVzcyB0aGUgY2xpZW50IGNhbm5vdCB1c2UsIHRoZSBjbGllbnQgc2hvdWxkIGJlIGFibGUg dG8gREVDTElORSBpdC4NCg0KICAgIA0KDQogICAgREVDTElORSBzaG91bGQgYmUgZGVmaW5lZCBh cyBhIHJlc3BvbnNlIGZvciB0aGUgYWRkcmVzc2VzIHRoYXQgY2Fubm90IGJlIGFzc2lnbmVkLiAN Cg0KICAgIA0KDQogICAgVGhlc2UgYXJlIHRoZSBpc3N1ZXMgSSBpZGVudGlmaWVkIGR1cmluZyBE SENQdjYgdGVzdGluZyBhbmQgYW5hbHlzaXMgYW5kIHRoZXkgbmVlZCB0byBiZSBhZGRyZXNzZWQg d2l0aCB0aGUgbmV3IGRlZmluaXRpb24gZm9yIERFQ0xJTkUuDQoNCiAgICANCg0KICAgIFJlZ2Fy ZHMsDQoNCiAgICBEdXNhbi4NCg0KICAgIA0KDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCg0KICAgIEZyb206IEJlcm5pZSBWb2x6ICh2b2x6KSBbbWFpbHRvOnZvbHpAY2lzY28uY29t XSANCg0KICAgIFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyA5OjA2IEFNDQoNCiAg ICBUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pDQoNCiAgICBDYzogZGhjd2cNCg0KICAgIFN1Ympl Y3Q6IFJlOiBSRkMzMzE1IERFQ0xJTkUgZGVmaW5pdGlvbg0KDQogICAgDQoNCiAgICBBZ2Fpbiwg REVDTElORSBJcyBvbmx5IGFmdGVyIFJFUExZIHJlY2VpdmVkLiBOb3QgQWR2ZXJ0aXNlLg0KDQog ICAgDQoNCiAgICAtIEJlcm5pZQ0KDQogICAgDQoNCiAgICBPbiAyLzkvMTcsIDg6NTcgQU0sICJN dWRyaWMsIER1c2FuIChEdXNhbikiIDxkbXVkcmljQGF2YXlhLmNvbT4gd3JvdGU6DQoNCiAgICAN Cg0KICAgICAgICBIaSBCZXJuaWUsDQoNCiAgICAgICAgDQoNCiAgICAgICAgSSBhZ3JlZSB3aXRo IHRoZSBkZWZpbml0aW9uOiAiIERFQ0xJTkUgbWVhbnMgYWRkcmVzcyBpcyBiYWQiLiBXaGF0IEkg YW0gc2F5aW5nIGlzIHRoYXQgImJhZCIgZG9lcyBub3Qgb25seSBtZWFuICJkdXBsaWNhdGVkIi4g QXBwbGljYXRpb25zIGFuZCBkZXZpY2VzIGNhbiBoYXZlIG90aGVyIHJlYXNvbnMgdG8gdGhpbmcg YWJvdXQgdGhlIG9mZmVyZWQgYWRkcmVzcyB0byBiZSAiYmFkIi4gSWYgdGhleSBmaW5kIHRoZSBh ZGRyZXNzICBpcyAiYmFkIiBmb3IgYW55IHJlYXNvbiwgdGhleSBjYW4gc2VuZCBERUNMSU5FLiBF dmVuIHRoZSBjdXJyZW50IERIQ1B2NiBwcm90b2NvbCBkb2VzIG5vdCBwcmV2ZW50IHRoZSBESENQ djYgY2xpZW50IHRvIHNlbmQgREVDTElORSBmb3IgQURWRVJUSVNFIGFuZCBSRVBMWS4gSXQgaXMg dGhlIHNlcnZlciB0aGF0IHNob3VsZCB1c2UgaXQgZWZmaWNpZW50bHkuDQoNCiAgICAgICAgDQoN CiAgICAgICAgUmVnYXJkcywNCg0KICAgICAgICBEdXNhbi4NCg0KICAgICAgICANCg0KICAgICAg ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQogICAgICAgIEZyb206IEJlcm5pZSBWb2x6 ICh2b2x6KSBbbWFpbHRvOnZvbHpAY2lzY28uY29tXSANCg0KICAgICAgICBTZW50OiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDA4LCAyMDE3IDU6NTIgUE0NCg0KICAgICAgICBUbzogTXVkcmljLCBEdXNh biAoRHVzYW4pDQoNCiAgICAgICAgQ2M6IGRoY3dnDQoNCiAgICAgICAgU3ViamVjdDogUkU6IFJG QzMzMTUgREVDTElORSBkZWZpbml0aW9uDQoNCiAgICAgICAgDQoNCiAgICAgICAgTm8uDQoNCiAg ICAgICAgDQoNCiAgICAgICAgREVDTElORSBtZWFucyBhZGRyZXNzIGlzIGJhZCAoZHVwbGljYXRl ZCkuIERFQ0xJTkUgaXMgb25seSB2YWxpZCBhZnRlciBSZXBseSwgbm90IGFmdGVyIEFkdmVydGlz ZS4gDQoNCiAgICAgICAgDQoNCiAgICAgICAgUkVMRUFTRSBtZWFucyBjbGllbnQgZG9lcyBub3Qg d2FudCB0byB1c2UgdGhlIGFkZHJlc3MgcHJvdmlkZWQuDQoNCiAgICAgICAgDQoNCiAgICAgICAg SSBkb24ndCBzZWUgYW55IGJlbmVmaXQgdG8gY2hhbmdlIHRoaXMuDQoNCiAgICAgICAgDQoNCiAg ICAgICAgLSBCZXJuaWUNCg0KICAgICAgICANCg0KICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KDQogICAgICAgIEZyb206IE11ZHJpYywgRHVzYW4gKER1c2FuKSBbbWFpbHRvOmRt dWRyaWNAYXZheWEuY29tXSANCg0KICAgICAgICBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4 LCAyMDE3IDU6MzggUE0NCg0KICAgICAgICBUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNp c2NvLmNvbT4NCg0KICAgICAgICBDYzogZGhjd2cgPGRoY3dnQGlldGYub3JnPg0KDQogICAgICAg IFN1YmplY3Q6IFJFOiBSRkMzMzE1IERFQ0xJTkUgZGVmaW5pdGlvbg0KDQogICAgICAgIA0KDQog ICAgICAgIFVuZGVyc3RhbmQgdGhlIGNvbmNlcm4uIFRoZSBjbGllbnQgc2hvdWxkIGJlIGFibGUg dG8gREVDTElORSBhZGRyZXNzZXMgaW4gYm90aCBBRFZFUlRJU0UgYW5kIFJFUExZLiBSZWNlaXZp bmcgdGhlIFJFUExZIGRvZXMgbm90IG1lYW4gdGhhdCBhIHVuaXF1ZSBhZGRyZXNzIG11c3QgYmUg YXNzaWduZWQgdG8gdGhlIGludGVyZmFjZS4gSWYgYSBjbGllbnQgREVDTElORXMgdGhlIEFEVkVS VElTRWQgb3IgUkVQTElFZCBhZGRyZXNzLCBESENQVjYgc2VydmVyIHNob3VsZCBiZSBhYmxlIHRv IGFkdmVydGlzZSBhbm90aGVyIGFkZHJlc3MuDQoNCiAgICAgICAgDQoNCiAgICAgICAgVGhlIGNs aWVudCBzaG91bGQgYWxzbyBiZSBhYmxlIHRvIHRlbGwgdGhhdCBpcyBkb2VzIG5vdCB3YW50IGFu b3RoZXIgYWRkcmVzcy4gRm9yIGV4YW1wbGUsIGlmIFJFTkVXL1JFQklORCByZXR1cm5zIGEgbmV3 IGFkZHJlc3MsIHRoZSBjbGllbnQgc2hvdWxkIGJlIGFibGUgdG8gREVDTElORSBpdC4NCg0KICAg ICAgICANCg0KICAgICAgICBSZWdhcmRzLA0KDQogICAgICAgIER1c2FuLg0KDQogICAgICAgIA0K DQogICAgICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCiAgICAgICAgRnJvbTogQmVy bmllIFZvbHogKHZvbHopIFttYWlsdG86dm9sekBjaXNjby5jb21dIA0KDQogICAgICAgIFNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMDgsIDIwMTcgNToyOCBQTQ0KDQogICAgICAgIFRvOiBNdWRy aWMsIER1c2FuIChEdXNhbikNCg0KICAgICAgICBDYzogZGhjd2cNCg0KICAgICAgICBTdWJqZWN0 OiBSRTogUkZDMzMxNSBERUNMSU5FIGRlZmluaXRpb24NCg0KICAgICAgICANCg0KICAgICAgICBJ J20gY29uZnVzZWQgLi4uIGFkdmVydGlzZWQgdnMgYXNzaWduZWQgYWRkcmVzc2VzLiBPbmNlIGEg UmVwbHkgaXMgcmVjZWl2ZWQsIHRoZSBhZGRyZXNzIGlzIGFzc2lnbmVkIC0tIG5vIGxvbmdlciBh ZHZlcnRpc2VkLg0KDQogICAgICAgIA0KDQogICAgICAgIERFQ0xJTkUgbWVhbnMgdGhhdCB0aGUg YWRkcmVzcyBpcyBpbiB1c2UuIElmIHRoZSBjbGllbnQgREVDTElORXMgaXQgYW5kIGp1c3QgbWFr ZXMgaXQgYXZhaWxhYmxlIGltbWVkaWF0ZWx5LCB0aGUgbmV4dCBjbGllbnQgdG8gZ2V0IHRoYXQg YWRkcmVzcyBhc3NpZ25lZCBhbmQgZG9lcyBEQUQgd2lsbCBhbHNvIGZpbmQgYSBjb25mbGljdCAu Li4gc28gd2hhdOKAmXMgdGhlIHZhbHVlIG9mIHRoYXQuDQoNCiAgICAgICAgDQoNCiAgICAgICAg R2VuZXJhbGx5LCBkZWNsaW5lZCBhZGRyZXNzZXMgc2hvdWxkIG5vdCBiZSB1c2VkIGZvciBhIHdo aWxlICh0aGF0IGlzIHBvbGljeSBkZXBlbmRlbnQpIHNpbmNlIGl0IG1lYW5zIHNvbWUgb3RoZXIg ZGV2aWNlIGlzIHVzaW5nIHRoZSBhZGRyZXNzLg0KDQogICAgICAgIA0KDQogICAgICAgIA0KDQog ICAgICAgIEkgdGhvdWdodCB5b3Ugd2VyZSB0cnlpbmcgdG8gc2F5IGEgRGVjbGluZSBzZW50IGlu IHJlc3BvbnNlIHRvIGFuIEFkdmVydGlzZSB3b3VsZCB0ZWxsIHRoZSBzZXJ2ZXIgIkkgZG9uJ3Qg d2FudCB0aG9zZSBhZGRyZXNzZXMiLiBCdXQgdGhhdCBpcyBub3QgbWVhbmluZ2Z1bCBhbmQgd2h5 IHdvdWxkIGEgY2xpZW50IGV2ZW4gdHJ5IHRvIGRvIHRoYXQuIEFsc28sIGFuIEFkdmVydGlzZSBp cyBqdXN0IHRoYXQgLS0gYW5kIGFkdmVydGlzZW1lbnQ7IGl0IGlzIG5vdCBhIGNvbW1pdG1lbnQg dG8gYXNzaWduZWQgdGhvc2UgYWRkcmVzc2VzIC0tIHRoZSBjbGllbnQgY2FuIG9ubHkgdXNlIHRo ZSBhZGRyZXNzZXMgaW4gdGhlIFJlcGx5LiAoREhDUHY0IGlzIGEgYml0IGRpZmZlcmVudCBpbiB0 aGlzIHJlc3BlY3QgLS0gdGhlIGFkZHJlc3MgaW4gdGhlIE9mZmVyIG11c3QgYmUgc2FtZSBhcyBp biB0aGUgQWNrLiBESENQdjYgaGFzIG5vIHN1Y2ggaGFyZCByZXF1aXJlbWVudCAtLSBpdCB1c3Vh bGx5IGlzLCBidXQgdGhhdCdzIG5vdCByZXF1aXJlZC4pDQoNCiAgICAgICAgDQoNCiAgICAgICAg LSBCZXJuaWUNCg0KICAgICAgICANCg0KICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KDQogICAgICAgIEZyb206IE11ZHJpYywgRHVzYW4gKER1c2FuKSBbbWFpbHRvOmRtdWRyaWNA YXZheWEuY29tXSANCg0KICAgICAgICBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDE3 IDU6MTkgUE0NCg0KICAgICAgICBUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNv bT4NCg0KICAgICAgICBDYzogZGhjd2cgPGRoY3dnQGlldGYub3JnPg0KDQogICAgICAgIFN1Ympl Y3Q6IFJFOiBSRkMzMzE1IERFQ0xJTkUgZGVmaW5pdGlvbg0KDQogICAgICAgIA0KDQogICAgICAg IA0KDQogICAgICAgIEhpIEJlcm5pZSwNCg0KICAgICAgICANCg0KICAgICAgICBJIGFtIHRhbGtp bmcgYWJvdXQgREVDTElORSBhZnRlciBSRVBMWS4gV2hhdCBJIGFtICBwcm9wb3NpbmcgaXMgdG8g dXNlIERFQ0xJTkUgZm9yICJJIGRvbid0IHdhbnQgeW91ciBBZHZlcnRpc2VkIGFkZHJlc3MoZXMp Ii4gSSB0aGluayB0aGlzIHdpbGwgYmUgbXVjaCBjbGVhbmVyIHRoZW4gdG8gbGV0IHRoZSBzZXJ2 ZXIgdGltZW91dCB0aGUgYWR2ZXJ0aXNlZCBhZGRyZXNzZXMsIHdoaWNoIGNhbiB0YWtlIGxvbmcu DQoNCiAgICAgICAgDQoNCiAgICAgICAgVGhhbmtzLA0KDQogICAgICAgIA0KDQogICAgICAgIER1 c2FuDQoNCiAgICAgICAgDQoNCiAgICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0K ICAgICAgICBGcm9tOiBCZXJuaWUgVm9seiAodm9seikgW21haWx0bzp2b2x6QGNpc2NvLmNvbV0g DQoNCiAgICAgICAgU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyA0OjU3IFBNDQoN CiAgICAgICAgVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKTsg56We5piO6YGU5ZOJOyBMaXNoYW4g TGkNCg0KICAgICAgICBDYzogZGhjd2cNCg0KICAgICAgICBTdWJqZWN0OiBSRTogUkZDMzMxNSBE RUNMSU5FIGRlZmluaXRpb24NCg0KICAgICAgICANCg0KICAgICAgICBEdXNhbjoNCg0KICAgICAg ICANCg0KICAgICAgICBERUNMSU5FIGlzIHVzZWQgYWZ0ZXIgYSBSRVBMWSwgbm90IGFmdGVyIGFu IEFEVkVSVElTRS4NCg0KICAgICAgICANCg0KICAgICAgICBBIGNsaWVudCBoYXMgbm90IGJlZW4g YXNzaWduZWQgYW4gYWRkcmVzcyB1bnRpbCBpdCByZWNlaXZlcyB0aGUgUkVQTFkgKGF0IHdoaWNo IHBvaW50IGl0IGRvZXMgREFEIGFuZCBtYXkgc2VuZCBhIERFQ0xJTkUpLg0KDQogICAgICAgIA0K DQogICAgICAgIFRoZXJlIGlzIG5vIG1lY2hhbmlzbSBmb3IgYSBjbGllbnQgdG8gaW5kaWNhdGUg dG8gYSBzZXJ2ZXIgIkkgZG9uJ3Qgd2FudCB5b3VyIEFkdmVydGlzZWQgYWRkcmVzcyhlcykiLCBl eGNlcHQgYnkgbm90IHByb2NlZWRpbmcgdG8gc2VuZCBhIFJFUVVFU1QuDQoNCiAgICAgICAgDQoN CiAgICAgICAgVGhlIHNlcnZlciBtYXkgaGF2ZSBoZWxkIHRoZSBhZGRyZXNzICJyZXNlcnZlZCIg Zm9yIGEgc2hvcnQgcGVyaW9kIG9mIHRpbWUsIGJ1dCBkb2VzIHRoYXQgcmVhbGx5IG1hdHRlcj8g SVB2NiBhZGRyZXNzZXMgYXJlIG5vdCBpbiBzaG9ydCBzdXBwbHkuDQoNCiAgICAgICAgDQoNCiAg ICAgICAgLSBCZXJuaWUNCg0KICAgICAgICANCg0KICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KDQogICAgICAgIEZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIE11ZHJpYywgRHVzYW4gKER1c2FuKQ0KDQogICAgICAgIFNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMDgsIDIwMTcgNDo0NyBQTQ0KDQogICAgICAgIFRvOiDnpZ7m mI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPjsgTGlzaGFuIExpIDxsaWxpc2hhbjQ4QGdtYWls LmNvbT4NCg0KICAgICAgICBDYzogZGhjd2cgPGRoY3dnQGlldGYub3JnPg0KDQogICAgICAgIFN1 YmplY3Q6IFtkaGN3Z10gUkZDMzMxNSBERUNMSU5FIGRlZmluaXRpb24NCg0KICAgICAgICANCg0K ICAgICAgICBIaSwNCg0KICAgICAgICANCg0KICAgICAgICBDYW4gREVDTElORSBkZWZpbml0aW9u IGJlIGV4dGVuZGVkIGJleW9uZCB0aGUgREFEIHVzYWdlPyBJIHRoaW5rIERFQ0xJTkUgc2hvdWxk IGJlIHVzZWQgZXZlcnkgdGltZSBESENQVjYgY2xpZW50IGRlY2lkZXMgbm90IHRvIGFzc2lnbiB0 aGUgb2ZmZXJlZCBhZGRyZXNzLCBmb3IgYW55IHJlYXNvbiwgbm90IGp1c3QgdGhlIGFkZHJlc3Mg aXMgZHVwbGljYXRlLiBXaGVuIHJlY2VpdmluZyBERUNMSU5FLCBESENQVjYgc2VydmVyIHNob3Vs ZCBiZSBhYmxlIHRvIGltbWVkaWF0ZWx5IG1ha2UgdGhlIHNhbWUgYWRkcmVzcyBhdmFpbGFibGUg aW4gdGhlIGFkZHJlc3MgcG9vbCBmb3IgdGhlIG90aGVyIGNsaWVudHMuDQoNCiAgICAgICAgDQoN CiAgICAgICAgUmVnYXJkcywNCg0KICAgICAgICBEdXNhbi4NCg0KICAgICAgICANCg0KICAgICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogICAg ICAgIGRoY3dnIG1haWxpbmcgbGlzdA0KDQogICAgICAgIGRoY3dnQGlldGYub3JnDQoNCiAgICAg ICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19kaGN3ZyZkPURRSUZKZyZjPUJGcFdRdzhic3VL cGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZ Jm09ZFNPWlI0ZE92T0lGbHJKVU8wcmE5RWFIb2NjckFqQWlXeWNYX1k0dm5SUSZzPWU1d0stV1Mw OUJJeDBSS0RUQkVfaUVkVWxyS19iUDZndjRUZlFhTVRQaVUmZT0gDQoNCiAgICAgICAgDQoNCiAg ICANCg0KICAgIA0KDQoNCg0K From nobody Thu Feb 9 06:55:47 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C65129AA1 for ; Thu, 9 Feb 2017 06:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 kaIUlfRvEftL for ; Thu, 9 Feb 2017 06:55:44 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE26129A9A for ; Thu, 9 Feb 2017 06:55:42 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id u25so6625408qki.2 for ; Thu, 09 Feb 2017 06:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3kM6nYjqyO+JBshMLXcJ5hsJ5Y7L6ozqGbt9XL1k/Nk=; b=bPeWDttKkpdGbaYTvWhDxTW+ec4dR+Y+N89+PifnpjhcwW4AyGkch4i9lB/j4Bl1Q2 Ho5zLT+cBkFLk2spAVz6RUm6s6Y6ymxziUOtkkI4XDLtYbxWs4D6YTRxC7ddIOJbp870 3T3viWtJ8Gcxg1pKHLZvsTcETu3LUhRcme+JfQeOfuIcViRLTITBRv6JegiQAIyjaG2z sa+TWkNRQ5ela2LUWQwp4JVaARoVIAxqoJD2S9luVeq1pfoyuu2rizCvWcwoCXchUyQd Y2gJo/5MBP4h1INJSSKhvZonDaugQmyg0D+JEg+y3p8B9TfD3Nd8TF1imEoHKTB6AQeZ O9IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3kM6nYjqyO+JBshMLXcJ5hsJ5Y7L6ozqGbt9XL1k/Nk=; b=VjGafsrdWqjspi3Gy9MLW9dxDHquLVgboVUQFcwcGr00uiPZk6yQcywIL8uY3QboqM CeTsh5/kQzlhwmUsibj2ft5gyVqp80SWjGTd+b7qMrnIQIeM1EsIllGE0bu8cf4W8Zem 2VgsHyydMMPg9TH5iB+7drDeYWOJRTQ8k1t/xHDqD17flhO1306G6tl07CnlXd4FRvsY gHHG6J6OLA60In2hZX2TFK+ypyPlfYMXY3nRPqb7acD28eW2US8nlTssEdU5jPxmB/cy KTJAou3PcjuT4Dwp9QD3HUdaiH1kVuZdu1QLc0nxyi7Curwc5m9wdLz8QtEBAB2L4qX/ wmUg== X-Gm-Message-State: AMke39nZz3BlI6aCAkkwDrPWtxaGWXWpZ4NDC71+MmQZPgRLI0AWKWTsnprBqfsIuueJ1w== X-Received: by 10.55.162.138 with SMTP id l132mr3158592qke.204.1486652141713; Thu, 09 Feb 2017 06:55:41 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id z4sm9349265qkc.7.2017.02.09.06.55.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 06:55:39 -0800 (PST) From: Ted Lemon Message-Id: <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4051D8D9-7454-42DB-B138-57F32665FAA6" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 09:55:38 -0500 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> To: "Mudric, Dusan (Dusan)" References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhcwg , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:55:46 -0000 --Apple-Mail=_4051D8D9-7454-42DB-B138-57F32665FAA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2017, at 9:41 AM, Mudric, Dusan (Dusan) = wrote: > How can I contribute to RFC3315bis? What is the process? The first step would be to figure out what you want, why you want it, = and why anybody should care about it. Then you explain that on the = mailing list and see if you get some interest. =46rom reading what you've said so far, what you want is the ability for = a client to say it doesn't like a particular address, with the intended = effect that if it asks for another address, it will get a _different_ = address. But your intended semantics are unclear, and I don't see how = the server can usefully address this use case. You'd need to explain = that. --Apple-Mail=_4051D8D9-7454-42DB-B138-57F32665FAA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 9, 2017, at 9:41 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote:
How can I contribute to RFC3315bis? What is the = process?

The = first step would be to figure out what you want, why you want it, and = why anybody should care about it.   Then you explain that on the = mailing list and see if you get some interest.

=46rom reading what you've said so far, = what you want is the ability for a client to say it doesn't like a = particular address, with the intended effect that if it asks for another = address, it will get a _different_ address.   But your intended = semantics are unclear, and I don't see how the server can usefully = address this use case.   You'd need to explain that.

= --Apple-Mail=_4051D8D9-7454-42DB-B138-57F32665FAA6-- From nobody Thu Feb 9 07:22:08 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D384F129AB9 for ; Thu, 9 Feb 2017 07:22:05 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 f3bOj7-NG103 for ; Thu, 9 Feb 2017 07:22:03 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [81.174.135.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED34129991 for ; Thu, 9 Feb 2017 07:22:03 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id A87D11A071 for ; Thu, 9 Feb 2017 15:21:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> Date: Thu, 9 Feb 2017 15:21:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3C2E4DD5-AE54-4A1A-881F-324AAD838620@thehobsons.co.uk> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> To: dhcwg X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 15:22:06 -0000 "Mudric, Dusan (Dusan)" wrote: > That is the current use of DECLINE (only for DAD). = https://tools.ietf.org/html/rfc3315#section-17.1.3 only focuses on the = server selection after ADVERTISE is received. It does not mention that = DHCPv6 client might not be happy with the advertised addresses. IPv6 = defines different kinds of addresses and allows multiple addresses, = making it more complex to handle. If a server offers IPv6 address that = client cannot use (e.g. a multicast address, a second address), the = client should be able to decline it. >=20 > Again, if the server sends REPLY or REBIND with an address the client = cannot use, the client should be able to DECLINE it. The big problem I see here is that you are extending the "cannot use" = problem from one where it applies to all clients (eg duplicate address) = to one where **THIS** client cannot use for some local (to the client) = reason and which may well not apply to other clients. it's already been = stated (AIUI) that there is no mechanism for the client to tell the = server WHY it's declining, and hence any decline can only be processed = as "this address is bad for all clients". It might help if you gave an example of a setup where a sensibly = configured server and client have this problem. You mention getting a = multicast address, but (and bear in mind I'm barely at the "crawled of = of the primordial ooze" level with DHCP6, so I don't know how the = client/server differentiate between different types of addresses) surely = if the client can't use a multicast address - why is it asking for one ? = If the server is offering multicast addresses routinely, then why is it = configured that way ? If the client "just wants a different address" then surely the way to do = that is simply solicit for a new lease, using a different identifier so = the server will give it an additional address - and the client can = simply stop using the old address and let it's lease lapse. You've already been told that coming here and just saying "this is = wrong" won't work. You need to explain why it's wrong, why this is an issue for more than = just yourself, and most importantly - why it's a big enough issue to = justify changing the standards and imposing development load on all = creators/vendors of DHCP6 server and client software to implement that = change. Part of the justification involves specific use cases - along the lines = of "people who use X to do Y suffer issue Z". You have not done that so = far. From nobody Thu Feb 9 07:38:08 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B4B129AD9 for ; Thu, 9 Feb 2017 07:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 0WB0RlvrL7Ib for ; Thu, 9 Feb 2017 07:38:05 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18CC0129AE7 for ; Thu, 9 Feb 2017 07:38:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ESAQABjJxY/xUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8hQWGBCQeNWpIJkyeCD4IMhiICgmo/GAECAQEBAQEBAQNfKIR?= =?us-ascii?q?pAQEBAQMSG0ELEAIBCA0BAwQBAQsWBwcyFAkIAgQOBQgRCYlSAaUljQcmAosfA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYZNhG6BPIMCGDSCfoIxBYl0i2CGHAGcZ4Y?= =?us-ascii?q?vkxMfOX5PFTyERB2BYXWHcgGBCwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2ESAQABjJxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgm8?= =?us-ascii?q?hQWGBCQeNWpIJkyeCD4IMhiICgmo/GAECAQEBAQEBAQNfKIRpAQEBAQMSG0ELE?= =?us-ascii?q?AIBCA0BAwQBAQsWBwcyFAkIAgQOBQgRCYlSAaUljQcmAosfAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBHYZNhG6BPIMCGDSCfoIxBYl0i2CGHAGcZ4YvkxMfOX5PFTyER?= =?us-ascii?q?B2BYXWHcgGBCwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,349,1484024400"; d="scan'208,217";a="214668449" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Feb 2017 10:38:03 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 10:38:03 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 10:38:02 -0500 From: "Mudric, Dusan (Dusan)" To: Ted Lemon Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEA== Date: Thu, 9 Feb 2017 15:38:01 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> In-Reply-To: <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457AA1898FAZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: Cc: dhcwg , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 15:38:06 -0000 --_000_9142206A0C5BF24CB22755C8EC422E457AA1898FAZUS1EXMB03glob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, Let's start with the problem statements: 1. When DHCPv6 client starts it sends SOLICIT with IA option (without= or with IPv6 address). The server sends ADVERTISE message offering IPv6 ad= dress(es). If the server offers IPv6 address(es) that client cannot use (e.= g. an address with wrong semantics, a multicast address, a reserved address= , ... , a second address and the client can support only one address), the = client should be able to respond to the server indicating which address it = cannot use. 2. After T1 the client needs to RENEW the address. If REPLY from the = server has new IPv6 address(es) that client cannot use (e.g. a multicast ad= dress, a reserved address, ... , a second address and the client can suppor= t only one address), the client should be able to respond to the server ind= icating which address it cannot use. 3. After T2 the client needs to REBIND the address. If REBIND from th= e server has new IPv6 address(es) that client cannot use (e.g. a multicast = address, a reserved address, ... , a second address and the client can supp= ort only one address), the client should be able to respond to the server i= ndicating which address it cannot use. 4. If the client cannot use the offered address, it might be left in = one of the two states: a. Without any IPv6 address, or b. Still has IPv6 address in preferred state a) The client does not have IPv6 address and needs immediately another= offer from the DHCPv6 server with a different address (e.g. a global, unre= served address) b) With a valid IPv6 address a. The client has IPv6 address it can use during the valid life time = and needs another address from DHCPv6 server (e.g. with a different address= type) before the valid life time expires b. The client cannot handle the address change and does not need the n= ew address from DHCPv6 server c. The client has IPv6 address it can use and does not need multiple = addresses from DHCPv6 server 5. DHCPv6 server should a. Offer a different address type, or b. Make the address available to other clients, or c. Block the address for further use (e.g. the address was invalid). I propose that DECLINE should be defined as a response for the addresses th= at cannot be assigned. There can be a reason code in DECLINE helping the se= rver interpret the response. Regards, Dusan Mudric. From: Ted Lemon [mailto:mellon@fugue.com] Sent: Thursday, February 09, 2017 9:56 AM To: Mudric, Dusan (Dusan) Cc: Bernie Volz (volz); dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition On Feb 9, 2017, at 9:41 AM, Mudric, Dusan (Dusan) > wrote: How can I contribute to RFC3315bis? What is the process? The first step would be to figure out what you want, why you want it, and w= hy anybody should care about it. Then you explain that on the mailing lis= t and see if you get some interest. >From reading what you've said so far, what you want is the ability for a cl= ient to say it doesn't like a particular address, with the intended effect = that if it asks for another address, it will get a _different_ address. B= ut your intended semantics are unclear, and I don't see how the server can = usefully address this use case. You'd need to explain that. --_000_9142206A0C5BF24CB22755C8EC422E457AA1898FAZUS1EXMB03glob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ted,=

 <= /p>

Let’s start with th= e problem statements:

1. = ;      When DHCPv6 clien= t starts it sends SOLICIT with IA option (without or with IPv6 address). Th= e server sends ADVERTISE message offering IPv6 address(es). If the server offers IPv6 address(es) that client cannot use (e.g. an addr= ess with wrong semantics, a multicast address, a reserved address, … = , a second address and the client can support only one address), the client= should be able to respond to the server indicating which address it cannot use.

2. = ;      After T1 the clie= nt needs to RENEW the address. If REPLY from the server has new IPv6 addres= s(es) that client cannot use (e.g. a multicast address, a reserved address, … , a second address and the client can support = only one address), the client should be able to respond to the server indic= ating which address it cannot use.

3. = ;      After T2 the clie= nt needs to REBIND the address. If REBIND from the server has new IPv6 addr= ess(es) that client cannot use (e.g. a multicast address, a reserved address, … , a second address and the client can support = only one address), the client should be able to respond to the server indic= ating which address it cannot use.

4. = ;      If the client can= not use the offered address, it might be left in one of the two states:

a.  &= nbsp;    Without any IPv6 = address, or

b.  &= nbsp;   Still has IPv6 ad= dress in preferred state

a)  &= nbsp;   The client does n= ot have IPv6 address and needs immediately another offer from the DHCPv6 se= rver with a different address (e.g. a global, unreserved address)

b)  &= nbsp;   With a valid IPv6= address

a.  &= nbsp;    The client has IP= v6 address it can use during the valid life time and needs another address = from DHCPv6 server (e.g. with a different address type) before the valid life time expires

b.  &= nbsp;   The client cannot= handle the address change and does not need the new address from DHCPv6 se= rver

c.  &= nbsp;    The client has IP= v6 address it can use and does not need multiple addresses from DHCPv6 serv= er

5. = ;      DHCPv6 server sho= uld

a.  &= nbsp;    Offer a different= address type, or

b.  &= nbsp;   Make the address = available to other clients, or

c.  &= nbsp;    Block the address= for further use (e.g. the address was invalid).

 <= /p>

I propose that DECLINE sh= ould be defined as a response for the addresses that cannot be assigned. Th= ere can be a reason code in DECLINE helping the server interpret the response.

 <= /p>

Regards,

Dusan Mudric.<= /span>

 <= /p>

 

From: Ted Lemo= n [mailto:mellon@fugue.com]
Sent: Thursday, February 09, 2017 9:56 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz (volz); dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

 

On Feb 9, 2017, at 9:41 AM, Mudric, Dusan (Dusan) &l= t;dmudric@avaya.com> wrote:

How can I contribute to RFC3315bis? Wh= at is the process?

 

The first step would be to figure out what you want,= why you want it, and why anybody should care about it.   Then you exp= lain that on the mailing list and see if you get some interest.<= /p>

 

From reading what you've said so far, what you want = is the ability for a client to say it doesn't like a particular address, wi= th the intended effect that if it asks for another address, it will get a _= different_ address.   But your intended semantics are unclear, and I don't see how the server can usefully address= this use case.   You'd need to explain that.

 

--_000_9142206A0C5BF24CB22755C8EC422E457AA1898FAZUS1EXMB03glob_-- From nobody Thu Feb 9 07:40:38 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD06129AE8 for ; Thu, 9 Feb 2017 07:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 pCx10uJYZBn8 for ; Thu, 9 Feb 2017 07:40:36 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF32129AD9 for ; Thu, 9 Feb 2017 07:40:36 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id w20so7286075qtb.1 for ; Thu, 09 Feb 2017 07:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DRCFCSfmP1UGT8FAFxDkIeIRZmriwBrLE3rYXOUT/gY=; b=i8oVqTlblPksHu86vFlBexZqtPV0opSrs98A+eUNKIwrQ+4OBl/Yufkuzcb4aFVpNe iHOr7qddOCG2zep1Q1ifJPNeJwIlVzU0QGCpFWuYuA3Y9BDOGh2a2z5wzoSLm1NgGi+L NMgMriqJtW3ZA9kfTcU7fsONkk60SrTenNqL0nV3CmBOAj+jAgzl+zvmI2ifKLHJDbVW qyLi8xb5Cc5+HxmkjBnrfO8URdE2TxSuGQd/kV9SkXGPumFJii5V3OT0nu9+cFEqP3s3 DavADXWRoT4FIDIQu30IfIGnj3Sm4VMjI+M933juIgl9OMFUzhMOOfv9OIzoxmsF1nF3 JzgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DRCFCSfmP1UGT8FAFxDkIeIRZmriwBrLE3rYXOUT/gY=; b=YOJlmQ//Eqith4QE0rHdstRPJvc6qzsDPRBEBSIwtWR+EjJNbPFsTYapr0GMnZZ3ki ylP6JBjE0Lf6GPg0bO2WKQh1OgCjFWlrAhW2lz6HwFminNA9biMkixl0NDo5A2nfbilu +w3ZmfgWHSfvz3l0fJMjIAs2MFuqN/CjA48GOK/M24VKx1BqQnfI+duQcFjZdopfRDl8 joWkPV0Z5DwCznQHpDzsLOTSQqQyt1Au4PRwUgVRfzgyuQc3RL4eOulHxHu3ZfZ4OPCK k+xXQ2FivvrAsZAfXoR5J1raweTrmThYnjtE6FLEUQsAEwq5VQAw4O3XzCdyGUn9t4qX +PkA== X-Gm-Message-State: AMke39mgkhFw6srpRtbjCDvTXFBuR26W4ZloJnpdrhYVIFxLCWsixgEqwE9alei2zlL2xw== X-Received: by 10.200.42.227 with SMTP id c32mr3377462qta.70.1486654835511; Thu, 09 Feb 2017 07:40:35 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 140sm9401372qkj.19.2017.02.09.07.40.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 07:40:34 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_49B6282A-4623-4533-9093-7ACF56B9CB96" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 10:40:33 -0500 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> To: "Mudric, Dusan (Dusan)" References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhcwg , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 15:40:37 -0000 --Apple-Mail=_49B6282A-4623-4533-9093-7ACF56B9CB96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 9, 2017, at 10:38 AM, Mudric, Dusan (Dusan) = wrote: > 1. When DHCPv6 client starts it sends SOLICIT with IA option = (without or with IPv6 address). The server sends ADVERTISE message = offering IPv6 address(es). If the server offers IPv6 address(es) that = client cannot use (e.g. an address with wrong semantics, a multicast = address, a reserved address, =E2=80=A6 , a second address and the client = can support only one address), the client should be able to respond to = the server indicating which address it cannot use. Let me stop you here. This is a server misconfiguration. The server = is not artificially intelligent, so the client can't usefully tell the = server it is misconfigured. If the server is configured to hand out = addresses with the wrong semantics, the solution is to fix the server, = not complicate the protocol with a way for the client to tell the server = something it can't do anything about. This also needlessly complicates = the client. So why do you think this is a useful thing to do? What = non-hypothetical problem are you trying to solve here? --Apple-Mail=_49B6282A-4623-4533-9093-7ACF56B9CB96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 9, 2017, at 10:38 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote:
1.       When DHCPv6 client starts it sends SOLICIT = with IA option (without or with IPv6 address). The server sends = ADVERTISE message offering IPv6 address(es). If the server offers IPv6 = address(es) that client cannot use (e.g. an address with wrong = semantics, a multicast address, a reserved address, =E2=80=A6 , a second = address and the client can support only one address), the client should = be able to respond to the server indicating which address it cannot = use.

Let me = stop you here.   This is a server misconfiguration.   The = server is not artificially intelligent, so the client can't usefully = tell the server it is misconfigured.   If the server is configured = to hand out addresses with the wrong semantics, the solution is to fix = the server, not complicate the protocol with a way for the client to = tell the server something it can't do anything about.   This also = needlessly complicates the client.

So = why do you think this is a useful thing to do?   What = non-hypothetical problem are you trying to solve here?

= --Apple-Mail=_49B6282A-4623-4533-9093-7ACF56B9CB96-- From nobody Thu Feb 9 07:46:27 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D033C129AB5 for ; Thu, 9 Feb 2017 07:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 mG2vfKTN5B_b for ; Thu, 9 Feb 2017 07:46:24 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096E21299E1 for ; Thu, 9 Feb 2017 07:46:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ETAQBWjpxY/xUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8hQWGBCQeDUooIkgmTJ4IPggyGIgIaglA/GAECAQEBAQEBAQN?= =?us-ascii?q?fKIRpAQEBAQMSEQpMEAIBCA0BAwQBAQsdAwICAjAUCQgCBA4FCBMHiVIBpSiKY?= =?us-ascii?q?oIlJgKLHwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GTYRugTyDAhgVH4JQLoIxBYl?= =?us-ascii?q?0i2CGHAGcZ4YvkxMfOX5PFYR7ggN1h3IBgQsBAQE?= X-IPAS-Result: =?us-ascii?q?A2ETAQBWjpxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgm8?= =?us-ascii?q?hQWGBCQeDUooIkgmTJ4IPggyGIgIaglA/GAECAQEBAQEBAQNfKIRpAQEBAQMSE?= =?us-ascii?q?QpMEAIBCA0BAwQBAQsdAwICAjAUCQgCBA4FCBMHiVIBpSiKYoIlJgKLHwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAR2GTYRugTyDAhgVH4JQLoIxBYl0i2CGHAGcZ4Yvk?= =?us-ascii?q?xMfOX5PFYR7ggN1h3IBgQsBAQE?= X-IronPort-AV: E=Sophos;i="5.35,349,1484024400"; d="scan'208,217";a="190087705" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Feb 2017 10:46:16 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 10:46:16 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 10:46:15 -0500 From: "Mudric, Dusan (Dusan)" To: Ted Lemon Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jA= Date: Thu, 9 Feb 2017 15:46:14 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457AA189BDAZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: Cc: dhcwg , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 15:46:26 -0000 --_000_9142206A0C5BF24CB22755C8EC422E457AA189BDAZUS1EXMB03glob_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGZpcnN0IHByb2JsZW0gc3RhdGVtZW50IGlzIGFib3V0IHRoZSBzZXJ2ZXIgbWlzY29uZmln dXJhdGlvbi4gSW5zdGVhZCBvZiBjbGllbnQgc2lsZW50bHkgaWdub3JpbmcgdGhlIG9mZmVyZWQg YWRkcmVzcywgb3IgZXZlbiB3b3JzZSwgYXNzaWduaW5nIHRoZSBtaXNjb25maWd1cmVkIGFkZHJl c3MsIHRoZSBzZXJ2ZXIgKGFuZCBhZG1pbmlzdHJhdG9yKSBzaG91bGQgYmUgaW5mb3JtZWQgYWJv dXQgdGhlIG1pc2NvbmZpZ3VyYXRpb24uDQoNClJlZ2FyZHMsDQpEdXNhbiBNdWRyaWMuDQoNCkZy b206IFRlZCBMZW1vbiBbbWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dDQpTZW50OiBUaHVyc2RheSwg RmVicnVhcnkgMDksIDIwMTcgMTA6NDEgQU0NClRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikNCkNj OiBCZXJuaWUgVm9seiAodm9seik7IGRoY3dnDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBSRkMzMzE1 IERFQ0xJTkUgZGVmaW5pdGlvbg0KDQpPbiBGZWIgOSwgMjAxNywgYXQgMTA6MzggQU0sIE11ZHJp YywgRHVzYW4gKER1c2FuKSA8ZG11ZHJpY0BhdmF5YS5jb208bWFpbHRvOmRtdWRyaWNAYXZheWEu Y29tPj4gd3JvdGU6DQoxLiAgICAgICBXaGVuIERIQ1B2NiBjbGllbnQgc3RhcnRzIGl0IHNlbmRz IFNPTElDSVQgd2l0aCBJQSBvcHRpb24gKHdpdGhvdXQgb3Igd2l0aCBJUHY2IGFkZHJlc3MpLiBU aGUgc2VydmVyIHNlbmRzIEFEVkVSVElTRSBtZXNzYWdlIG9mZmVyaW5nIElQdjYgYWRkcmVzcyhl cykuIElmIHRoZSBzZXJ2ZXIgb2ZmZXJzIElQdjYgYWRkcmVzcyhlcykgdGhhdCBjbGllbnQgY2Fu bm90IHVzZSAoZS5nLiBhbiBhZGRyZXNzIHdpdGggd3Jvbmcgc2VtYW50aWNzLCBhIG11bHRpY2Fz dCBhZGRyZXNzLCBhIHJlc2VydmVkIGFkZHJlc3MsIOKApiAsIGEgc2Vjb25kIGFkZHJlc3MgYW5k IHRoZSBjbGllbnQgY2FuIHN1cHBvcnQgb25seSBvbmUgYWRkcmVzcyksIHRoZSBjbGllbnQgc2hv dWxkIGJlIGFibGUgdG8gcmVzcG9uZCB0byB0aGUgc2VydmVyIGluZGljYXRpbmcgd2hpY2ggYWRk cmVzcyBpdCBjYW5ub3QgdXNlLg0KDQpMZXQgbWUgc3RvcCB5b3UgaGVyZS4gICBUaGlzIGlzIGEg c2VydmVyIG1pc2NvbmZpZ3VyYXRpb24uICAgVGhlIHNlcnZlciBpcyBub3QgYXJ0aWZpY2lhbGx5 IGludGVsbGlnZW50LCBzbyB0aGUgY2xpZW50IGNhbid0IHVzZWZ1bGx5IHRlbGwgdGhlIHNlcnZl ciBpdCBpcyBtaXNjb25maWd1cmVkLiAgIElmIHRoZSBzZXJ2ZXIgaXMgY29uZmlndXJlZCB0byBo YW5kIG91dCBhZGRyZXNzZXMgd2l0aCB0aGUgd3Jvbmcgc2VtYW50aWNzLCB0aGUgc29sdXRpb24g aXMgdG8gZml4IHRoZSBzZXJ2ZXIsIG5vdCBjb21wbGljYXRlIHRoZSBwcm90b2NvbCB3aXRoIGEg d2F5IGZvciB0aGUgY2xpZW50IHRvIHRlbGwgdGhlIHNlcnZlciBzb21ldGhpbmcgaXQgY2FuJ3Qg ZG8gYW55dGhpbmcgYWJvdXQuICAgVGhpcyBhbHNvIG5lZWRsZXNzbHkgY29tcGxpY2F0ZXMgdGhl IGNsaWVudC4NCg0KU28gd2h5IGRvIHlvdSB0aGluayB0aGlzIGlzIGEgdXNlZnVsIHRoaW5nIHRv IGRvPyAgIFdoYXQgbm9uLWh5cG90aGV0aWNhbCBwcm9ibGVtIGFyZSB5b3UgdHJ5aW5nIHRvIHNv bHZlIGhlcmU/DQoNCg== --_000_9142206A0C5BF24CB22755C8EC422E457AA189BDAZUS1EXMB03glob_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBmaXJzdCBwcm9ibGVtIHN0 YXRlbWVudCBpcyBhYm91dCB0aGUgc2VydmVyIG1pc2NvbmZpZ3VyYXRpb24uIEluc3RlYWQgb2Yg Y2xpZW50IHNpbGVudGx5IGlnbm9yaW5nIHRoZSBvZmZlcmVkIGFkZHJlc3MsIG9yIGV2ZW4gd29y c2UsIGFzc2lnbmluZyB0aGUgbWlzY29uZmlndXJlZA0KIGFkZHJlc3MsIHRoZSBzZXJ2ZXIgKGFu ZCBhZG1pbmlzdHJhdG9yKSBzaG91bGQgYmUgaW5mb3JtZWQgYWJvdXQgdGhlIG1pc2NvbmZpZ3Vy YXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkR1c2FuIE11ZHJpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBUZWQgTGVtb24gW21haWx0bzptZWxsb25AZnVndWUuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyAxMDo0MSBBTTxicj4NCjxiPlRvOjwv Yj4gTXVkcmljLCBEdXNhbiAoRHVzYW4pPGJyPg0KPGI+Q2M6PC9iPiBCZXJuaWUgVm9seiAodm9s eik7IGRoY3dnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZGhjd2ddIFJGQzMzMTUgREVDTElO RSBkZWZpbml0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gRmViIDksIDIwMTcsIGF0IDEwOjM4IEFNLCBNdWRyaWMsIER1c2FuIChEdXNhbikgJmx0 OzxhIGhyZWY9Im1haWx0bzpkbXVkcmljQGF2YXlhLmNvbSI+ZG11ZHJpY0BhdmF5YS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0 ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7d29yZC1zcGFjaW5nOjBweCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ MS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5XaGVuDQogREhDUHY2IGNsaWVudCBzdGFydHMgaXQgc2VuZHMgU09M SUNJVCB3aXRoIElBIG9wdGlvbiAod2l0aG91dCBvciB3aXRoIElQdjYgYWRkcmVzcykuIFRoZSBz ZXJ2ZXIgc2VuZHMgQURWRVJUSVNFIG1lc3NhZ2Ugb2ZmZXJpbmcgSVB2NiBhZGRyZXNzKGVzKS4g SWYgdGhlIHNlcnZlciBvZmZlcnMgSVB2NiBhZGRyZXNzKGVzKSB0aGF0IGNsaWVudCBjYW5ub3Qg dXNlIChlLmcuIGFuIGFkZHJlc3Mgd2l0aCB3cm9uZyBzZW1hbnRpY3MsIGEgbXVsdGljYXN0DQog YWRkcmVzcywgYSByZXNlcnZlZCBhZGRyZXNzLCDigKYgLCBhIHNlY29uZCBhZGRyZXNzIGFuZCB0 aGUgY2xpZW50IGNhbiBzdXBwb3J0IG9ubHkgb25lIGFkZHJlc3MpLCB0aGUgY2xpZW50IHNob3Vs ZCBiZSBhYmxlIHRvIHJlc3BvbmQgdG8gdGhlIHNlcnZlciBpbmRpY2F0aW5nIHdoaWNoIGFkZHJl c3MgaXQgY2Fubm90IHVzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXQgbWUgc3RvcCB5b3UgaGVy ZS4gJm5ic3A7IFRoaXMgaXMgYSBzZXJ2ZXIgbWlzY29uZmlndXJhdGlvbi4gJm5ic3A7IFRoZSBz ZXJ2ZXIgaXMgbm90IGFydGlmaWNpYWxseSBpbnRlbGxpZ2VudCwgc28gdGhlIGNsaWVudCBjYW4n dCB1c2VmdWxseSB0ZWxsIHRoZSBzZXJ2ZXIgaXQgaXMgbWlzY29uZmlndXJlZC4gJm5ic3A7IElm IHRoZSBzZXJ2ZXIgaXMgY29uZmlndXJlZCB0byBoYW5kIG91dCBhZGRyZXNzZXMgd2l0aCB0aGUg d3JvbmcNCiBzZW1hbnRpY3MsIHRoZSBzb2x1dGlvbiBpcyB0byBmaXggdGhlIHNlcnZlciwgbm90 IGNvbXBsaWNhdGUgdGhlIHByb3RvY29sIHdpdGggYSB3YXkgZm9yIHRoZSBjbGllbnQgdG8gdGVs bCB0aGUgc2VydmVyIHNvbWV0aGluZyBpdCBjYW4ndCBkbyBhbnl0aGluZyBhYm91dC4gJm5ic3A7 IFRoaXMgYWxzbyBuZWVkbGVzc2x5IGNvbXBsaWNhdGVzIHRoZSBjbGllbnQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIHdoeSBkbyB5b3Ug dGhpbmsgdGhpcyBpcyBhIHVzZWZ1bCB0aGluZyB0byBkbz8gJm5ic3A7IFdoYXQgbm9uLWh5cG90 aGV0aWNhbCBwcm9ibGVtIGFyZSB5b3UgdHJ5aW5nIHRvIHNvbHZlIGhlcmU/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9142206A0C5BF24CB22755C8EC422E457AA189BDAZUS1EXMB03glob_-- From nobody Thu Feb 9 07:48:36 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74BB129AD9 for ; Thu, 9 Feb 2017 07:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 R8cMAVuGZlyC for ; Thu, 9 Feb 2017 07:48:34 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D455B129AC8 for ; Thu, 9 Feb 2017 07:48:33 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id s186so8468798qkb.1 for ; Thu, 09 Feb 2017 07:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=ubzAfe3cmqt1PFZkozImamCxsOGjmgMiCrK+uPhVqWE=; b=1tRwFe8NhTt+EDKVHZeqzpsIsqM/r2y7KkB+cagedBENUEAKCZ1NOAYWjWvwC0I0s+ 6E7Uddb+AYXvmxtIduOlBBr92ya8ijSbo069tr6CxqMt0uwpmAgHMkYacDvLf4dTOkF3 SLqS9HoJ24NSmUp9yEn+g7rpZRj2GuwVr7+QeQ3zrPSgcLQNKxJY9iWjDZnFoCdxcRQq nNL3h2pw+wxapmiZgaoOS+HrjNnKgSX+kNA9zPpXZIcydxedbdl3Ip2dSmd2JvGzkBjQ 0aT+Y/i4QL4051/+ht7qtDS/HHe+36h+8sS0dx5mAUJcIyNfmzG6fDwKt6GEUDnPZhqX fzng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=ubzAfe3cmqt1PFZkozImamCxsOGjmgMiCrK+uPhVqWE=; b=GKVfcCyw9CidAwOaI/ZlSnqZYO7nCA99qEtuuK04ANP0vi+EfCf+zWnZExZ8oidbzn 2j8tsWjGPY+rRMBvnhkHwMIyXxb/D7gzHMsQs2jYxVvqr7EfJ2j4ctIA7kCHVYg1Vh6H 7il9BGdKx6srK67hf/F0dZ27Kc78VPOnX8UuhPw9RGDkrVVlf8UUTDnpnEhOGA5wlN+o bRUZnkRPLCA10faRltxRwVha5r/ssuVxEktzcg2RsySG4yjLItrjM8PsvWzvgFlJJs46 jqxdaawGLz6sgNRGBhzX0awjsp+Qqc3Rfrhk8EMr64smOrATUomaQh27cv0NoacNh5xj 01ZQ== X-Gm-Message-State: AMke39k1NObdkr0iAAim4uQeb7EfgGEoZGN5TWPkND+mXKPrfjIjfptXESJxA7J7dd1QzA== X-Received: by 10.55.4.19 with SMTP id 19mr3878822qke.320.1486655312850; Thu, 09 Feb 2017 07:48:32 -0800 (PST) Received: from [192.168.125.1] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id r10sm9438899qte.1.2017.02.09.07.48.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 07:48:31 -0800 (PST) From: "Ted Lemon" To: "Mudric, Dusan" Date: Thu, 09 Feb 2017 10:48:17 -0500 Message-ID: <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate Trial (1.9.6r5344) Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 15:48:35 -0000 On 9 Feb 2017, at 10:46, Mudric, Dusan (Dusan) wrote: > The first problem statement is about the server misconfiguration. > Instead of client silently ignoring the offered address, or even > worse, assigning the misconfigured address, the server (and > administrator) should be informed about the misconfiguration. How does this make things better? From nobody Thu Feb 9 08:06:24 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C6A129B2E for ; Thu, 9 Feb 2017 08:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 b5WGOPWpjNHb for ; Thu, 9 Feb 2017 08:06:22 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257E7129B28 for ; Thu, 9 Feb 2017 08:06:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ESAQAGk5xY/yYyC4ddGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBBgWoHjVqSCpMngg+CDIYiAoJqPxgBAgEBAQEBAQEDXyiEaQE?= =?us-ascii?q?BAQEDEig/DAQCAQgNAQMEAQEBChQJBzIUCQgCBA4FCBqJUgGlJ40HJgKLJQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2GTYRugTyDAhiDMoIxBZtwAZxnhi+TEx85fk8?= =?us-ascii?q?VhHuCA3WHcgGBCwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2ESAQAGk5xY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?BgWoHjVqSCpMngg+CDIYiAoJqPxgBAgEBAQEBAQEDXyiEaQEBAQEDEig/DAQCA?= =?us-ascii?q?QgNAQMEAQEBChQJBzIUCQgCBA4FCBqJUgGlJ40HJgKLJQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAR2GTYRugTyDAhiDMoIxBZtwAZxnhi+TEx85fk8VhHuCA3WHcgGBC?= =?us-ascii?q?wEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,137,1484024400"; d="scan'208";a="214672811" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Feb 2017 11:06:12 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 11:06:13 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 11:06:11 -0500 From: "Mudric, Dusan (Dusan)" To: Ted Lemon Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ Date: Thu, 9 Feb 2017 16:06:08 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> In-Reply-To: <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:06:23 -0000 Let's say there is a deployment within an enterprise of 20 000 devices, eac= h with DHCPv6 enabled. They are on different locations and use different DH= CPv6 servers. One server is configured to statically assign IPv6 addresses = (based on the client MAC) or with a pool of IPv6 addresses for the local li= nk. If a client on that location assigns the misconfigured address it becom= es unreachable. A user does not even know how to spell DHCPv6 and all he/sh= e experiences is that the device is unusable. The network operator does not= get any indication that the device is out of service. If the client is able to tell the server that the address cannot be used, t= he administrator should be able to get some notification about the problem = (e.g. an alarm), and find in the server log there was the configuration pro= blem. The server might be able to automatically solve the issue. For exampl= e, the server can be configured with different address pools (e.g. using di= fferent address types) and the server can offer the address from a differen= t address pool. Regards, Dusan. -----Original Message----- From: Ted Lemon [mailto:mellon@fugue.com]=20 Sent: Thursday, February 09, 2017 10:48 AM To: Mudric, Dusan (Dusan) Cc: Bernie Volz; dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition On 9 Feb 2017, at 10:46, Mudric, Dusan (Dusan) wrote: > The first problem statement is about the server misconfiguration.=20 > Instead of client silently ignoring the offered address, or even=20 > worse, assigning the misconfigured address, the server (and > administrator) should be informed about the misconfiguration. How does this make things better? From nobody Thu Feb 9 08:13:11 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8496B129B63 for ; Thu, 9 Feb 2017 08:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=incognito-com.20150623.gappssmtp.com 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 ocBJuAn95MaX for ; Thu, 9 Feb 2017 08:13:05 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04BF129B62 for ; Thu, 9 Feb 2017 08:13:04 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id u68so5044345ywg.0 for ; Thu, 09 Feb 2017 08:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=incognito-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2DVsXwuajqTQB6uBHPj1ss8lnim2E+z78pAHlt8hj5Y=; b=b+Ir2NWcjJrubuDE58W/bKfNxwtmKRMAjBt0hMio6xJy0siFUqLlqnSFc2OUzeZsAv y6k4D37fMCi3RlecU74mrgVbHJNM6wV+TotQiBqPV6J3awN+S3mlGJstgoak/IuhHAca XpZUpXSLV8czXBuLCzjhvk7qs+3h69KCida+mMVJdlHRPVSmxDpRwE07gtEJwVK76gJx yfrQX2jSIHDGQN6b2tIotuY0TYj6Ox8XfYVAZU0FsYlu3rvvJsz8V8BVCiMDkZJszPEr bKxxIct3XD7/UzL8dHe3sGvyTQ0gI1OwcucSr0uRtq/ArDL1BkbSXeOFBhTf1TlqF8As g86A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2DVsXwuajqTQB6uBHPj1ss8lnim2E+z78pAHlt8hj5Y=; b=lqH2DMTlnPEzxFRWA/R4VkeNewoyFRgjoRjXEh2VeUaQM2Q6Bt3z9mVEAaLxNlhddm RFRZRe8Mc5dUTqJkzoX0oiVNYh6ypmNZTtwDsahrOjSKJMA7xp70OO6s3Pgaq72oIe78 bU9Ea90paK4K+yOgAq9bTrNfoUvLNiN1A6+tZHqRkFROkQ/wWzUYI8hm65JtWCCXA9Ig d/LuN83+fh1DnxScqtk7ikB4oIgKhnwbQWGcUtUuKMsqW1nXz53Hc7UrTqAt1+CUfioC bx+Zcr4w8pWjVOcVmEMcqXWAcnu+c5gQSAa3P58UzV/9KCfRdV8xEzpX7A57BPkdQfWM 5z7A== X-Gm-Message-State: AMke39k3/CO5HXvALKrGxxjG3dcJTqk4Hlu0ewbjbSwLZo4ExkLy87AdB868qa1qSpEjpRVjzQSMBrwAAkx1/+3g X-Received: by 10.129.101.10 with SMTP id z10mr3178736ywb.45.1486656778768; Thu, 09 Feb 2017 08:12:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.113.5 with HTTP; Thu, 9 Feb 2017 08:12:58 -0800 (PST) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> From: Andre Kostur Date: Thu, 9 Feb 2017 08:12:58 -0800 Message-ID: To: "Mudric, Dusan (Dusan)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dhcwg , Ted Lemon , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:13:10 -0000 On Thu, Feb 9, 2017 at 8:06 AM, Mudric, Dusan (Dusan) w= rote: > Let's say there is a deployment within an enterprise of 20 000 devices, e= ach with DHCPv6 enabled. They are on different locations and use different = DHCPv6 servers. One server is configured to statically assign IPv6 addresse= s (based on the client MAC) or with a pool of IPv6 addresses for the local = link. If a client on that location assigns the misconfigured address it bec= omes unreachable. A user does not even know how to spell DHCPv6 and all he/= she experiences is that the device is unusable. The network operator does n= ot get any indication that the device is out of service. Assigns what misconfigured address? The client will either do a naked SOLICIT and get the reserved IP that the server was configured to give it, or it will do a CONFIRM with the address it obtained from a different link and the server will REPLY for that address giving it 0 lifetimes to instruct the client that the address is no longer usable. Then the client goes back to the SOLICIT and gets the reserved IP that the server was configured to give it. --=20 Andre Kostur From nobody Thu Feb 9 08:24:42 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59520129B89 for ; Thu, 9 Feb 2017 08:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 FYQWUL5nQpny for ; Thu, 9 Feb 2017 08:24:39 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D46B129B8A for ; Thu, 9 Feb 2017 08:24:38 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id w20so8661997qtb.1 for ; Thu, 09 Feb 2017 08:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=U6eFIMs0gJNGxHyf0vsT8i3o8DUiLhhQLCLsIBjqN4g=; b=AENevWVUZh/k66ajtWYnR4xdCqVsI5pptPkvx+JWIPdM+4Jmbjej+F5wtbDHVqrR8o AiI/Tgrw1r8kpek7fyQug8FIixvs/xA3O4wzzRPib0JKpdwUPlC1EkHbtpkM3J75lJLK +mn0oRoGkYuWfQ59a5Cb46MvgjtgiQdPNNEMOmM7VpuJlILEcZK1yAGyMzP8KL77e9mH mAG101Fwg89uOgxQrEUrJlKuf/77PXcJ3FOfkmNGgkqUkAuSV1WQQ2ogb1VI9AUQ8u2I UJ3Yxx/AMm7wDFXvuVRSQU9rh2CJE6GgssN5hE17vPuqlCiHZlqm+G9XLLhyYEYFBSgY Hqdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=U6eFIMs0gJNGxHyf0vsT8i3o8DUiLhhQLCLsIBjqN4g=; b=I2QzaVnKwC2wW4iXmsQlxQZzeO07NXss8Peg1F2w3EPRi0X83AX9ge8KoOi70LjhbZ 93SYqD5JhCb1E8gKjlTEIBXPyGEbr4nWlpxNSg4KqCKg+RwC2GsZPB98YeYVRHKVACye 5sZq4M6GWhlnHKVYWqwrKvXkfTr4UYsjQF1ExdOaEBNqwIn2Z9xOak42Qda/Vk58kPsb kSDBWqGX3z1X/YjR8VT05WHd1IJT/rtwUCY/xrrxFFEcV7jvcVcQ010Yu4zuxHUqGC0z YErfBJn2DiGWL7X3dkUgWyVUryVaNYzZkSnOpPWc6YnsP81tNcd0V6TpoN56ZUprk+io RsEw== X-Gm-Message-State: AMke39lH5+QC/0UIdoNPd+H1e87E9zEs2HJFm0FiHpopZfSFpazv0UfvVAQlhVUjPoSUnA== X-Received: by 10.237.42.108 with SMTP id k41mr3378005qtf.81.1486657477641; Thu, 09 Feb 2017 08:24:37 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m30sm9550196qtg.10.2017.02.09.08.24.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 08:24:36 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5051DAEF-B7F2-4AF6-86F8-9FBD75F686F1" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 11:24:34 -0500 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> To: "Mudric, Dusan (Dusan)" References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:24:40 -0000 --Apple-Mail=_5051DAEF-B7F2-4AF6-86F8-9FBD75F686F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2017, at 11:06 AM, Mudric, Dusan (Dusan) = wrote: > If the client is able to tell the server that the address cannot be = used, the administrator should be able to get some notification about = the problem (e.g. an alarm), and find in the server log there was the = configuration problem. The server might be able to automatically solve = the issue. For example, the server can be configured with different = address pools (e.g. using different address types) and the server can = offer the address from a different address pool. How does the client know that the address "cannot be used"? --Apple-Mail=_5051DAEF-B7F2-4AF6-86F8-9FBD75F686F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 9, 2017, at 11:06 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote:
If the client is able to tell the server that = the address cannot be used, the administrator should be able to get some = notification about the problem (e.g. an alarm), and find in the server = log there was the configuration problem. The server might be able to = automatically solve the issue. For example, the server can be configured = with different address pools (e.g. using different address types) and = the server can offer the address from a different address = pool.

How = does the client know that the address "cannot be used"?

= --Apple-Mail=_5051DAEF-B7F2-4AF6-86F8-9FBD75F686F1-- From nobody Thu Feb 9 08:25:14 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0350E129B61 for ; Thu, 9 Feb 2017 08:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 RhO7AIqqxClo for ; Thu, 9 Feb 2017 08:25:12 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ADA1129B8D for ; Thu, 9 Feb 2017 08:25:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ETAQCTlpxY/yYyC4ddGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxAXKoFqB4NSigiSCZMngg+CDIYiAhqCUD8YAQIBAQEBAQEBA18?= =?us-ascii?q?ohGkBAQEBAxIREUUMBAIBCA0BAwQBAQECAgYdAwICAjAUAQgIAgQOBQgaiVIBp?= =?us-ascii?q?TKKYoIlJgKLJQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VChG6BPIMCGBWCby6?= =?us-ascii?q?CMQWbcAGcZ4YvkxMfOX5PFYZ+dYdyAYELAQEB?= X-IPAS-Result: =?us-ascii?q?A2ETAQCTlpxY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxA?= =?us-ascii?q?XKoFqB4NSigiSCZMngg+CDIYiAhqCUD8YAQIBAQEBAQEBA18ohGkBAQEBAxIRE?= =?us-ascii?q?UUMBAIBCA0BAwQBAQECAgYdAwICAjAUAQgIAgQOBQgaiVIBpTKKYoIlJgKLJQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VChG6BPIMCGBWCby6CMQWbcAGcZ4Yvk?= =?us-ascii?q?xMfOX5PFYZ+dYdyAYELAQEB?= X-IronPort-AV: E=Sophos;i="5.35,137,1484024400"; d="scan'208";a="190093348" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Feb 2017 11:24:58 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 11:24:58 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 11:24:56 -0500 From: "Mudric, Dusan (Dusan)" To: Andre Kostur Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+ztAAACh5MoA== Date: Thu, 9 Feb 2017 16:24:54 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18A99@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: dhcwg , Ted Lemon , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:25:14 -0000 4oCdIFRoZSBjbGllbnQgd2lsbCBlaXRoZXIgZG8gYSBuYWtlZCBTT0xJQ0lUIGFuZCBnZXQgdGhl IHJlc2VydmVkIElQIHRoYXQgdGhlIHNlcnZlciB3YXMgY29uZmlndXJlZCB0byBnaXZlIGl0Ig0K DQpUaGF0IGNvbmZpZ3VyZWQgSVAgbWlnaHQgYmUgYW4gYWRkcmVzcyB0aGF0IHRoZSBjbGllbnQg Y2Fubm90IHVzZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFuZHJlIEtv c3R1ciBbbWFpbHRvOmFrb3N0dXJAaW5jb2duaXRvLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgMDksIDIwMTcgMTE6MTMgQU0NClRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikNCkNjOiBU ZWQgTGVtb247IGRoY3dnOyBCZXJuaWUgVm9seg0KU3ViamVjdDogUmU6IFtkaGN3Z10gUkZDMzMx NSBERUNMSU5FIGRlZmluaXRpb24NCg0KT24gVGh1LCBGZWIgOSwgMjAxNyBhdCA4OjA2IEFNLCBN dWRyaWMsIER1c2FuIChEdXNhbikgPGRtdWRyaWNAYXZheWEuY29tPiB3cm90ZToNCj4gTGV0J3Mg c2F5IHRoZXJlIGlzIGEgZGVwbG95bWVudCB3aXRoaW4gYW4gZW50ZXJwcmlzZSBvZiAyMCAwMDAg ZGV2aWNlcywgZWFjaCB3aXRoIERIQ1B2NiBlbmFibGVkLiBUaGV5IGFyZSBvbiBkaWZmZXJlbnQg bG9jYXRpb25zIGFuZCB1c2UgZGlmZmVyZW50IERIQ1B2NiBzZXJ2ZXJzLiBPbmUgc2VydmVyIGlz IGNvbmZpZ3VyZWQgdG8gc3RhdGljYWxseSBhc3NpZ24gSVB2NiBhZGRyZXNzZXMgKGJhc2VkIG9u IHRoZSBjbGllbnQgTUFDKSBvciB3aXRoIGEgcG9vbCBvZiBJUHY2IGFkZHJlc3NlcyBmb3IgdGhl IGxvY2FsIGxpbmsuIElmIGEgY2xpZW50IG9uIHRoYXQgbG9jYXRpb24gYXNzaWducyB0aGUgbWlz Y29uZmlndXJlZCBhZGRyZXNzIGl0IGJlY29tZXMgdW5yZWFjaGFibGUuIEEgdXNlciBkb2VzIG5v dCBldmVuIGtub3cgaG93IHRvIHNwZWxsIERIQ1B2NiBhbmQgYWxsIGhlL3NoZSBleHBlcmllbmNl cyBpcyB0aGF0IHRoZSBkZXZpY2UgaXMgdW51c2FibGUuIFRoZSBuZXR3b3JrIG9wZXJhdG9yIGRv ZXMgbm90IGdldCBhbnkgaW5kaWNhdGlvbiB0aGF0IHRoZSBkZXZpY2UgaXMgb3V0IG9mIHNlcnZp Y2UuDQoNCkFzc2lnbnMgd2hhdCBtaXNjb25maWd1cmVkIGFkZHJlc3M/ICBUaGUgY2xpZW50IHdp bGwgZWl0aGVyIGRvIGEgbmFrZWQgU09MSUNJVCBhbmQgZ2V0IHRoZSByZXNlcnZlZCBJUCB0aGF0 IHRoZSBzZXJ2ZXIgd2FzIGNvbmZpZ3VyZWQgdG8gZ2l2ZSBpdCwgb3IgaXQgd2lsbCBkbyBhIENP TkZJUk0gd2l0aCB0aGUgYWRkcmVzcyBpdCBvYnRhaW5lZCBmcm9tIGEgZGlmZmVyZW50IGxpbmsg YW5kIHRoZSBzZXJ2ZXIgd2lsbCBSRVBMWSBmb3IgdGhhdCBhZGRyZXNzIGdpdmluZyBpdCAwIGxp ZmV0aW1lcyB0byBpbnN0cnVjdCB0aGUgY2xpZW50IHRoYXQgdGhlIGFkZHJlc3MgaXMgbm8gbG9u Z2VyIHVzYWJsZS4NClRoZW4gdGhlIGNsaWVudCBnb2VzIGJhY2sgdG8gdGhlIFNPTElDSVQgYW5k IGdldHMgdGhlIHJlc2VydmVkIElQIHRoYXQgdGhlIHNlcnZlciB3YXMgY29uZmlndXJlZCB0byBn aXZlIGl0Lg0KDQotLQ0KQW5kcmUgS29zdHVyDQo= From nobody Thu Feb 9 08:28:36 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DD7129B9E for ; Thu, 9 Feb 2017 08:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 62pOmx4jbilP for ; Thu, 9 Feb 2017 08:28:33 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA14129B8E for ; Thu, 9 Feb 2017 08:28:33 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ESAQCvl5xY/xUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8hQWGBCQeNWpIJkyeCD4IMhiICgmo/GAECAQEBAQEBAQNfKIR?= =?us-ascii?q?pAQEBAQMSG0wQAgEIDQEDBAEBCx0HMhQJCAIEDgUIGolSAaU3jQcmAosnAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYZNhG6BPIMCGDSCfoIxBYl0kXwBnGeGL5MTHzl?= =?us-ascii?q?+TxWEewUdgWF1hkQrgQMBgQsBAQE?= X-IPAS-Result: =?us-ascii?q?A2ESAQCvl5xY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgm8?= =?us-ascii?q?hQWGBCQeNWpIJkyeCD4IMhiICgmo/GAECAQEBAQEBAQNfKIRpAQEBAQMSG0wQA?= =?us-ascii?q?gEIDQEDBAEBCx0HMhQJCAIEDgUIGolSAaU3jQcmAosnAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBHYZNhG6BPIMCGDSCfoIxBYl0kXwBnGeGL5MTHzl+TxWEewUdgWF1h?= =?us-ascii?q?kQrgQMBgQsBAQE?= X-IronPort-AV: E=Sophos;i="5.35,137,1484024400"; d="scan'208,217";a="214676456" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Feb 2017 11:28:26 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 11:28:27 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 11:28:25 -0500 From: "Mudric, Dusan (Dusan)" To: Ted Lemon Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EA== Date: Thu, 9 Feb 2017 16:28:24 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457AA18ABBAZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:28:35 -0000 --_000_9142206A0C5BF24CB22755C8EC422E457AA18ABBAZUS1EXMB03glob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The DHCPv6 client gets the address. Since I did not want to change the clie= nt, I passed the address to the application to do the validation. The appli= cation found out the address is not usable. The client can get a feedback f= rom the application that the address is not usable, or the client can be co= nfigured with the policy rules to validate the address itself. Dusan From: Ted Lemon [mailto:mellon@fugue.com] Sent: Thursday, February 09, 2017 11:25 AM To: Mudric, Dusan (Dusan) Cc: Bernie Volz; dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition On Feb 9, 2017, at 11:06 AM, Mudric, Dusan (Dusan) > wrote: If the client is able to tell the server that the address cannot be used, t= he administrator should be able to get some notification about the problem = (e.g. an alarm), and find in the server log there was the configuration pro= blem. The server might be able to automatically solve the issue. For exampl= e, the server can be configured with different address pools (e.g. using di= fferent address types) and the server can offer the address from a differen= t address pool. How does the client know that the address "cannot be used"? --_000_9142206A0C5BF24CB22755C8EC422E457AA18ABBAZUS1EXMB03glob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The DHCPv6 client gets th= e address. Since I did not want to change the client, I passed the address = to the application to do the validation. The application found out the address is not usable. The client can get a feedback from th= e application that the address is not usable, or the client can be configur= ed with the policy rules to validate the address itself.<= /p>

 <= /p>

Dusan

 

From: Ted Lemo= n [mailto:mellon@fugue.com]
Sent: Thursday, February 09, 2017 11:25 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

 

On Feb 9, 2017, at 11:06 AM, Mudric, Dusan (Dusan) &= lt;dmudric@avaya.com> wrote:

If the client is able to tell the serv= er that the address cannot be used, the administrator should be able to get= some notification about the problem (e.g. an alarm), and find in the server log there was the configuration problem. The server mig= ht be able to automatically solve the issue. For example, the server can be= configured with different address pools (e.g. using different address type= s) and the server can offer the address from a different address pool.

 

How does the client know that the address "cann= ot be used"?

 

--_000_9142206A0C5BF24CB22755C8EC422E457AA18ABBAZUS1EXMB03glob_-- From nobody Thu Feb 9 08:30:36 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A254E129B97 for ; Thu, 9 Feb 2017 08:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 Mlr8Z2MF3w2F for ; Thu, 9 Feb 2017 08:30:33 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1416F129B6C for ; Thu, 9 Feb 2017 08:30:33 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id s186so9933783qkb.1 for ; Thu, 09 Feb 2017 08:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9k/ldkgHZTbTIPOQiXBmWdj7hQ9wgMhbK8G1UNB+vBQ=; b=eHC2qXXZSRfjh8lNU5hIBj0M8z4oUHYcT+IH/h+eRQI4JRXwzEwzPDBmb+tynxMwMi EyyTqByHGKfh4jRj1YyUhkQl27LXFhItKonuH5XlWLfkRJ47Z8wwli7YbIwDEc7qIzgX uTu7fZIi99NBYSpABtPaxklDGPKiz0hJVAo1qFTZjIghM3Iny9nrrN+/naAN9RWU2GYh 3IQk+Js9DLcm2RctoYiPrIYPIaYbqfnWSy6nUAVBCEMb6Ve9+in/MBeHSRdFIvIys7Uc hWzd8ZPzB4RHohjitkB8swOE8uAdYfedU/5GrCRhQJiTGGva9SC9hLc+7YkQQkcYMazO FZ/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9k/ldkgHZTbTIPOQiXBmWdj7hQ9wgMhbK8G1UNB+vBQ=; b=tTWXlcKPuPtDd8UhFxeJ9Gr9Zn4L4mT9wPcBYvAErAgJ7j6E+BOcU8dfHiAF9dNwxf tntXSOXJplfB6cpQMdvOdpqghpH1AoxuN4R9eSTvPbO03ixldZM0zGx/Puz826A+/mjX 487cGoLktjmCzVKy/MruaA0fqbdsxPzQfnzMSEBd8LtYwnlQ70+SMskAfO2FmWBIJEyR tSbW033WxWwXTIygpPtxKjryHV9DZnhKpkRgYgOMzvC6VOyc3u4bz/yHPf9UQYY7wi8G RTMus45qyS0QYIjtKHqJyBI6rGhLdfGORjW671xrXSm+ziT2Xm3fBSHiDCUEnI3XFFAG Ub6Q== X-Gm-Message-State: AMke39ngCgXjQ6midKCSpvSOlmjV+XPV2Nbsi4jwEmZgqbOCs+r3Au2pFsLk4w8TwiF9Sw== X-Received: by 10.55.150.199 with SMTP id y190mr3490969qkd.273.1486657832217; Thu, 09 Feb 2017 08:30:32 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 43sm9531840qty.26.2017.02.09.08.30.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 08:30:30 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C7A3F108-8A64-4A47-A203-CDA83113BBD8" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 11:30:29 -0500 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> To: "Mudric, Dusan (Dusan)" References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:30:34 -0000 --Apple-Mail=_C7A3F108-8A64-4A47-A203-CDA83113BBD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2017, at 11:28 AM, Mudric, Dusan (Dusan) = wrote: > The DHCPv6 client gets the address. Since I did not want to change the = client, I passed the address to the application to do the validation. = The application found out the address is not usable. The client can get = a feedback from the application that the address is not usable, or the = client can be configured with the policy rules to validate the address = itself. How does the application determine that the address is not usable? = What is the validation process? --Apple-Mail=_C7A3F108-8A64-4A47-A203-CDA83113BBD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 9, 2017, at 11:28 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote:
The DHCPv6 client gets = the address. Since I did not want to change the client, I passed the = address to the application to do the validation. The application found = out the address is not usable. The client can get a feedback from the = application that the address is not usable, or the client can be = configured with the policy rules to validate the address = itself.

How = does the application determine that the address is not usable?   = What is the validation process?


= --Apple-Mail=_C7A3F108-8A64-4A47-A203-CDA83113BBD8-- From nobody Thu Feb 9 08:37:20 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35344129BC7 for ; Thu, 9 Feb 2017 08:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4BDE02nLIor5 for ; Thu, 9 Feb 2017 08:37:15 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5071D129BC0 for ; Thu, 9 Feb 2017 08:37:15 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ESAQASmpxY/xUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8hQWGBCQeNWpIJkyeCD4IMhiICgmo/GAECAQEBAQEBAQNfKIR?= =?us-ascii?q?pAQEBAQMSG0wQAgEIDQEDBAEBCx0HMhQJCAIEDgUIGolSAaU7jQcmAosnAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYZNhG6BPIMaNIJ+gjEFiXSRfAGcZ4YvkxMfOX5?= =?us-ascii?q?PFYUAHYFhdYZEK4EDAYELAQEB?= X-IPAS-Result: =?us-ascii?q?A2ESAQASmpxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgm8?= =?us-ascii?q?hQWGBCQeNWpIJkyeCD4IMhiICgmo/GAECAQEBAQEBAQNfKIRpAQEBAQMSG0wQA?= =?us-ascii?q?gEIDQEDBAEBCx0HMhQJCAIEDgUIGolSAaU7jQcmAosnAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBHYZNhG6BPIMaNIJ+gjEFiXSRfAGcZ4YvkxMfOX5PFYUAHYFhdYZEK?= =?us-ascii?q?4EDAYELAQEB?= X-IronPort-AV: E=Sophos;i="5.35,137,1484024400"; d="scan'208,217";a="190094964" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Feb 2017 11:37:13 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 11:37:12 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 11:37:11 -0500 From: "Mudric, Dusan (Dusan)" To: Ted Lemon Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EAAKQI6AAB7vbSA= Date: Thu, 9 Feb 2017 16:37:11 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457AA18B12AZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:37:17 -0000 --_000_9142206A0C5BF24CB22755C8EC422E457AA18B12AZUS1EXMB03glob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The application does the semantic check for the address and, if the address= is semantically correct, checks if the device using the offered address ca= n be reached within the domain the in which device has to communicate. If, = for example, the device has to be globally reachable, the address has to be= an unreserved, or not deprecated, global address. Dusan From: Ted Lemon [mailto:mellon@fugue.com] Sent: Thursday, February 09, 2017 11:30 AM To: Mudric, Dusan (Dusan) Cc: Bernie Volz; dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition On Feb 9, 2017, at 11:28 AM, Mudric, Dusan (Dusan) > wrote: The DHCPv6 client gets the address. Since I did not want to change the clie= nt, I passed the address to the application to do the validation. The appli= cation found out the address is not usable. The client can get a feedback f= rom the application that the address is not usable, or the client can be co= nfigured with the policy rules to validate the address itself. How does the application determine that the address is not usable? What i= s the validation process? --_000_9142206A0C5BF24CB22755C8EC422E457AA18B12AZUS1EXMB03glob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The application does the = semantic check for the address and, if the address is semantically correct,= checks if the device using the offered address can be reached within the domain the in which device has to communicate. If, for example,= the device has to be globally reachable, the address has to be an unreserv= ed, or not deprecated, global address.

 <= /p>

Dusan

 

From: Ted Lemo= n [mailto:mellon@fugue.com]
Sent: Thursday, February 09, 2017 11:30 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

 

On Feb 9, 2017, at 11:28 AM, Mudric, Dusan (Dusan) &= lt;dmudric@avaya.com> wrote:

The DHCPv6 client gets th= e address. Since I did not want to change the client, I passed the address = to the application to do the validation. The application found out the address is not usable. The client can get a feedback from th= e application that the address is not usable, or the client can be configur= ed with the policy rules to validate the address itself.<= /p>

 

How does the application determine that the address = is not usable?   What is the validation process?

 

 

--_000_9142206A0C5BF24CB22755C8EC422E457AA18B12AZUS1EXMB03glob_-- From nobody Thu Feb 9 08:39:26 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D021129BD4 for ; Thu, 9 Feb 2017 08:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 dI-jha2KNm3f for ; Thu, 9 Feb 2017 08:39:24 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350D8129BCF for ; Thu, 9 Feb 2017 08:39:24 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id v23so9192114qtb.0 for ; Thu, 09 Feb 2017 08:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hCmP4JuAI9iBAVBAHJtPPkW1JkKX2BdmOZha2k2hFqk=; b=bGHIWNy0OK/ngahVkA+yw885d/9QrAS+ww4LGPYyH/vU7t0+GvWfG66s7ThKMQQYWl BfLuSmgr4PBAZb/ZnpUlbdZxqyzDUQxDWO8gc1SIGPMu3rbbcai3oLDYlIucY/zQjIrY C0nRIr+BljaEwSOZJiIfDiqb8U3IsjoODOAMGOfP4/Cm+wCgfFFVuHKmirYzgdtG6hC/ B0KH5WxRRojDAdWiaSbT5z8xQs6l5yltnPTEzufK5CB02ckWOTyEkFtG8sHz/uQG55W/ GL0K5zUb8Rr29ZFbqM/I/wU6nNMuXlQGWkFcyp1YLpiCnwsAfRYD1HECWjmmjWVKkH+X XWVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hCmP4JuAI9iBAVBAHJtPPkW1JkKX2BdmOZha2k2hFqk=; b=rYIUYyB84SjUiio2FGSsL3QND5HxhVRRdrvyj4/kIW1YhMhV+jNOqd58DbEKkc1AND dFNUOM1v8wIJkrccUWCtmX8BEchu0p148EojDWEoCIJuCIccKxkPiQSSl22Ha+tfMeN5 HOWdLitjyGdhlqBVc0gzR5karXCDp4+11YSWWmnavWNmLJHayYgV1etMrHEY9BG/YAGU eMGOl04N7MOUb/q0l0Hlx+/g2wTJVxUIHge7RySQuNRsdFLGCAzgSvlAjh66v/MCC51Q V7uxB+1TajJ3w9FTZ4UqnOvmzSNMpK+74K2zabtrShY8qc9mO2xTQooTrWE3Z+qZseG5 nitQ== X-Gm-Message-State: AMke39k2f7tHBoJOGsNdehWBoXR/KokQK3Z2oZGc9lg2K60wPBR22j6RW3SJvdzSNEt79g== X-Received: by 10.237.55.97 with SMTP id i88mr3984674qtb.143.1486658363395; Thu, 09 Feb 2017 08:39:23 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 23sm9559003qtp.20.2017.02.09.08.39.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 08:39:22 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_61EBD1F4-56B2-43E7-A300-0CAF5BFD2422" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 11:39:20 -0500 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> To: "Mudric, Dusan (Dusan)" References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:39:25 -0000 --Apple-Mail=_61EBD1F4-56B2-43E7-A300-0CAF5BFD2422 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2017, at 11:37 AM, Mudric, Dusan (Dusan) = wrote: > The application does the semantic check for the address and, if the = address is semantically correct, checks if the device using the offered = address can be reached within the domain the in which device has to = communicate. If, for example, the device has to be globally reachable, = the address has to be an unreserved, or not deprecated, global address. OK. Why can't the DHCP server do this validation? --Apple-Mail=_61EBD1F4-56B2-43E7-A300-0CAF5BFD2422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 9, 2017, at 11:37 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote:
The application does = the semantic check for the address and, if the address is semantically = correct, checks if the device using the offered address can be reached = within the domain the in which device has to communicate. If, for = example, the device has to be globally reachable, the address has to be = an unreserved, or not deprecated, global = address.

OK. =   Why can't the DHCP server do this validation?


= --Apple-Mail=_61EBD1F4-56B2-43E7-A300-0CAF5BFD2422-- From nobody Thu Feb 9 08:46:31 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC28129BA8 for ; Thu, 9 Feb 2017 08:46:28 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IbBlTBXDb6-T for ; Thu, 9 Feb 2017 08:46:26 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [81.174.135.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BB8129421 for ; Thu, 9 Feb 2017 08:46:26 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <91[...] Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 41CF31A071 for ; Thu, 9 Feb 2017 16:46:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> Date: Thu, 9 Feb 2017 16:46:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8 F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> To: dhcwg X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:46:28 -0000 "Mudric, Dusan (Dusan)" wrote: > One server is configured to statically assign IPv6 addresses (based on = the client MAC) or with a pool of IPv6 addresses for the local link. If = a client on that location assigns the misconfigured address it becomes = unreachable. A user does not even know how to spell DHCPv6 and all = he/she experiences is that the device is unusable. The network operator = does not get any indication that the device is out of service. And just how does the client differentiate between that being a = deliberate policy choice by the admin (perhaps that location is not = supposed to have outside IPv6 connectivity) and a server = misconfiguration ? Besides, just how is that different from other (eg DHCP4) setups ? If I = configure the HCP server to give the wrong router address then clients = get broken network configs. At the end of the day, unless you are going to build an all-knowing, = globe spanning, AI service that auto-configures everything - then you = have to allow for admins to have some intelligence and some competency = in their work. So far I've seen nothing in your suggestions that goes = beyond "the admin may make a mistake and then things are broken". yes we = can make mistakes - but finding and dealing them is part of the job. So, other than "the admin may make a mistake", what use cases do you = have ? "Mudric, Dusan (Dusan)" wrote: > The application does the semantic check for the address and, if the = address is semantically correct, checks if the device using the offered = address can be reached within the domain the in which device has to = communicate. If, for example, the device has to be globally reachable, = the address has to be an unreserved, or not deprecated, global address. You have **NOT** described anything related to whether the address = issued is usable at the network level, basically at the level DHCP is = working at. By your own admission, the device **DOES** have a valid = working address, but for some reason the **APPLICATION** cannot use it. = The **APPLICATION** should report that there is a communications problem = - this is how it works normally. The address may well be perfectly = usable for other traffic. Part of troubleshooting such an issue is to look at the network = connectivity and the requirements of the application. This sounds very = much like the refrain you hear from users who declare "the internet is = down" because the web page they are trying to reach isn't working. From nobody Thu Feb 9 08:47:49 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58D9129BC0 for ; Thu, 9 Feb 2017 08:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 aqm-JKMsuZy7 for ; Thu, 9 Feb 2017 08:47:46 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A08A129B85 for ; Thu, 9 Feb 2017 08:47:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ESAQCJnJxY/xUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8hQWGBCQeNWpIJkyeCD4IMhiICgms/GAECAQEBAQEBAQNfKIR?= =?us-ascii?q?pAQEBAQMSG0wQAgEIDQEDBAEBCx0HMhQJCAIEDgUIGolSAaU0jQcmAospAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYZNhG6BPIMCGDSCfoIxBYl0kXwBnGeGL5MTHzl?= =?us-ascii?q?+TxWGfnWGRCuBAwGBCwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2ESAQCJnJxY/xUHmMZdGQEBAQEBAQEBAQEBBwEBAQEBgm8?= =?us-ascii?q?hQWGBCQeNWpIJkyeCD4IMhiICgms/GAECAQEBAQEBAQNfKIRpAQEBAQMSG0wQA?= =?us-ascii?q?gEIDQEDBAEBCx0HMhQJCAIEDgUIGolSAaU0jQcmAospAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBHYZNhG6BPIMCGDSCfoIxBYl0kXwBnGeGL5MTHzl+TxWGfnWGRCuBA?= =?us-ascii?q?wGBCwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,137,1484024400"; d="scan'208,217";a="190096309" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Feb 2017 11:47:43 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 11:47:43 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 11:47:42 -0500 From: "Mudric, Dusan (Dusan)" To: Ted Lemon Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EAAKQI6AAB7vbSAAMyFpAABwmj1w Date: Thu, 9 Feb 2017 16:47:42 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457AA18B5EAZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:47:48 -0000 --_000_9142206A0C5BF24CB22755C8EC422E457AA18B5EAZUS1EXMB03glob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The server can do the same validation. If the server does the validation, i= t will be a new feature and there will be a mix of servers that do and do-n= ot provide this validation. The client either has to talk to the server tha= t does provide the validation or do the validation itself. This is the first problem statement. There are two more: - Assignment of multiple IPV6 addresses, that the client cannot su= pport - A change of IPv6 address, that the client cannot handle Dusan From: Ted Lemon [mailto:mellon@fugue.com] Sent: Thursday, February 09, 2017 11:39 AM To: Mudric, Dusan (Dusan) Cc: Bernie Volz; dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition On Feb 9, 2017, at 11:37 AM, Mudric, Dusan (Dusan) > wrote: The application does the semantic check for the address and, if the address= is semantically correct, checks if the device using the offered address ca= n be reached within the domain the in which device has to communicate. If, = for example, the device has to be globally reachable, the address has to be= an unreserved, or not deprecated, global address. OK. Why can't the DHCP server do this validation? --_000_9142206A0C5BF24CB22755C8EC422E457AA18B5EAZUS1EXMB03glob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The server can do the sam= e validation. If the server does the validation, it will be a new feature a= nd there will be a mix of servers that do and do-not provide this validation. The client either has to talk to the server that does pro= vide the validation or do the validation itself.

 <= /p>

This is the first problem= statement. There are two more:

- =          Assignment of mul= tiple IPV6 addresses, that the client cannot support

- =          A change of IPv6 = address, that the client cannot handle

 <= /p>

Dusan

 

From: Ted Lemo= n [mailto:mellon@fugue.com]
Sent: Thursday, February 09, 2017 11:39 AM
To: Mudric, Dusan (Dusan)
Cc: Bernie Volz; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

 

On Feb 9, 2017, at 11:37 AM, Mudric, Dusan (Dusan) &= lt;dmudric@avaya.com> wrote:

The application does the = semantic check for the address and, if the address is semantically correct,= checks if the device using the offered address can be reached within the domain the in which device has to communicate. If, for example,= the device has to be globally reachable, the address has to be an unreserv= ed, or not deprecated, global address.

 

OK.   Why can't the DHCP server do this validat= ion?

 

 

--_000_9142206A0C5BF24CB22755C8EC422E457AA18B5EAZUS1EXMB03glob_-- From nobody Thu Feb 9 08:59:57 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D9B129C06 for ; Thu, 9 Feb 2017 08:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 mLm2LCC0JVtT for ; Thu, 9 Feb 2017 08:59:44 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93EF129BF6 for ; Thu, 9 Feb 2017 08:53:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GcAQCanZxY/yYyC4ddGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBBYYEJB59jkyeCD4FJQyaFfAKCa0AXAQIBAQEBAQEBA18ogls?= =?us-ascii?q?9BgcvAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAgESKDQQBwQCAQgNAQMEAQELF?= =?us-ascii?q?AkHMhQJCAIEARIIGolKCAGlOI0HJgKLKgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2?= =?us-ascii?q?GTYRugTyDAhiDMoIxBZtwAYZsjXOICIYvkxMgATd+TxU8hkJ1hkQrgQMBgQsBA?= =?us-ascii?q?QE?= X-IPAS-Result: =?us-ascii?q?A2GcAQCanZxY/yYyC4ddGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?BYYEJB59jkyeCD4FJQyaFfAKCa0AXAQIBAQEBAQEBA18ogls9BgcvAQEBAQEBA?= =?us-ascii?q?QEBAQEBARwCD0EBARgBAQEBAgESKDQQBwQCAQgNAQMEAQELFAkHMhQJCAIEARI?= =?us-ascii?q?IGolKCAGlOI0HJgKLKgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GTYRugTyDAhiDM?= =?us-ascii?q?oIxBZtwAYZsjXOICIYvkxMgATd+TxU8hkJ1hkQrgQMBgQsBAQE?= X-IronPort-AV: E=Sophos;i="5.35,137,1484024400"; d="scan'208";a="227441326" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Feb 2017 11:53:19 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 11:53:19 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Feb 2017 11:53:19 -0500 From: "Mudric, Dusan (Dusan)" To: Simon Hobson , dhcwg Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+9CIAACln0wA== Date: Thu, 9 Feb 2017 16:53:18 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18B73@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8 F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:59:45 -0000 " By your own admission, the device **DOES** have a valid working address, = but for some reason the **APPLICATION** cannot use it." I was just saying the validation is done in the application because DHCPv6 = client cannot do it. It is about the network reachability and not about the= application. Site-Local (FEC0::/10), for example, cannot be used by any de= vice (RFC 3879: Deprecating Site Local Addresses. The prefix MUST NOT be re= assigned for other use except by a future IETF standards action.) Dusan -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simon Hobson Sent: Thursday, February 09, 2017 11:46 AM To: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition "Mudric, Dusan (Dusan)" wrote: > One server is configured to statically assign IPv6 addresses (based on th= e client MAC) or with a pool of IPv6 addresses for the local link. If a cli= ent on that location assigns the misconfigured address it becomes unreachab= le. A user does not even know how to spell DHCPv6 and all he/she experience= s is that the device is unusable. The network operator does not get any ind= ication that the device is out of service. And just how does the client differentiate between that being a deliberate = policy choice by the admin (perhaps that location is not supposed to have o= utside IPv6 connectivity) and a server misconfiguration ? Besides, just how is that different from other (eg DHCP4) setups ? If I con= figure the HCP server to give the wrong router address then clients get bro= ken network configs. At the end of the day, unless you are going to build an all-knowing, globe = spanning, AI service that auto-configures everything - then you have to all= ow for admins to have some intelligence and some competency in their work. = So far I've seen nothing in your suggestions that goes beyond "the admin ma= y make a mistake and then things are broken". yes we can make mistakes - bu= t finding and dealing them is part of the job. So, other than "the admin may make a mistake", what use cases do you have ? "Mudric, Dusan (Dusan)" wrote: > The application does the semantic check for the address and, if the addre= ss is semantically correct, checks if the device using the offered address = can be reached within the domain the in which device has to communicate. If= , for example, the device has to be globally reachable, the address has to = be an unreserved, or not deprecated, global address. You have **NOT** described anything related to whether the address issued i= s usable at the network level, basically at the level DHCP is working at. B= y your own admission, the device **DOES** have a valid working address, but= for some reason the **APPLICATION** cannot use it. The **APPLICATION** sho= uld report that there is a communications problem - this is how it works no= rmally. The address may well be perfectly usable for other traffic. Part of troubleshooting such an issue is to look at the network connectivit= y and the requirements of the application. This sounds very much like the r= efrain you hear from users who declare "the internet is down" because the w= eb page they are trying to reach isn't working. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dhcwg&d=3DDQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3DKqFrsW5PMmj9eF_ImRLdVyBEBXnnp1_49yauNwdixwE&= s=3Dnl7CEbTMCiHR8hrfTbjU1VqkR6r2wFunbJnd1xj5SKk&e=3D=20 From nobody Thu Feb 9 09:00:09 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84ACC129C12 for ; Thu, 9 Feb 2017 09:00:08 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=incognito-com.20150623.gappssmtp.com 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 HrCdg-bt2dHO for ; Thu, 9 Feb 2017 09:00:00 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4447E129BFC for ; Thu, 9 Feb 2017 08:59:45 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id 123so3083969ybe.3 for ; Thu, 09 Feb 2017 08:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=incognito-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dsb071FxcPg+OathPnoY1C6I0hgDGe33pqKz/CCQbD8=; b=iEpZrvd/9kBQvV3X78kSgESfn4JlBt3TpgE2KAMtEiZEiw/3lXwE2ecFPNUb+8ohfU BK/FYdixrtC3FiaO1nBzbjajkf2ABhYea5C8PXB0zHP5h5PQCDN/AP5KHs/aXeMHoXsG jcGLYmGmrfhSBInuaGmb7aZBFrUBf3HPQFZLKlFW0Hk0f0OR1ftYnQOvAXEQJEuTPmKM QvgZQpL/K25WmRC6xnQIDxv4A3VaPvPVmOuFGKcs2WgZz54/KUOlN+Dl+QEmp1SAjVEN i8r8aT9gC3c6Inwta+ODNV1M45YaCowC5k1Ac07qn2TKLy/6Yn074k8oGHYFSAnIIwEy 6DIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dsb071FxcPg+OathPnoY1C6I0hgDGe33pqKz/CCQbD8=; b=PThmUdpYlReId/eCW+fK2Yi49erto6fWT3SI5fkeWm+NJgirll8wifq+mps0N58GoL Hd7wQEoCyhgMnhg3c2qKNgczYEHeMaSdfezVKUXHrvbzT8byq9D/3v78u99tO+fTumHI IGVHFiWPrlVDCO93EdiAWwYd5BLnsluAitRmNlwzZu4F2zxwY3lWZS+ClBTjuWfQj+Ki bLgAkDZyPBnUevbRfoYIWv4wocBThuNUmhP/wEEwd62dq0d/7EX9nMUYYBrmtt1JEXVW dWpwl+2gtJXDAOlxuTlLj7HGOyzulpwmoXseBMhYbInTcvGwwMcumvohDU3Z/hRl5CZ+ INYQ== X-Gm-Message-State: AMke39lYGIcEGkaG3xu4iXMZHX+gH94us7xZesG/XsZIt10QolNEIWJ+Tu9oIGF5iatMecbHISV3HjBHKjgNtaJK X-Received: by 10.37.97.15 with SMTP id v15mr2929619ybb.70.1486659584253; Thu, 09 Feb 2017 08:59:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.113.5 with HTTP; Thu, 9 Feb 2017 08:59:43 -0800 (PST) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> From: Andre Kostur Date: Thu, 9 Feb 2017 08:59:43 -0800 Message-ID: To: "Mudric, Dusan (Dusan)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg , Ted Lemon , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:00:08 -0000 On Thu, Feb 9, 2017 at 8:47 AM, Mudric, Dusan (Dusan) wrote: > This is the first problem statement. There are two more: > > - Assignment of multiple IPV6 addresses, that the client cannot > support Already dealt with by the protocol. The server OFFERs 2 addresses, the client just REQUESTs one of them. -- Andre Kostur From nobody Thu Feb 9 09:14:00 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAA3129C06 for ; Thu, 9 Feb 2017 09:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 EKgpL3YiJVeR for ; Thu, 9 Feb 2017 09:13:58 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4955E129BFD for ; Thu, 9 Feb 2017 09:13:58 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id v23so10253142qtb.0 for ; Thu, 09 Feb 2017 09:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NWJbXnULnKmkAkic3dFoIU/L06lOL1+0mhPHYUJW0kI=; b=huWGQn27SA0ljEDTEYRFAWNLts7qYUpxZUEtjNSH/noNj0SZCGqYePThnCCGw+dxOd BgOXSkWgb/Q6E4QIQb+p1wlmB/stnp0XwiZ6/i3zF4VugYCEmYpHqHTigwZv9eWmsj2K jGFWlAed4bV13JlMIlzWi7fydN+k4375eA+rmJasVbrtyI3AYsdsOi/4DjsPL9SAZlPA IXCVbG1fnc5P86mYsH4rkvq2MEY5p3dGl2x/ZqlsOpYq8Lz1yrn4KtrRiC4NkD72taHj 16mz99NJ9AUtWDQgZ5yFdXNcZfGHrxG0mFXU8rJmnWIdMhEtO08uDhlby8Zp8+S93hDJ VslA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NWJbXnULnKmkAkic3dFoIU/L06lOL1+0mhPHYUJW0kI=; b=TZQr3Zg5PpiG+0r3aIi3NGJ54JUiWSxAl+PfNlwBwQT5Y+emvJEadXZpZMDrcEq9yM SbSLbgbSvsbjKRM7PjVwxMBKvkzilfv3kyiJDK4ZR5eA+Y2E+1CMW/RLENAassLHFZec Xkx7BkLZqm+rJHuELqEfHxyk5dDCg8uimmYWH8Ya+MJzWTNRprTvQQ86IH01kwhcrs8/ tDuN+WXzTlfzuCHEfLZ0EJTjH9botcAg+YOKZsPg0beCAT/+MuOP7QLInrmjHr8aBRzH 02C2VODjqsMqZr1MqzlgIqa93JBwdDeCnG8b5XGF/BE2yI3ev0Xr5rFQbzBCpFNPfWVD 7Ffg== X-Gm-Message-State: AMke39kWS9PPKTRzn1kyQaLAYzqjoOeOJuZzdFsUgXjTgkK3VJFRWYox4gNPGnmp4PnTDA== X-Received: by 10.200.47.152 with SMTP id l24mr3989131qta.212.1486660437417; Thu, 09 Feb 2017 09:13:57 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k19sm9628843qtf.37.2017.02.09.09.13.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 09:13:56 -0800 (PST) From: Ted Lemon Message-Id: <9A870D5A-2447-48C8-BCE1-B40594E710FD@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CFF79974-4155-46DA-BB61-237E51123F3E" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 12:13:54 -0500 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> To: "Mudric, Dusan (Dusan)" References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:13:59 -0000 --Apple-Mail=_CFF79974-4155-46DA-BB61-237E51123F3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 9, 2017, at 11:47 AM, Mudric, Dusan (Dusan) = wrote: > The server can do the same validation. If the server does the = validation, it will be a new feature and there will be a mix of servers = that do and do-not provide this validation. The client either has to = talk to the server that does provide the validation or do the validation = itself. So why is it easier to have the client do the validation than the = server? You're adding protocol to make this work, and in order for = this to be useful, changes are required on the server anyway. These = changes are quite a bit more complex than the changes required to simply = do whatever validation you are arguing should be done. So why not do = it the easy way instead of the hard way? =20 > This is the first problem statement. There are two more: > - Assignment of multiple IPV6 addresses, that the client = cannot support Then the client is broken. Why not fix it instead of adding more = protocol? > - A change of IPv6 address, that the client cannot handle Again, the client is broken. Why not fix it instead of adding more = protocol? --Apple-Mail=_CFF79974-4155-46DA-BB61-237E51123F3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 9, 2017, at 11:47 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote:
The server can do the = same validation. If the server does the validation, it will be a new = feature and there will be a mix of servers that do and do-not provide = this validation. The client either has to talk to the server that does = provide the validation or do the validation = itself.

So why = is it easier to have the client do the validation than the server? =   You're adding protocol to make this work, and in order for this = to be useful, changes are required on the server anyway.   These = changes are quite a bit more complex than the changes required to simply = do whatever validation you are arguing should be done.   So why not = do it the easy way instead of the hard way?
 
This is the first problem statement. There are two more:
-          Assignment of multiple IPV6 addresses, = that the client cannot support

Then the client is broken.   Why not fix it = instead of adding more protocol?

-          A change of IPv6 address, that the client = cannot handle

Again, the client is broken.   Why not fix it instead of = adding more protocol?

= --Apple-Mail=_CFF79974-4155-46DA-BB61-237E51123F3E-- From nobody Thu Feb 9 09:14:35 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AF0129C27 for ; Thu, 9 Feb 2017 09:14:34 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=incognito-com.20150623.gappssmtp.com 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 qcmlvulv8_3L for ; Thu, 9 Feb 2017 09:14:32 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F6E129C24 for ; Thu, 9 Feb 2017 09:14:32 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id o65so3275701ybo.2 for ; Thu, 09 Feb 2017 09:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=incognito-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IbFB7gxD+sv1+iDKwzcZiPjlgRmSA9E+rPTA8Uap6Fw=; b=DRSNoXUZQql1r5FOZglZe6eQq+DpUmJ7stxjpMC0nqCqjuuTmuot4hDn5UjxsKN13j j0+LnFQuRCqIHnmipHDC6f4ih5sM+nOjDMMHol0Vx3WmXibgLjniHhnsfr/seYqGxczx 1CyvZjVc/ro+GLV5mj3EifK6yifi0adUKIjNSHd27GwdzYAh5x+eUtdbswCMPOY5UpaM DqdoOshFLM6jftZ/AiAFlDJSwn3t0QBXZA8HS1RpS1sYTqg3pIW9ZdrTk+mmHPYnNqhf ZbGDB28soTgkGSgOneDQ5RvPu0ZALgt1zglolVYKFon59tExiT0KBr14GmAeTD2wfi4B AxUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IbFB7gxD+sv1+iDKwzcZiPjlgRmSA9E+rPTA8Uap6Fw=; b=Sj3l171ipVQJ0Q88YTf50ufaBfA/tuWDY3LGzgobT7t1rVI866UeK0nUbatY/9Uxf7 ezxbl/dQ1zOTxIZ6b1G2wQgr817Q6ps/alG0b304cKQBb2LkhQhpzU1Qf30mgYC+VBiK QerhrhdzaEsduYvK6IB3eW11d6MSHQpl2XCdwwzsEwonVxEtwRIu9N6UCkXdZV+zVsDw G6+xUMGa1Ury+8W0G8tObEzk3OlaJs8KjLZTi3PJVt8acewJ98N6krJ9tgPzrenDHsDx xvqscWNTXiAEUNXTAWTFPnfquAqVldB23vAKYIQ6jL9TlHwFpM0VKNhUkC6q5dBWXvV2 3PiQ== X-Gm-Message-State: AMke39nlqRAlWXyX0mbMfARLTQbYlQ7WZyOyzGSza2iE20IBxJFeX6KpJ1gNLieRFBbZOFbvOAIbG1vdG12KCnc4 X-Received: by 10.37.38.12 with SMTP id m12mr3116923ybm.30.1486660471387; Thu, 09 Feb 2017 09:14:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.113.5 with HTTP; Thu, 9 Feb 2017 09:14:30 -0800 (PST) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18B73@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B73@AZ-US1EXMB03.global.avaya.com> From: Andre Kostur Date: Thu, 9 Feb 2017 09:14:30 -0800 Message-ID: To: "Mudric, Dusan (Dusan)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:14:34 -0000 On Thu, Feb 9, 2017 at 8:53 AM, Mudric, Dusan (Dusan) w= rote: > " By your own admission, the device **DOES** have a valid working address= , but for some reason the **APPLICATION** cannot use it." > > I was just saying the validation is done in the application because DHCPv= 6 client cannot do it. It is about the network reachability and not about t= he application. Site-Local (FEC0::/10), for example, cannot be used by any = device (RFC 3879: Deprecating Site Local Addresses. The prefix MUST NOT be = reassigned for other use except by a future IETF standards action.) So you don't configure your DHCP server to give out those IP addresses. Problem solved. This doesn't need a protocol change. And should it (the FEC0::/10 prefix) be reassigned for other uses in a future IETF standards action, then one would need to change your application again, and/or change the DHCP server again. And, the application may be in use in some network that already has that prefix in use because that network has not had the time to renumber that prefix into something like a Unique Local IPv6 prefix (RFC 4193). --=20 Andre Kostur From nobody Thu Feb 9 09:23:39 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14597129BED for ; Thu, 9 Feb 2017 09:23:30 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 c-SlSG5c_TlY for ; Thu, 9 Feb 2017 09:23:29 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [81.174.135.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6246B129485 for ; Thu, 9 Feb 2017 09:23:28 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <91[...] Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 493C61A071 for ; Thu, 9 Feb 2017 17:23:20 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> Date: Thu, 9 Feb 2017 17:23:18 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8 F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> To: dhcwg X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:23:30 -0000 "Mudric, Dusan (Dusan)" wrote: > - Assignment of multiple IPV6 addresses, that the client = cannot support I thought it was part of the spec that a client must be capable of being = configured with multiple addresses. As a minimum it must support 2 - one = link-local, and one globally unique if external connectivity is needed. "Mudric, Dusan (Dusan)" wrote: > I was just saying the validation is done in the application because = DHCPv6 client cannot do it. It is about the network reachability and not = about the application. Site-Local (FEC0::/10), for example, cannot be = used by any device (RFC 3879: Deprecating Site Local Addresses. The = prefix MUST NOT be reassigned for other use except by a future IETF = standards action.) 1) How does the application know that allocation of such addresses isn't = a deliberate policy decision ? 2) It's an "admin error" anyway and it will either a) be spotted fairly = quickly due to the lack of connectivity, b) obviously isn't that = important. And as I said before, there is nothing to stop the admin putting (say) = an incorrect router address in DHCPv4 - and I can't say I've seen a lot = of clamour for "we must handle this automatically" features. From nobody Thu Feb 9 19:07:28 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F7B129525; Thu, 9 Feb 2017 19:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 eFKIo2hUKswN; Thu, 9 Feb 2017 19:07:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080DC129503; Thu, 9 Feb 2017 19:07:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAI13641; Fri, 10 Feb 2017 03:07:17 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 10 Feb 2017 03:07:15 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.147]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Fri, 10 Feb 2017 11:07:09 +0800 From: "Liushucheng (Will)" To: "dhcwg@ietf.org" , "opsawg@ietf.org" , "anima@ietf.org" Thread-Topic: CASM BoF request just posted to BoF wiki Thread-Index: AdKCiHMMgNp6ZUuET/qq14mhMlioJgAvLOVg Date: Fri, 10 Feb 2017 03:07:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.79.101] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB898C19DCSZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.589D2E66.0029, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.147, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f71407a1d7d4e433bab33c03b22e97ac Archived-At: Cc: "CASM@ietf.org" Subject: [dhcwg] FW: CASM BoF request just posted to BoF wiki X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 03:07:24 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB898C19DCSZXEMA509MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJ4oCZbSBmb3J3YXJkaW5nIHRoZSB1cGRhdGVkIHZlcnNpb24gb2YgIENBU00g Qm9GIHJlcXVlc3Qgb24gYmVoYWxmIG9mIG90aGVyIHByb3BvbmVudHMuIFBsZWFzZSBmZWVsIGZy ZWUgdG8gYXNrIHF1ZXN0aW9ucyBhbmQgcHJvdmlkZSBjb21tZW50cy4gVGhhbmtzIQ0KDQotLXN0 YXJ0LS0NCg0KQ29vcmRpbmF0ZWQgQWRkcmVzcyBTcGFjZSBNYW5hZ2VtZW50IChDQVNNKQ0KDQog ICogICBEZXNjcmlwdGlvbjogT3JnYW5pemF0aW9ucyB1c2UgSVAgQWRkcmVzcyBTcGFjZSBNYW5h Z2VtZW50IChJUEFNKSB0b29scyB0byBtYW5hZ2UgdGhlaXIgSVAgYWRkcmVzcyBzcGFjZSwgb2Z0 ZW4gd2l0aCBwcm9wcmlldGFyeSBkYXRhYmFzZSBhbmQgaW50ZXJmYWNlcy4gVGhpcyB3b3JrIGlu dGVuZHMgdG8gZXZvbHZlIElQQU0gaW50byBzdGFuZGFyZGl6ZWQgaW50ZXJmYWNlcyBmb3IgY29v cmRpbmF0ZWQgbWFuYWdlbWVudCBvZiBJUCBhZGRyZXNzZXMsIGluY2x1ZGluZyBTRE4vTkZWIG5l dHdvcmtzIGFuZCBvdGhlciBmb3JtcyBvZiB2aXJ0dWFsaXphdGlvbi4gVXNlIGNhc2VzIGluY2x1 ZGUgZHluYW1pYyBhbGxvY2F0aW9uIGFuZCByZWxlYXNlIG9mIElQIGFkZHJlc3NlcyBhbmQgcHJl Zml4ZXMgYmFzZWQgb24gdXNhZ2UgKHJlYWxsb2NhdGlvbiBpbiBjYXNlIG9mIG5vIG1vcmUgaW4g dXNlKSBhbmQvb3IgdXNlciBpbnRlbnQgKGZvciBzcGVjaWZpYyBzZXJ2aWNlcykuDQoNCiAgKiAg IEFnZW5kYQ0KICAgICAqICAgUHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHVzZSBjYXNlcw0KICAgICAq ICAgUmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcmsNCiAgICAgKiAgIFBvc3NpYmxlIGNoYXJ0ZXIg Z29hbHMgYW5kIG1pbGVzdG9uZXMNCiAgICAgKiAgIE5leHQgc3RlcHMNCiAgKiAgIFN0YXR1czog V0cgRm9ybWluZw0KICAqICAgUmVzcG9uc2libGUgQUQ6IE9QUyAoQmVub2l0IENsYWlzZSwgSm9l bCBKYWVnZ2xpKQ0KICAqICAgQm9GIHByb3BvbmVudHM6IENob25nZmVuZyBYaWUoQ2hpbmEgVGVs ZWNvbSksIFJha2VzaCBLdW1hciAoSnVuaXBlciksIFlpbmcgQ2hlbmcoQ2hpbmEgVW5pY29tKSwg V2lsbCBMaXUoSHVhd2VpKQ0KICAqICAgQm9GIGNoYWlyczogVEJEDQogICogICBOdW1iZXIgb2Yg cGVvcGxlIGV4cGVjdGVkIHRvIGF0dGVuZDogMTAwDQogICogICBMZW5ndGggb2Ygc2Vzc2lvbiAo MSwgMS41LCAyLCBvciAyLjUgaG91cnMpOiAxLjUgaG91cnMNCiAgKiAgIENvbmZsaWN0cyB0byBh dm9pZCAod2hvbGUgQXJlYXMgYW5kL29yIFdHcyk6IGludGFyZWEsIG9wc2F3ZywgYW5pbWEsIHN1 cGEsIGRoYywgbmZ2cmcNCiAgKiAgIE1haWxpbmcgTGlzdDog4oCL4oCLaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYXNtPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2FzbT4NCiAgKiAgIERyYWZ0IGNoYXJ0ZXI6IFRCRA0KICAqICAgUmVsZXZhbnQg ZHJhZnRzOg0KICAgICAqICAg4oCLaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQta3VtYXItY2FzbS1wcm9ibGVtLWFuZC11c2UtY2FzZXM8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQta3VtYXItY2FzbS1wcm9ibGVtLWFuZC11c2UtY2FzZXM+DQogICAg ICogICDigItodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14aWUtcHMtY2Vu dHJhbGl6ZWQtYWRkcmVzcy1tYW5hZ2VtZW50PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXhpZS1wcy1jZW50cmFsaXplZC1hZGRyZXNzLW1hbmFnZW1lbnQ+DQogICAgICog ICDigItodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rdW1hci1jYXNtLXJl cXVpcmVtZW50cy1hbmQtZnJhbWV3b3JrPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWt1bWFyLWNhc20tcmVxdWlyZW1lbnRzLWFuZC1mcmFtZXdvcms+DQogICAgICogICDi gItodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdW4taTJhcG0tYWRkcmVz cy1wb29sLW1hbmFnZW1lbnQtYXJjaDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1zdW4taTJhcG0tYWRkcmVzcy1wb29sLW1hbmFnZW1lbnQtYXJjaD4NCiAgICAgKiAgIOKA i2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN1bi1pMmFwbS1hZGRyZXNz LXBvb2wtbWFuYWdlbWVudC15YW5nPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXN1bi1pMmFwbS1hZGRyZXNzLXBvb2wtbWFuYWdlbWVudC15YW5nPg0KDQotLWVuZC0tDQoN ClJlZ2FyZHMsDQpXaWxsIChMSVUgU2h1Y2hlbmcpDQoNCkZyb206IENBU00gW21haWx0bzpjYXNt LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaXVzaHVjaGVuZyAoV2lsbCkNClNlbnQ6 IFRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyAxMTo1NiBBTQ0KVG86IENBU01AaWV0Zi5vcmcN ClN1YmplY3Q6IFtDYXNtXSBDQVNNIEJvRiByZXF1ZXN0IGp1c3QgcG9zdGVkIHRvIEJvRiB3aWtp DQoNCkhpIGFsbCwNCg0KSeKAmW0gd3JpdGluZyB0byBub3RpZnkgeW91IHRoYXQgdGhlIENBU00g Qm9GIHJlcXVlc3Qgd2FzIGp1c3QgcG9zdGVkIGluIHRoZSBib2Ygd2lraS4gaHR0cHM6Ly90cmFj LnRvb2xzLmlldGYub3JnL2JvZi90cmFjLw0KTWFueSB0aGFua3MgZm9yIHRoZSBlZmZvcnRzIGZy b20gTWFyYywgQWRyaWFuLCBSYWtlc2ggYW5kIENob25nZmVuZy4NCg0KUGxlYXNlIGhlbHAgdG8g cmV2aWV3IGl0IGFuZCBsZXQgdXMga25vdyB5b3VyIHRob3VnaHRzLiBJ4oCZbSBjb3B5aW5nIGl0 IGJlbG93Lg0KDQotLXN0YXJ0LS0NCg0KQ2VudHJhbGl6ZWQgQWRkcmVzcyBNYW5hZ2VtZW50IChD QVNNKQ0KDQogICogICBEZXNjcmlwdGlvbjogT3JnYW5pemF0aW9ucyB1c2UgSVAgQWRkcmVzcyBT cGFjZSBNYW5hZ2VtZW50IChJUEFNKSB0b29scyB0byBtYW5hZ2UgdGhlaXIgSVAgYWRkcmVzcyBz cGFjZSwgb2Z0ZW4gd2l0aCBwcm9wcmlldGFyeSBkYXRhYmFzZSBhbmQgaW50ZXJmYWNlcy4gVGhp cyB3b3JrIGludGVuZHMgdG8gZXZvbHZlIElQQU0gaW50byBzdGFuZGFyZGl6ZWQgaW50ZXJmYWNl cyBmb3IgY2VudHJhbGl6ZWQgbWFuYWdlbWVudCBvZiBJUCBhZGRyZXNzZXMsIHNwZWNpYWxseSBp biB0aGUgY29udGV4dCBvZiBTRE4vTkZWIG5ldHdvcmtzLiBVc2UgY2FzZXMgaW5jbHVkZSBkeW5h bWljIGFsbG9jYXRpb24gYW5kIHJlbGVhc2Ugb2YgSVAgYWRkcmVzc2VzIGFuZCBwcmVmaXhlcyBi YXNlZCBvbiB1c2FnZSAocmVhbGxvY2F0aW9uIGluIGNhc2Ugb2Ygbm8gbW9yZSBpbiB1c2UpIGFu ZC9vciB1c2VyIGludGVudCAoZm9yIHNwZWNpZmljIHNlcnZpY2VzKS4NCg0KICAqICAgQWdlbmRh DQogICAgICogICBQcm9ibGVtIHN0YXRlbWVudCBhbmQgdXNlIGNhc2VzDQogICAgICogICBSZXF1 aXJlbWVudHMgYW5kIGZyYW1ld29yaw0KICAgICAqICAgUG9zc2libGUgY2hhcnRlciBnb2FscyBh bmQgbWlsZXN0b25lcw0KICAgICAqICAgTmV4dCBzdGVwcw0KICAqICAgU3RhdHVzOiBXRyBGb3Jt aW5nDQogICogICBSZXNwb25zaWJsZSBBRDogT1BTIChCZW5vaXQgQ2xhaXNlLCBKb2VsIEphZWdn bGkpDQogICogICBCb0YgcHJvcG9uZW50czogQ2hvbmdmZW5nIFhpZShDaGluYSBUZWxlY29tKSwg UmFrZXNoIEt1bWFyIChKdW5pcGVyKSwgWWluZyBDaGVuZyhDaGluYSBVbmljb20pLCBXaWxsIExp dShIdWF3ZWkpDQogICogICBCb0YgY2hhaXJzOiBUQkQNCiAgKiAgIE51bWJlciBvZiBwZW9wbGUg ZXhwZWN0ZWQgdG8gYXR0ZW5kOiAxMDANCiAgKiAgIExlbmd0aCBvZiBzZXNzaW9uICgxLCAxLjUs IDIsIG9yIDIuNSBob3Vycyk6IDEuNSBob3Vycw0KICAqICAgQ29uZmxpY3RzIHRvIGF2b2lkICh3 aG9sZSBBcmVhcyBhbmQvb3IgV0dzKTogaW50YXJlYSwgb3BzYXdnLCBhbmltYSwgc3VwYSwgZGhj LCBuZnZyZw0KICAqICAgTWFpbGluZyBMaXN0OiDigIvigItodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Nhc208aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jYXNtPg0KICAqICAgRHJhZnQgY2hhcnRlcjogVEJEDQogICogICBSZWxldmFudCBkcmFmdHM6 DQogICAgICogICDigItodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rdW1h ci1jYXNtLXByb2JsZW0tYW5kLXVzZS1jYXNlczxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1rdW1hci1jYXNtLXByb2JsZW0tYW5kLXVzZS1jYXNlcz4NCiAgICAgKiAgIOKA i2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpZS1wcy1jZW50cmFsaXpl ZC1hZGRyZXNzLW1hbmFnZW1lbnQ8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQteGllLXBzLWNlbnRyYWxpemVkLWFkZHJlc3MtbWFuYWdlbWVudD4NCiAgICAgKiAgIOKAi2h0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt1bWFyLWNhc20tcmVxdWlyZW1l bnRzLWFuZC1mcmFtZXdvcms8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt a3VtYXItY2FzbS1yZXF1aXJlbWVudHMtYW5kLWZyYW1ld29yaz4NCiAgICAgKiAgIOKAi2h0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN1bi1pMmFwbS1hZGRyZXNzLXBvb2wt bWFuYWdlbWVudC1hcmNoPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN1 bi1pMmFwbS1hZGRyZXNzLXBvb2wtbWFuYWdlbWVudC1hcmNoPg0KICAgICAqICAg4oCLaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3VuLWkyYXBtLWFkZHJlc3MtcG9vbC1t YW5hZ2VtZW50LXlhbmc8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3Vu LWkyYXBtLWFkZHJlc3MtcG9vbC1tYW5hZ2VtZW50LXlhbmc+DQotLWVuZC0tDQoNClJlZ2FyZHMs DQpXaWxsIChMSVUgU2h1Y2hlbmcpDQoNCg== --_000_C9B5F12337F6F841B35C404CF0554ACB898C19DCSZXEMA509MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLmljb24NCgl7bXNvLXN0eWxlLW5hbWU6aWNv bjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6NDU0MzY3NTQzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0MDk4OTM3MjA7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox MDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjUzNzM1 MDY5NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTgzNDEzMTA2ODt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo5 NDc4MTQxMjI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwMDg1NjQ0MDA7fQ0KQGxpc3QgbDI6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3Qt aWQ6MTI5OTA2NjcwNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODM0MTkwOTAwO30NCkBsaXN0 IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy NTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1s aXN0LWlkOjEzMTMwMjY1MDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zNTczMDIzNDt9DQpA bGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNQ0KCXtt c28tbGlzdC1pZDoxNzAyNDM0NTc1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTE1MTcyMDQ4 Mjt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1Omxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUy LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3A+DQo8cCBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5J 4oCZbSBmb3J3YXJkaW5nIHRoZSB1cGRhdGVkIHZlcnNpb24gb2YgJm5ic3A7Q0FTTSBCb0YgcmVx dWVzdCBvbiBiZWhhbGYgb2Ygb3RoZXIgcHJvcG9uZW50cy4gUGxlYXNlIGZlZWwgZnJlZSB0byBh c2sgcXVlc3Rpb25zIGFuZCBwcm92aWRlIGNvbW1lbnRzLiBUaGFua3MhPG86cD48L286cD48L3Nw YW4+PC9zdHJvbmc+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LS1zdGFydC0tPG86cD48L286cD48L3NwYW4+PC9zdHJv bmc+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Q29vcmRpbmF0ZWQgQWRkcmVzcyBTcGFjZSBNYW5hZ2VtZW50IChDQVNN KTwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0Omw0IGxldmVsMSBsZm83O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRlc2NyaXB0 aW9uOiBPcmdhbml6YXRpb25zIHVzZSBJUCBBZGRyZXNzIFNwYWNlIE1hbmFnZW1lbnQgKElQQU0p IHRvb2xzIHRvIG1hbmFnZSB0aGVpciBJUCBhZGRyZXNzIHNwYWNlLCBvZnRlbiB3aXRoIHByb3By aWV0YXJ5IGRhdGFiYXNlIGFuZCBpbnRlcmZhY2VzLiBUaGlzIHdvcmsgaW50ZW5kcyB0byBldm9s dmUgSVBBTSBpbnRvIHN0YW5kYXJkaXplZCBpbnRlcmZhY2VzDQogZm9yIGNvb3JkaW5hdGVkIG1h bmFnZW1lbnQgb2YgSVAgYWRkcmVzc2VzLCBpbmNsdWRpbmcgU0ROL05GViBuZXR3b3JrcyBhbmQg b3RoZXIgZm9ybXMgb2YgdmlydHVhbGl6YXRpb24uIFVzZSBjYXNlcyBpbmNsdWRlIGR5bmFtaWMg YWxsb2NhdGlvbiBhbmQgcmVsZWFzZSBvZiBJUCBhZGRyZXNzZXMgYW5kIHByZWZpeGVzIGJhc2Vk IG9uIHVzYWdlIChyZWFsbG9jYXRpb24gaW4gY2FzZSBvZiBubyBtb3JlIGluIHVzZSkgYW5kL29y IHVzZXIgaW50ZW50DQogKGZvciBzcGVjaWZpYyBzZXJ2aWNlcykuPG86cD48L286cD48L3NwYW4+ PC9saT48L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvODtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5BZ2VuZGE8 bzpwPjwvbzpwPjwvc3Bhbj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIgbGZvODtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5Qcm9ibGVtIHN0YXRlbWVudCBhbmQgdXNlIGNhc2VzPG86cD48L286cD48L3NwYW4+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMiBsZm84 O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPlJlcXVpcmVtZW50cyBhbmQgZnJhbWV3b3JrPG86cD48L286cD48 L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omwy IGxldmVsMiBsZm84O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlBvc3NpYmxlIGNoYXJ0ZXIgZ29hbHMgYW5k IG1pbGVzdG9uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzg7YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TmV4 dCBzdGVwczxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvODtiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5TdGF0dXM6IFdHIEZvcm1pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzg7YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+UmVzcG9uc2libGUgQUQ6IE9QUyAoQmVub2l0IENsYWlzZSwgSm9lbCBKYWVnZ2xp KTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xv cjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvODtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Cb0YgcHJvcG9uZW50 czogQ2hvbmdmZW5nIFhpZShDaGluYSBUZWxlY29tKSwgUmFrZXNoIEt1bWFyIChKdW5pcGVyKSwg WWluZyBDaGVuZyhDaGluYSBVbmljb20pLCBXaWxsIExpdShIdWF3ZWkpPG86cD48L286cD48L3Nw YW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxl dmVsMSBsZm84O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkJvRiBjaGFpcnM6IFRCRDxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBs ZXZlbDEgbGZvODtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5OdW1iZXIgb2YgcGVvcGxlIGV4cGVjdGVkIHRv IGF0dGVuZDogMTAwPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm84O2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkxl bmd0aCBvZiBzZXNzaW9uICgxLCAxLjUsIDIsIG9yIDIuNSBob3Vycyk6IDEuNSBob3VyczxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMiBsZXZlbDEgbGZvODtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Db25mbGljdHMgdG8gYXZvaWQg KHdob2xlIEFyZWFzIGFuZC9vciBXR3MpOiBpbnRhcmVhLCBvcHNhd2csIGFuaW1hLCBzdXBhLCBk aGMsIG5mdnJnPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm84O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk1haWxp bmcgTGlzdDog4oCLPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jYXNtIj48c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPuKA izwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2FzbTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVs MSBsZm84O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRyYWZ0IGNoYXJ0ZXI6IFRCRDxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBs ZXZlbDEgbGZvODtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5SZWxldmFudCBkcmFmdHM6PG86cD48L286cD48 L3NwYW4+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzg7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta3VtYXItY2FzbS1wcm9ibGVt LWFuZC11c2UtY2FzZXMiPjxzcGFuIGNsYXNzPSJpY29uIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0 MDA4OCI+4oCLPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0MDA4OCI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta3VtYXItY2FzbS1wcm9ibGVtLWFuZC11 c2UtY2FzZXM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIgbGZvODtiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14aWUt cHMtY2VudHJhbGl6ZWQtYWRkcmVzcy1tYW5hZ2VtZW50Ij48c3BhbiBjbGFzcz0iaWNvbiI+PHNw YW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPuKAizwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM0NDAwODgiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpZS1w cy1jZW50cmFsaXplZC1hZGRyZXNzLW1hbmFnZW1lbnQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBs ZXZlbDIgbGZvODtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1rdW1hci1jYXNtLXJlcXVpcmVtZW50cy1hbmQtZnJhbWV3b3Jr Ij48c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPuKAizwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWt1bWFyLWNhc20tcmVxdWlyZW1lbnRzLWFuZC1mcmFtZXdvcms8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIgbGZvODtiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdW4taTJhcG0tYWRk cmVzcy1wb29sLW1hbmFnZW1lbnQtYXJjaCI+PHNwYW4gY2xhc3M9Imljb24iPjxzcGFuIHN0eWxl PSJjb2xvcjojNDQwMDg4Ij7igIs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQw MDg4Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdW4taTJhcG0tYWRk cmVzcy1wb29sLW1hbmFnZW1lbnQtYXJjaDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMiBs Zm84O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXN1bi1pMmFwbS1hZGRyZXNzLXBvb2wtbWFuYWdlbWVudC15YW5nIj48c3Bh biBjbGFzcz0iaWNvbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPuKAizwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXN1bi1pMmFwbS1hZGRyZXNzLXBvb2wtbWFuYWdlbWVudC15YW5nPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2xpPjwvdWw+DQo8cCBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4tLWVu ZC0tPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv c3Ryb25nPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5XaWxsIChMSVUgU2h1Y2hlbmcpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9i PiBDQVNNIFttYWlsdG86Y2FzbS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwv Yj5MaXVzaHVjaGVuZyAoV2lsbCk8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5 IDA5LCAyMDE3IDExOjU2IEFNPGJyPg0KPGI+VG86PC9iPiBDQVNNQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtDYXNtXSBDQVNNIEJvRiByZXF1ZXN0IGp1c3QgcG9zdGVkIHRvIEJvRiB3 aWtpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPknigJltIHdyaXRpbmcgdG8gbm90aWZ5IHlvdSB0aGF0IHRoZSBD QVNNIEJvRiByZXF1ZXN0IHdhcyBqdXN0IHBvc3RlZCBpbiB0aGUgYm9mIHdpa2kuDQo8YSBocmVm PSJodHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvIj5odHRwczovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYm9mL3RyYWMvPC9hPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5NYW55IHRoYW5rcyBmb3IgdGhlIGVmZm9ydHMgZnJvbSBNYXJjLCBBZHJpYW4sIFJh a2VzaCBhbmQgQ2hvbmdmZW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgaGVscCB0 byByZXZpZXcgaXQgYW5kIGxldCB1cyBrbm93IHlvdXIgdGhvdWdodHMuIEnigJltIGNvcHlpbmcg aXQgYmVsb3cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tc3RhcnQtLTxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Q2VudHJhbGl6ZWQgQWRkcmVzcyBNYW5hZ2VtZW50IChDQVNNKTwvc3Bhbj48L3N0 cm9uZz48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzM7YmFja2dyb3VuZDp3aGl0 ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+RGVzY3JpcHRpb246IE9yZ2FuaXphdGlvbnMgdXNlIElQIEFkZHJlc3MgU3BhY2UgTWFuYWdl bWVudCAoSVBBTSkgdG9vbHMgdG8gbWFuYWdlIHRoZWlyIElQIGFkZHJlc3Mgc3BhY2UsIG9mdGVu IHdpdGggcHJvcHJpZXRhcnkgZGF0YWJhc2UgYW5kIGludGVyZmFjZXMuIFRoaXMgd29yayBpbnRl bmRzIHRvIGV2b2x2ZSBJUEFNIGludG8gc3RhbmRhcmRpemVkIGludGVyZmFjZXMNCiBmb3IgY2Vu dHJhbGl6ZWQgbWFuYWdlbWVudCBvZiBJUCBhZGRyZXNzZXMsIHNwZWNpYWxseSBpbiB0aGUgY29u dGV4dCBvZiBTRE4vTkZWIG5ldHdvcmtzLiBVc2UgY2FzZXMgaW5jbHVkZSBkeW5hbWljIGFsbG9j YXRpb24gYW5kIHJlbGVhc2Ugb2YgSVAgYWRkcmVzc2VzIGFuZCBwcmVmaXhlcyBiYXNlZCBvbiB1 c2FnZSAocmVhbGxvY2F0aW9uIGluIGNhc2Ugb2Ygbm8gbW9yZSBpbiB1c2UpIGFuZC9vciB1c2Vy IGludGVudCAoZm9yIHNwZWNpZmljDQogc2VydmljZXMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+ PC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QWdlbmRhPC9zcGFu PiA8bzpwPjwvbzpwPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMiBsZm82O2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlBy b2JsZW0gc3RhdGVtZW50IGFuZCB1c2UgY2FzZXM8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzY7YmFj a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+UmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcms8L3NwYW4+PG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2 ZWwyIGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UG9zc2libGUgY2hhcnRlciBnb2FscyBhbmQgbWls ZXN0b25lczwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDIgbGZvNjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5OZXh0IHN0 ZXBzPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm82O2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PlN0YXR1czogV0cgRm9ybWluZzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvNjtiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5SZXNwb25zaWJsZSBBRDogT1BTIChCZW5vaXQgQ2xhaXNlLCBKb2VsIEphZWdnbGkpPC9z cGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJs YWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwxIGxldmVsMSBsZm82O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkJvRiBwcm9wb25lbnRzOiBD aG9uZ2ZlbmcgWGllKENoaW5hIFRlbGVjb20pLCBSYWtlc2ggS3VtYXIgKEp1bmlwZXIpLCBZaW5n IENoZW5nKENoaW5hIFVuaWNvbSksIFdpbGwgTGl1KEh1YXdlaSk8L3NwYW4+PG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Qm9GIGNoYWlyczogVEJEPC9zcGFuPjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVs MSBsZm82O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk51bWJlciBvZiBwZW9wbGUgZXhwZWN0ZWQgdG8gYXR0 ZW5kOiAxMDA8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TGVuZ3Ro IG9mIHNlc3Npb24gKDEsIDEuNSwgMiwgb3IgMi41IGhvdXJzKTogMS41IGhvdXJzPC9zcGFuPjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwxIGxldmVsMSBsZm82O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkNvbmZsaWN0cyB0byBhdm9pZCAod2hv bGUgQXJlYXMgYW5kL29yIFdHcyk6IGludGFyZWEsIG9wc2F3ZywgYW5pbWEsIHN1cGEsIGRoYywg bmZ2cmc8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TWFpbGluZyBM aXN0OiDigIs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nh c20iPjxzcGFuIGNsYXNzPSJpY29uIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0MDA4OCI+4oCLPC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0MDA4OCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jYXNtPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+RHJhZnQgY2hhcnRlcjogVEJEPC9zcGFuPjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVs MSBsZm82O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlJlbGV2YW50IGRyYWZ0czo8L3NwYW4+IDxvOnA+PC9v OnA+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta3VtYXItY2FzbS1wcm9ibGVtLWFu ZC11c2UtY2FzZXMiPjxzcGFuIGNsYXNzPSJpY29uIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0MDA4 OCI+4oCLPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0MDA4OCI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta3VtYXItY2FzbS1wcm9ibGVtLWFuZC11c2Ut Y2FzZXM8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDIgbGZvNjtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14aWUtcHMt Y2VudHJhbGl6ZWQtYWRkcmVzcy1tYW5hZ2VtZW50Ij48c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4g c3R5bGU9ImNvbG9yOiM0NDAwODgiPuKAizwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiM0NDAwODgiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpZS1wcy1j ZW50cmFsaXplZC1hZGRyZXNzLW1hbmFnZW1lbnQ8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZl bDIgbGZvNjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1rdW1hci1jYXNtLXJlcXVpcmVtZW50cy1hbmQtZnJhbWV3b3JrIj48 c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPuKAizwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWt1bWFyLWNhc20tcmVxdWlyZW1lbnRzLWFuZC1mcmFtZXdvcms8L3Nw YW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDIgbGZvNjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdW4taTJhcG0tYWRkcmVz cy1wb29sLW1hbmFnZW1lbnQtYXJjaCI+PHNwYW4gY2xhc3M9Imljb24iPjxzcGFuIHN0eWxlPSJj b2xvcjojNDQwMDg4Ij7igIs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQwMDg4 Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdW4taTJhcG0tYWRkcmVz cy1wb29sLW1hbmFnZW1lbnQtYXJjaDwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMiBsZm82 O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXN1bi1pMmFwbS1hZGRyZXNzLXBvb2wtbWFuYWdlbWVudC15YW5nIj48c3BhbiBj bGFzcz0iaWNvbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPuKAizwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXN1bi1pMmFwbS1hZGRyZXNzLXBvb2wtbWFuYWdlbWVudC15YW5nPC9zcGFuPjwv YT48L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLWVuZC0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWdu Omp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlJl Z2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 IzFGNDk3RCI+V2lsbCAoTElVIFNodWNoZW5nKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_C9B5F12337F6F841B35C404CF0554ACB898C19DCSZXEMA509MBSchi_-- From nobody Thu Feb 9 21:24:07 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D26F1297EC; Thu, 9 Feb 2017 21:24:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148670424604.8220.4593280126601582247.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 21:24:06 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-forcerenew-extensions-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 05:24:06 -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 of the IETF. Title : Forcerenew Reconfiguration Extensions for DHCPv4 Authors : Luyuan Fang Deepak Bansal Fabio Chiussi Filename : draft-ietf-dhc-dhcpv4-forcerenew-extensions-02.txt Pages : 7 Date : 2017-02-09 Abstract: This document extends the definition of the DHCPFORCERENEW message for parameter reconfiguration in DHCPv4. This extension makes the DHCPFORCERENEW message more suitable to reconfigure configuration parameters other than IP addresses, and aligns the behavior of the reconfiguration procedure in DHCPv4 to the corresponding behavior in DHCPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-forcerenew-extensions/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-forcerenew-extensions-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-forcerenew-extensions-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 Thu Feb 9 21:30:50 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F3F129863 for ; Thu, 9 Feb 2017 21:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.501 X-Spam-Level: X-Spam-Status: No, score=-22.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=lufang@ebay.com header.d=ebay.com; dkim=pass (1024-bit key) header.d=ebay.com 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 Wz-kfVTddL8i for ; Thu, 9 Feb 2017 21:30:45 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C43129861 for ; Thu, 9 Feb 2017 21:30:45 -0800 (PST) DomainKey-Signature: s=ebaycorp; d=ebay.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:Received: Received:Received:From:To:CC:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:authentication-results: x-ms-exchange-messagesentrepresentingtype: x-originating-ip:x-ms-office365-filtering-correlation-id: x-ms-office365-filtering-ht:x-microsoft-antispam: x-microsoft-exchange-diagnostics: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf: spamdiagnosticoutput:spamdiagnosticmetadata:Content-Type: MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id: X-MS-Exchange-Transport-CrossTenantHeadersStamped: Return-Path:X-OriginatorOrg:X-CFilter-Loop; b=aznnRydydEWuy6Fjl759Lo0uP9et03hGBtl9G3wh+joRwVjQQ1MCfMj2 V6smMgG8IyYa7GsX5BYh3HsL0e5++Vvtn6Boa4DuYUnqMnbH1fDjb4pTH VkEGq/JxesID8D5jRd8zkfHRplvhIcrYCy1YWN8kEaWnIb3l111ayRDPg E=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ebay.com; i=@ebay.com; q=dns/txt; s=ebaycorp; t=1486704645; x=1518240645; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yWrMqoqtmygnqo1/OmZHu0vwGEQkCjK7OaHb8WMQjBM=; b=aM/VnItgprUcuBtYj50jwpiOqKQ2UTRPOuKAAjqlqR6KnHfk4lrPhY77 mvnkiX7WFjxOnqor6fXPVBUcgGtIR7aqaOarCw5emU9QBQpC14O6HoZxD Dz4sFtq6ujnor/qAfC44P+C/MN8grp/nWENlkQiDzQKOLWcHFZ8nCiqG2 E=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="5.35,139,1484031600"; d="scan'208,217";a="219630612" Received: from den-vteml-004.corp.ebay.com (HELO DEN-EXMHT-004.corp.ebay.com) ([10.101.112.120]) by den-mipot-002.corp.ebay.com with ESMTP; 09 Feb 2017 22:29:41 -0700 Received: from DEN-365HT-003.corp.ebay.com (10.101.47.5) by DEN-EXMHT-004.corp.ebay.com (10.241.17.151) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 9 Feb 2017 22:29:41 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (216.32.180.52) by o365.corp.ebay.com (10.101.47.5) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 9 Feb 2017 22:29:40 -0700 Received: from CY1PR07MB2410.namprd07.prod.outlook.com (10.166.195.11) by CY1PR07MB2409.namprd07.prod.outlook.com (10.166.195.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10 Feb 2017 05:29:39 +0000 Received: from CY1PR07MB2410.namprd07.prod.outlook.com ([10.166.195.11]) by CY1PR07MB2410.namprd07.prod.outlook.com ([10.166.195.11]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 05:29:39 +0000 From: "Fang, Luyuan" To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: WG meeting follow-up - Forcerenew Reconfiguration Extensions for DHCPv4 Thread-Index: AdJFrgUx4It+bot+S7WY8x3eyFGyNQGacxOAASTqXrAMnAjUgA== Date: Fri, 10 Feb 2017 05:29:39 +0000 Message-ID: <5EDAFB65-056F-44B1-9F61-490422391068@ebay.com> References: <3f436153e5004bd285f29ffb79c6865e@XCH-ALN-003.cisco.com> <66b668a7292c4a638be82b5029d3c070@XCH-ALN-003.cisco.com> In-Reply-To: <66b668a7292c4a638be82b5029d3c070@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=lufang@ebay.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [73.97.226.46] x-ms-office365-filtering-correlation-id: a7d65fac-f1d3-4290-ce2e-08d45175cf35 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR07MB2409; x-microsoft-exchange-diagnostics: 1; CY1PR07MB2409; 7:Paz1eeBXo7z1LFwBgWhEOX1pelDMqMPsFNclgQClXNrrE0LYLcIJggwZee9HUFbI91EV70Ru0rwEoADklRdciujBng+QyGWTJicZG44zM0eSV3wtxS9ugpGPb0bhVG3yg9mj2Y6O5q3JkUgi2bbVQ664CWu+08U0QVvwJIjjUxxd2DIUD7Q7GyFqnb7EDbdsSfjIXgxNGBGB7N4vDYw4gaQfSKVe0HBKBY8MqXegP2FKHDPCuBg/P91CXDoUf7gtbbsVzfe9/w6kpOQYbNRtPLHhVlC2DDDjuFG87Opzs1C49gQ/Pmhmp3hT9l0XRmCByZkoFUXcqKpRhS7G6EcHQiuXfXmJfT0oGmtWMPgZyoJF+mUiHORvrjd/gAmj8NgyBkX8iXT0lcxIXdL+/gB7OTrMPG+v4G6fSwHlrOMu3eglufP2ZY5oR0FayyuggZbvMOYtv1b6Cd5Mo72uUeXW1hDBiS1fNIeXh9PO6eNO6kBEtPKh5mRUD8PHz8itPlOhJX0BBkfDCj0wtCi1kxENSA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(55715876382637)(158342451672863)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY1PR07MB2409; BCL:0; PCL:0; RULEID:; SRVR:CY1PR07MB2409; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39860400002)(39450400003)(39840400002)(39850400002)(189002)(377454003)(199003)(50986999)(6246003)(10290500002)(54356999)(76176999)(101416001)(5660300001)(122556002)(33656002)(2950100002)(68736007)(81156014)(81166006)(66066001)(8676002)(8936002)(38730400002)(2501003)(345774005)(53936002)(9326002)(105586002)(106356001)(7906003)(92566002)(7736002)(2900100001)(83716003)(36756003)(4326007)(3660700001)(3280700002)(97736004)(2906002)(189998001)(25786008)(3846002)(606005)(6116002)(39060400001)(8666007)(236005)(102836003)(82746002)(6436002)(54896002)(99286003)(6506006)(86362001)(6306002)(229853002)(54906002)(6512007)(77096006)(6486002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR07MB2409; H:CY1PR07MB2410.namprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ebay.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5EDAFB65056F44B19F61490422391068ebaycom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 05:29:39.4665 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46326bff-9928-41a0-baca-17c16c94ea99 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2409 X-OriginatorOrg: ebay.com X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-dhc-dhcpv4-forcerenew-extensions@ietf.org" , "Deepak Bansal \(AZURE\)" , Fabio Chiussi Subject: Re: [dhcwg] WG meeting follow-up - Forcerenew Reconfiguration Extensions for DHCPv4 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 05:30:48 -0000 --_000_5EDAFB65056F44B19F61490422391068ebaycom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVybmllLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCBkaXNjdXNzaW9uLiBT b3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuDQpNU0ZUIEF6dXJlIGlzIHdvcmtpbmcgdG8gaGF2ZSBh biBpbXBsZW1lbnRhdGlvbiBpbiBDWTE3LCB3ZeKAmWxsIHdhaXQgYSBiaXQgYmVmb3JlIFdHTEMu DQoNClJlZ2FyZGluZyB5b3VyIGNvbW1lbnRzIGZvciBTZWN0aW9uIDIuMywgZ29vZCBwb2ludHMs IHdlIHJlbW92ZWQgYm90aCBzZW50ZW5jZXMgaW4gdGhlIHVwZGF0ZWQgdmVyc2lvbi4NCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1kaGNwdjQtZm9yY2VyZW5ldy1l eHRlbnNpb25zLTAyDQoNClRoYW5rcywNCkx1eXVhbg0KDQpGcm9tOiAiQmVybmllIFZvbHogKHZv bHopIiA8dm9sekBjaXNjby5jb20+DQpEYXRlOiBXZWRuZXNkYXksIERlY2VtYmVyIDcsIDIwMTYg YXQgOTowOSBBTQ0KVG86ICJGYW5nLCBMdXl1YW4iIDxsdWZhbmdAZWJheS5jb20+LCAiZGhjd2dA aWV0Zi5vcmciIDxkaGN3Z0BpZXRmLm9yZz4NCkNjOiAiZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LWZv cmNlcmVuZXctZXh0ZW5zaW9uc0BpZXRmLm9yZyIgPGRyYWZ0LWlldGYtZGhjLWRoY3B2NC1mb3Jj ZXJlbmV3LWV4dGVuc2lvbnNAaWV0Zi5vcmc+LCAiRGVlcGFrIEJhbnNhbCAoQVpVUkUpIiA8ZGJh bnNhbEBtaWNyb3NvZnQuY29tPiwgRmFiaW8gQ2hpdXNzaSA8ZmFiaW9jaGl1c3NpQGdtYWlsLmNv bT4NClN1YmplY3Q6IFJFOiBXRyBtZWV0aW5nIGZvbGxvdy11cCAtIEZvcmNlcmVuZXcgUmVjb25m aWd1cmF0aW9uIEV4dGVuc2lvbnMgZm9yIERIQ1B2NA0KDQpUaGFua3MgTHV5dWFuLg0KDQpTbywg YXQgdGhpcyBwb2ludCB0aGUgbmV4dCBzdGVwIGlzIHJlYWxseSB0byB1cCB0byB5b3Ug4oCmIHNl ZW1zIHRvIGJlOg0KDQoNCjEuICAgICAgIFdhaXQgdW50aWwgTVNGVCBoYXMgaW1wbGVtZW50ZWQg YW5kIHNlZSBpZiB0aGF0IGdlbmVyYXRlcyBhbnkgYWRkaXRpb25hbCBjaGFuZ2VzIHRvIHRoZSBk b2N1bWVudA0KDQoyLiAgICAgICBJbml0aWF0ZSBXR0xDIChlaXRoZXIgbm93IG9yIGFmdGVyIDEg 4oCTIHBlcmhhcHMgd2FpdGluZyBpcyBiZXN0KQ0KDQpJIGRvIHNlZSB0aGF0IFNlY3Rpb24gMi4z IGRpc2N1c3NlcyBzb21lIHBvdGVudGlhbCB3b3JrIChhcyB0aGlzIGFsdGVybmF0aXZlIG1lY2hh bmlzbSBpcyBub3QgZGVmaW5lZCk6DQoNCiAgIEFsdGVybmF0aXZlbHksIGEgbWVjaGFuaXNtIGZv ciB0aGUgY2xpZW50IHRvIGV4cGxpY2l0IGluZm9ybSB0aGUNCiAgIHNlcnZlciB0aGF0IGl0IGlz IGRlY2xpbmluZyB0aGUgc2VydmVyLWluaXRpYXRlZCBESENQSU5GT0ZPUkNFUkVORVcNCiAgIHJl Y29uZmlndXJhdGlvbiBwcm9jZWR1cmUgbmVlZHMgdG8gYmUgZGV2aXNlZC4NCg0KSXQgc2VlbXMg dG8gbWUgdGhhdCB0aGlzIG1pZ2h0IGJlIHdvcnRoIGVpdGhlciByZW1vdmluZz8gVGhhdCAyLjMg c2VjdGlvbiBhbHNvIGhhcyBhbiBvZGQgc2VudGVuY2UgKFRoaXMgZnVydGhlciBhbGlnbnMgdGhl IGNsaWVudCBiZWhhdmlvciBpbiBESENQdjQgc2VydmVyLWluaXRpYXRlZCByZWNvbmZpZ3VyYXRp b24gd2l0aCB0aGUgY29ycmVzcG9uZGluZyBiZWhhdmlvciBpbiBESENQdjYuKSBhcyBJIGRvbuKA mXQgcmVjYWxsIGFueSBzdWNoIGNhcGFiaWxpdHkgaW4gREhDUHY2PyBJbiBESENQdjYgYSBjbGll bnQgY2FuIGluZGljYXRlIHdoZXRoZXIgaXQgc3VwcG9ydHMgUmVjb25maWd1cmUsIGJ1dCBub3Qg d2hpY2ggb2YgdGhlIFJlY29uZmlndXJlIG1lc3NhZ2VzIChSZW5ldywgUmViaW5kLCBvciBJbmZv cm1hdGlvbi1SZXF1ZXN0KS4NCg0KQW5kLCBhbiBpc3N1ZSB3aXRoICMxIGlzIHRoYXQgeW914oCZ ZCBoYXZlIHRvIHBpY2sgYSBtZXNzYWdlIG51bWJlciB0byB1c2UgYXMgSUFOQSB3b27igJl0IGhh dmUgYXNzaWduZWQgYSBuZXcgb25lIGZvciB0aGUgREhDUEZPUkNFSU5GT1JFTkVXIG1lc3NhZ2Ug KGFuZCB0aGF0IGNvdWxkIHBvc3NpYmxlIGNvbmZsaWN0IGlmIHRoZXJlIHdhcyBzb21ldGhpbmcg ZWxzZSBhc3NpZ25lZCBpbiB0aGUgaW50ZXJpbSwgdGhvdWdoIEkgYW0gbm90IGF3YXJlIG9mIGFu eXRoaW5nLikNCg0KDQotICAgICAgICAgIEJlcm5pZQ0KDQpGcm9tOiBGYW5nLCBMdXl1YW4gW21h aWx0bzpsdWZhbmdAZWJheS5jb21dDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDAyLCAyMDE2IDEy OjE0IEFNDQpUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT47IGRoY3dnQGll dGYub3JnDQpDYzogZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LWZvcmNlcmVuZXctZXh0ZW5zaW9uc0Bp ZXRmLm9yZzsgRGVlcGFrIEJhbnNhbCAoQVpVUkUpIDxkYmFuc2FsQG1pY3Jvc29mdC5jb20+OyBG YWJpbyBDaGl1c3NpIDxmYWJpb2NoaXVzc2lAZ21haWwuY29tPg0KU3ViamVjdDogUmU6IFdHIG1l ZXRpbmcgZm9sbG93LXVwIC0gRm9yY2VyZW5ldyBSZWNvbmZpZ3VyYXRpb24gRXh0ZW5zaW9ucyBm b3IgREhDUHY0DQoNCkhpIFRvbWVrIGFuZCBCZXJuaWUsDQoNClRoYW5rcyBmb3IgcHJlc2VudGlu ZyB0aGUgZHJhZnQgaW4gdGhlIGxhc3QgSUVURiBhbmQgYnJpbmcgdGhpcyB0byBkaGMgd2cgZGlz Y3Vzc2lvbi4gU29ycnkgZm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlLg0KDQpZZXMsIHdlIHN0aWxs IGhhdmUgc3Ryb25nIGludGVyZXN0cyB0byBjb21wbGV0ZSB0aGlzIHdvcmsuIE1TRlQgaXMgd29y a2luZyB0byBpbXBsZW1lbnQgaXQgaW4gQXp1cmUuIFdlIHdpbGwgcmVwb3J0IHRoZSByZXN1bHRz IHdoZW4gcmVhZHkuDQpBdCB0aGUgbWVhbnRpbWUsIHdl4oCZbGwgcG9zdCBhIG5ldyB2ZXJzaW9u IHdpdGhvdXQgY29udGVudCBjaGFuZ2UuDQoNClRoYW5rcywNCkx1eXVhbg0KDQpGcm9tOiAiQmVy bmllIFZvbHogKHZvbHopIiA8dm9sekBjaXNjby5jb208bWFpbHRvOnZvbHpAY2lzY28uY29tPj4N CkRhdGU6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjMsIDIwMTYgYXQgMTA6NTAgQU0NClRvOiAiZGhj d2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPiIgPGRoY3dnQGlldGYub3JnPG1haWx0 bzpkaGN3Z0BpZXRmLm9yZz4+DQpDYzogImRyYWZ0LWlldGYtZGhjLWRoY3B2NC1mb3JjZXJlbmV3 LWV4dGVuc2lvbnNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtZGhjLWRoY3B2NC1mb3JjZXJl bmV3LWV4dGVuc2lvbnNAaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LWZvcmNlcmVu ZXctZXh0ZW5zaW9uc0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LWZvcmNl cmVuZXctZXh0ZW5zaW9uc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBXRyBtZWV0aW5nIGZvbGxvdy11 cCAtIEZvcmNlcmVuZXcgUmVjb25maWd1cmF0aW9uIEV4dGVuc2lvbnMgZm9yIERIQ1B2NA0KDQpI aToNCg0KQXQgdGhlIElFVEYtOTcgKFNlb3VsKSBESEMgV0cgbWVldGluZywgVG9tZWsgaGFkIGEg YnJpZWYgcHJlc2VudGF0aW9uIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjQtZm9yY2Vy ZW5ldy1leHRlbnNpb25zIChzZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcv c2xpZGVzL3NsaWRlcy05Ny1kaGMtbmV4dC1zdGVwcy1mb3ItZHJhZnQtaWV0Zi1kaGMtZGhjcHY0 LWZvcmNlcmVuZXctZXh0ZW5zaW9ucy0wMC5wZGYpLg0KDQpUaGlzIGRvY3VtZW50IGhhcyBiZWVu IGluYWN0aXZlIHNpbmNlIFdHIGFkb3B0aW9uIGFuZCBoYXMgbm93IGV4cGlyZWQuIFRoZSBjby1j aGFpcnMgbWFkZSBzZXZlcmFsIGF0dGVtcHRzIHRvIGNvbnRhY3QgdGhlIGF1dGhvcnMsIGJ1dCB0 aGV5IHdlcmUgdW5yZXNwb25zaXZlLiBUb21layBhc2tlZCB0aG9zZSBpbiB0aGUgcm9vbSBpZiB0 aGVyZSB3YXMgYW55IGludGVyZXN0IGZyb20gc29tZW9uZSB0byB0YWtlIG9uIHRoaXMgd29yay4g VGhlcmUgd2FzIG5vIGludGVyZXN0IGV4cHJlc3NlZCwgYnV0IHdlIHdhbnQgdG8gdGFrZSBpdCB0 byB0aGUgV0cgbWFpbGluZyBsaXN0IHRvIHNlZSBpZiBhbnlvbmUgaGFzIGFueSBpbnRlcmVzdC4N Cg0KSWYgeW91IGRvIGhhdmUgaW50ZXJlc3QgaW4gd29ya2luZyBvbiB0aGlzLCBwbGVhc2UgY29u dGFjdCB0aGUgREhDIFdHIGNoYWlycyAoZGhjLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86ZGhjLWNo YWlyc0BpZXRmLm9yZz4pLg0KDQpZb3UgY2FuIHZpZXcgdGhlIGN1cnJlbnQgKGV4cGlyZWQpIGRy YWZ0IGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1kaGNwdjQt Zm9yY2VyZW5ldy1leHRlbnNpb25zLTAwLg0KDQpJZiB0aGVyZSBpcyBubyBpbnRlcmVzdCwgdGhl IGRvY3VtZW50IHdpbGwganVzdCBiZSBsZWZ0IGFzIGl0IGlzIHRvZGF5IChleHBpcmVkKS4gV29y ayBvbiBpdCBjYW4gYWx3YXlzIGJlIHJldml2ZWQgc29tZXRpbWUgaW4gdGhlIGZ1dHVyZSBpZiBh IG5lZWQgZGV2ZWxvcHMuDQoNClRoYW5rcy4NCg0KDQotICAgICAgICAgIFRvbWVrICYgQmVybmll DQo= --_000_5EDAFB65056F44B19F61490422391068ebaycom_ Content-Type: text/html; charset="utf-8" Content-ID: <1C5482299831674495AB326C71B500F1@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5hdXRob3ItYS1sejY5enoxMjJ6b296NjZ6eXo4NHp6ODN6ZWt5ejg3 ejB6Nzd6ejcxeg0KCXttc28tc3R5bGUtbmFtZTphdXRob3ItYS1sejY5enoxMjJ6b296NjZ6eXo4 NHp6ODN6ZWt5ejg3ejB6Nzd6ejcxejt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNv bG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6MTAzOTYyNDgyMjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6MzY0OTU4NTAyIDIwMTg2NjE0MDQgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjIwMTA5MDkxMDY7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04NDIzNzE1MjIgNDI0ODU4 MjM4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoy MDc4ODk1ODUxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMjE5NjQ4Mzc2IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwyOmxldmVsMQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBCZXJuaWUsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rIHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIGRpc2N1c3Npb24uIFNvcnJ5IGZvciB0aGUgbGF0 ZSByZXBseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1TRlQgQXp1cmUg aXMgd29ya2luZyB0byBoYXZlIGFuIGltcGxlbWVudGF0aW9uIGluIENZMTcsIHdl4oCZbGwgd2Fp dCBhIGJpdCBiZWZvcmUgV0dMQy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHlv dXIgY29tbWVudHMgZm9yIFNlY3Rpb24gMi4zLCBnb29kIHBvaW50cywgd2UgcmVtb3ZlZCBib3Ro IHNlbnRlbmNlcyBpbiB0aGUgdXBkYXRlZCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtZGhjLWRoY3B2NC1mb3JjZXJlbmV3LWV4dGVuc2lvbnMtMDIiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1kaGNwdjQtZm9yY2VyZW5ldy1leHRlbnNpb25z LTAyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5MdXl1YW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+JnF1b3Q7QmVybmllIFZvbHogKHZv bHopJnF1b3Q7ICZsdDt2b2x6QGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVz ZGF5LCBEZWNlbWJlciA3LCAyMDE2IGF0IDk6MDkgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O0Zh bmcsIEx1eXVhbiZxdW90OyAmbHQ7bHVmYW5nQGViYXkuY29tJmd0OywgJnF1b3Q7ZGhjd2dAaWV0 Zi5vcmcmcXVvdDsgJmx0O2RoY3dnQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7 ZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LWZvcmNlcmVuZXctZXh0ZW5zaW9uc0BpZXRmLm9yZyZxdW90 OyAmbHQ7ZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LWZvcmNlcmVuZXctZXh0ZW5zaW9uc0BpZXRmLm9y ZyZndDssICZxdW90O0RlZXBhayBCYW5zYWwgKEFaVVJFKSZxdW90OyAmbHQ7ZGJhbnNhbEBtaWNy b3NvZnQuY29tJmd0OywgRmFiaW8gQ2hpdXNzaSAmbHQ7ZmFiaW9jaGl1c3NpQGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFdHIG1lZXRpbmcgZm9sbG93LXVwIC0gRm9yY2Vy ZW5ldyBSZWNvbmZpZ3VyYXRpb24gRXh0ZW5zaW9ucyBmb3IgREhDUHY0PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5UaGFua3MgTHV5dWFuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+U28sIGF0IHRoaXMgcG9pbnQgdGhlIG5leHQgc3RlcCBpcyByZWFsbHkgdG8gdXAgdG8geW91 IOKApiBzZWVtcyB0byBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XYWl0 IHVudGlsIE1TRlQgaGFzIGltcGxlbWVudGVkIGFuZCBzZWUgaWYgdGhhdCBnZW5lcmF0ZXMgYW55 IGFkZGl0aW9uYWwgY2hhbmdlcyB0byB0aGUgZG9jdW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluaXRpYXRl IFdHTEMgKGVpdGhlciBub3cgb3IgYWZ0ZXIgMSDigJMgcGVyaGFwcyB3YWl0aW5nIGlzIGJlc3Qp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGRvIHNlZSB0aGF0IFNlY3Rp b24gMi4zIGRpc2N1c3NlcyBzb21lIHBvdGVudGlhbCB3b3JrIChhcyB0aGlzIGFsdGVybmF0aXZl IG1lY2hhbmlzbSBpcyBub3QgZGVmaW5lZCk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgQWx0ZXJuYXRpdmVseSwgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQg dG8gZXhwbGljaXQgaW5mb3JtIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2VydmVyIHRoYXQg aXQgaXMgZGVjbGluaW5nIHRoZSBzZXJ2ZXItaW5pdGlhdGVkIERIQ1BJTkZPRk9SQ0VSRU5FVzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVjb25maWd1cmF0aW9uIHByb2NlZHVyZSBuZWVkcyB0byBi ZSBkZXZpc2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SXQgc2VlbXMg dG8gbWUgdGhhdCB0aGlzIG1pZ2h0IGJlIHdvcnRoIGVpdGhlciByZW1vdmluZz8gVGhhdCAyLjMg c2VjdGlvbiBhbHNvIGhhcyBhbiBvZGQgc2VudGVuY2UgKFRoaXMgZnVydGhlciBhbGlnbnMgdGhl IGNsaWVudCBiZWhhdmlvciBpbiBESENQdjQgc2VydmVyLWluaXRpYXRlZCByZWNvbmZpZ3VyYXRp b24gd2l0aCB0aGUgY29ycmVzcG9uZGluZyBiZWhhdmlvcg0KIGluIERIQ1B2Ni4pIGFzIEkgZG9u 4oCZdCByZWNhbGwgYW55IHN1Y2ggY2FwYWJpbGl0eSBpbiBESENQdjY/IEluIERIQ1B2NiBhIGNs aWVudCBjYW4gaW5kaWNhdGUgd2hldGhlciBpdCBzdXBwb3J0cyBSZWNvbmZpZ3VyZSwgYnV0IG5v dCB3aGljaCBvZiB0aGUgUmVjb25maWd1cmUgbWVzc2FnZXMgKFJlbmV3LCBSZWJpbmQsIG9yIElu Zm9ybWF0aW9uLVJlcXVlc3QpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ QW5kLCBhbiBpc3N1ZSB3aXRoICMxIGlzIHRoYXQgeW914oCZZCBoYXZlIHRvIHBpY2sgYSBtZXNz YWdlIG51bWJlciB0byB1c2UgYXMgSUFOQSB3b27igJl0IGhhdmUgYXNzaWduZWQgYSBuZXcgb25l IGZvciB0aGUgREhDUEZPUkNFSU5GT1JFTkVXIG1lc3NhZ2UgKGFuZCB0aGF0IGNvdWxkIHBvc3Np YmxlIGNvbmZsaWN0IGlmIHRoZXJlIHdhcyBzb21ldGhpbmcgZWxzZQ0KIGFzc2lnbmVkIGluIHRo ZSBpbnRlcmltLCB0aG91Z2ggSSBhbSBub3QgYXdhcmUgb2YgYW55dGhpbmcuKTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QmVybmllPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRmFuZywgTHV5 dWFuIFttYWlsdG86bHVmYW5nQGViYXkuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBE ZWNlbWJlciAwMiwgMjAxNiAxMjoxNCBBTTxicj4NCjxiPlRvOjwvYj4gQmVybmllIFZvbHogKHZv bHopICZsdDt2b2x6QGNpc2NvLmNvbSZndDs7IGRoY3dnQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9i PiBkcmFmdC1pZXRmLWRoYy1kaGNwdjQtZm9yY2VyZW5ldy1leHRlbnNpb25zQGlldGYub3JnOyBE ZWVwYWsgQmFuc2FsIChBWlVSRSkgJmx0O2RiYW5zYWxAbWljcm9zb2Z0LmNvbSZndDs7IEZhYmlv IENoaXVzc2kgJmx0O2ZhYmlvY2hpdXNzaUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBXRyBtZWV0aW5nIGZvbGxvdy11cCAtIEZvcmNlcmVuZXcgUmVjb25maWd1cmF0aW9u IEV4dGVuc2lvbnMgZm9yIERIQ1B2NDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgVG9tZWsgYW5kIEJlcm5pZSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz IGZvciBwcmVzZW50aW5nIHRoZSBkcmFmdCBpbiB0aGUgbGFzdCBJRVRGIGFuZCBicmluZyB0aGlz IHRvIGRoYyB3ZyBkaXNjdXNzaW9uLiBTb3JyeSBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9uc2UuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgd2Ugc3RpbGwgaGF2ZSBzdHJvbmcgaW50ZXJlc3Rz IHRvIGNvbXBsZXRlIHRoaXMgd29yay4gTVNGVCBpcyB3b3JraW5nIHRvIGltcGxlbWVudCBpdCBp biBBenVyZS4gV2Ugd2lsbCByZXBvcnQgdGhlIHJlc3VsdHMgd2hlbiByZWFkeS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHRoZSBtZWFudGltZSwgd2XigJlsbCBwb3N0 IGEgbmV3IHZlcnNpb24gd2l0aG91dCBjb250ZW50IGNoYW5nZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+THV5dWFu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZxdW90O0Jlcm5pZSBWb2x6ICh2b2x6KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnZvbHpAY2lzY28uY29tIj52b2x6QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPldlZG5lc2RheSwgTm92ZW1iZXIgMjMsIDIwMTYgYXQgMTA6NTAgQU08YnI+DQo8Yj5Ubzog PC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyI+ZGhjd2dAaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1p ZXRmLWRoYy1kaGNwdjQtZm9yY2VyZW5ldy1leHRlbnNpb25zQGlldGYub3JnIj5kcmFmdC1pZXRm LWRoYy1kaGNwdjQtZm9yY2VyZW5ldy1leHRlbnNpb25zQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtZGhjLWRoY3B2NC1mb3JjZXJlbmV3LWV4dGVuc2lv bnNAaWV0Zi5vcmciPmRyYWZ0LWlldGYtZGhjLWRoY3B2NC1mb3JjZXJlbmV3LWV4dGVuc2lvbnNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5XRyBtZWV0aW5nIGZvbGxvdy11 cCAtIEZvcmNlcmVuZXcgUmVjb25maWd1cmF0aW9uIEV4dGVuc2lvbnMgZm9yIERIQ1B2NDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGk6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHRoZSBJRVRGLTk3IChTZW91bCkgREhDIFdHIG1l ZXRpbmcsIDxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejY5enoxMjJ6b296NjZ6eXo4NHp6ODN6ZWt5 ejg3ejB6Nzd6ejcxeiI+DQpUb21layBoYWQgYSBicmllZiBwcmVzZW50YXRpb24gcmVnYXJkaW5n IGRyYWZ0LWlldGYtZGhjLWRoY3B2NC1mb3JjZXJlbmV3LWV4dGVuc2lvbnMgKHNlZQ0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny1k aGMtbmV4dC1zdGVwcy1mb3ItZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LWZvcmNlcmVuZXctZXh0ZW5z aW9ucy0wMC5wZGYiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVz L3NsaWRlcy05Ny1kaGMtbmV4dC1zdGVwcy1mb3ItZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LWZvcmNl cmVuZXctZXh0ZW5zaW9ucy0wMC5wZGY8L2E+KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo2OXp6MTIyem9vejY2enl6 ODR6ejgzemVreXo4N3owejc3eno3MXoiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejY5enoxMjJ6b296NjZ6 eXo4NHp6ODN6ZWt5ejg3ejB6Nzd6ejcxeiI+VGhpcyBkb2N1bWVudCBoYXMgYmVlbiBpbmFjdGl2 ZSBzaW5jZSBXRyBhZG9wdGlvbiBhbmQgaGFzIG5vdyBleHBpcmVkLiBUaGUgY28tY2hhaXJzIG1h ZGUgc2V2ZXJhbCBhdHRlbXB0cyB0byBjb250YWN0IHRoZSBhdXRob3JzLCBidXQgdGhleSB3ZXJl IHVucmVzcG9uc2l2ZS4gVG9tZWsgYXNrZWQNCiB0aG9zZSBpbiB0aGUgcm9vbSBpZiB0aGVyZSB3 YXMgYW55IGludGVyZXN0IGZyb20gc29tZW9uZSB0byB0YWtlIG9uIHRoaXMgd29yay4gVGhlcmUg d2FzIG5vIGludGVyZXN0IGV4cHJlc3NlZCwgYnV0IHdlIHdhbnQgdG8gdGFrZSBpdCB0byB0aGUg V0cgbWFpbGluZyBsaXN0IHRvIHNlZSBpZiBhbnlvbmUgaGFzIGFueSBpbnRlcmVzdC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9y LWEtbHo2OXp6MTIyem9vejY2enl6ODR6ejgzemVreXo4N3owejc3eno3MXoiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRo b3ItYS1sejY5enoxMjJ6b296NjZ6eXo4NHp6ODN6ZWt5ejg3ejB6Nzd6ejcxeiI+SWYgeW91IGRv IGhhdmUgaW50ZXJlc3QgaW4gd29ya2luZyBvbiB0aGlzLCBwbGVhc2UgY29udGFjdCB0aGUgREhD IFdHIGNoYWlycyAoPGEgaHJlZj0ibWFpbHRvOmRoYy1jaGFpcnNAaWV0Zi5vcmciPmRoYy1jaGFp cnNAaWV0Zi5vcmc8L2E+KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo2OXp6MTIyem9vejY2enl6ODR6ejgzemVreXo4 N3owejc3eno3MXoiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1sejY5enoxMjJ6b296NjZ6eXo4NHp6ODN6ZWt5 ejg3ejB6Nzd6ejcxeiI+WW91IGNhbiB2aWV3IHRoZSBjdXJyZW50IChleHBpcmVkKSBkcmFmdCBh dA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLWRo Y3B2NC1mb3JjZXJlbmV3LWV4dGVuc2lvbnMtMDAiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtZGhjLWRoY3B2NC1mb3JjZXJlbmV3LWV4dGVuc2lvbnMtMDA8L2E+Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJh dXRob3ItYS1sejY5enoxMjJ6b296NjZ6eXo4NHp6ODN6ZWt5ejg3ejB6Nzd6ejcxeiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 ImF1dGhvci1hLWx6Njl6ejEyMnpvb3o2Nnp5ejg0eno4M3pla3l6ODd6MHo3N3p6NzF6Ij5JZiB0 aGVyZSBpcyBubyBpbnRlcmVzdCwgdGhlIGRvY3VtZW50IHdpbGwganVzdCBiZSBsZWZ0IGFzIGl0 IGlzIHRvZGF5IChleHBpcmVkKS4gV29yayBvbiBpdCBjYW4gYWx3YXlzIGJlIHJldml2ZWQgc29t ZXRpbWUgaW4gdGhlIGZ1dHVyZSBpZiBhIG5lZWQgZGV2ZWxvcHMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLWx6Njl6ejEy Mnpvb3o2Nnp5ejg0eno4M3pla3l6ODd6MHo3N3p6NzF6Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo2OXp6 MTIyem9vejY2enl6ODR6ejgzemVreXo4N3owejc3eno3MXoiPlRoYW5rcy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtbHo2 OXp6MTIyem9vejY2enl6ODR6ejgzemVreXo4N3owejc3eno3MXoiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm82Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRvbWVrICZh bXA7IEJlcm5pZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5EDAFB65056F44B19F61490422391068ebaycom_-- From nobody Fri Feb 10 02:13:40 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62D11294B9 for ; Fri, 10 Feb 2017 02:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 xM0paivCc-4M for ; Fri, 10 Feb 2017 02:13:37 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FDF129487 for ; Fri, 10 Feb 2017 02:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K/omN3aZeLLrlv3d4hC3ydEtE2XMTqwPR+mrmO01Px8=; b=YViMpCifgwjRiCngtzc+cRb+IOsk6rhtHr6weXszl+l2Kpng0fFmD5Upv7NZCby1ftbMpdsu1HfZzAIw/T4HI7mDv8AKgXWeuorwBuJu7yr4bkTEYS5tar5JF6o2qiiHQM4Zr+9ytbpuc1rODm6OXF9CLiIXK9jesD6GXFNSu9I= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0245.outbound.protection.outlook.com [213.199.154.245]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-103-7ZLvdDvaNzqUefDdL33uew-1; Fri, 10 Feb 2017 10:13:31 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Fri, 10 Feb 2017 10:13:30 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::69c4:89e7:78ae:238f]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::69c4:89e7:78ae:238f%14]) with mapi id 15.01.0888.026; Fri, 10 Feb 2017 10:13:30 +0000 From: Tim Chown To: Simon Hobson Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9w///mfQCAAAvXgIAAALaAgAABlgCAAACTgIAABPwAgAAFJwCAAAESAIAAAJWAgAAB34CAAACaAIAAAlcAgAAJ8gCAARo+gA== Date: Fri, 10 Feb 2017 10:13:29 +0000 Message-ID: <80850211-62FA-4E42-BF57-FC32F29B19DC@jisc.ac.uk> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8 F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> In-Reply-To: <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:d517:d0:57c1:3897] x-ms-office365-filtering-correlation-id: 8d1871ee-7777-4221-9f92-08d4519d7632 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1139; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:Ujusza8xyA98Zv8lS92UuRoJjmF1z3rIbs5CUcjSXUj0l2Ws0TINEi2lRme4z4JLu7IYZQK5ciICeiXBQokYb5YVQzxjEBoSRcsFRn9u/OEZ4gI3nVqIIgIHUB8vnEc8EtLMRP+c6+/Qpj6lZAtHKjYYo2hn7qEt0mB0WofxgRrZRO3yYdZ3wNVS3lIG7PQP1vc0uH05vkt8TG4T4StMHsMcI17kMcNaNTrmvIliKYOrCoSpQ2ZV1ExFcKYmlU9wYDBUTMQ4/WcPQVEV1jdYKnGNm38IHgrUi124d59EfaRxRQlHRgo7NPvyW+52JzW2iVt99pW2/IYxl3IlyVkEYFPScBqBSfZ8Rdk9S/nJHrBGMsKmI3jNo41Mf8Mb/kPPceBsUq+9FvXU9OKc/KXhyHPX9baDCECKx60U3X37WO4nCTVBhtoY6eBq7sJsM5NDdXxJGMIg3HgAGvFQLKXj0I210V0SQLvLyKDJ3pywzcLFrBEU2Oa+lRZz7TsbbmjHshs9y2GMmQ6q3iARh8HJsQ==; 20:/aizYOAK12RWYdNxe2SYDchZt2jTXs9Sj6j3x1QLF5d3dWILe1Ak8tlCtyMD/9EaKmq6UToWoOD6i3ImdQcKq0oQuAytPaMk3SI192vtW2GQcswNqb6vGfWRJchW0Cllh1kgFgb6w6UpJP0FikbS3eFj3R54kZbo7B7DChOaU8Q= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(20161123564025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(199003)(189002)(8936002)(2900100001)(99286003)(76176999)(50986999)(92566002)(86362001)(36756003)(106356001)(8676002)(101416001)(3280700002)(6506006)(81166006)(81156014)(5660300001)(68736007)(7736002)(189998001)(6436002)(105586002)(53936002)(6486002)(5250100002)(3660700001)(102836003)(6116002)(6512007)(42882006)(2950100002)(57306001)(6916009)(38730400002)(53546003)(229853002)(83716003)(110136004)(4326007)(50226002)(82746002)(74482002)(6246003)(2906002)(93886004)(305945005)(33656002)(97736004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <0225331B8164AB47A4B371FCC5E77B0A@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 10:13:30.0045 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: 7ZLvdDvaNzqUefDdL33uew-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 10:13:40 -0000 PiBPbiA5IEZlYiAyMDE3LCBhdCAxNzoyMywgU2ltb24gSG9ic29uIDxsaW51eEB0aGVob2Jzb25z LmNvLnVrPiB3cm90ZToNCj4gDQo+ICJNdWRyaWMsIER1c2FuIChEdXNhbikiIDxkbXVkcmljQGF2 YXlhLmNvbT4gd3JvdGU6DQo+IA0KPj4gLSAgICAgICAgICBBc3NpZ25tZW50IG9mIG11bHRpcGxl IElQVjYgYWRkcmVzc2VzLCB0aGF0IHRoZSBjbGllbnQgY2Fubm90IHN1cHBvcnQNCj4gDQo+IEkg dGhvdWdodCBpdCB3YXMgcGFydCBvZiB0aGUgc3BlYyB0aGF0IGEgY2xpZW50IG11c3QgYmUgY2Fw YWJsZSBvZiBiZWluZyBjb25maWd1cmVkIHdpdGggbXVsdGlwbGUgYWRkcmVzc2VzLiBBcyBhIG1p bmltdW0gaXQgbXVzdCBzdXBwb3J0IDIgLSBvbmUgbGluay1sb2NhbCwgYW5kIG9uZSBnbG9iYWxs eSB1bmlxdWUgaWYgZXh0ZXJuYWwgY29ubmVjdGl2aXR5IGlzIG5lZWRlZC4NCg0KUkZDIDc5MzQg aXMgYSBnb29kIHJlYWQgb24gdGhhdCB0b3BpYywgdGhvdWdoIGFzIEkgdGhpbmsgQmVybmllIHBv aW50ZWQgb3V0IHRoZSBESENQIHNldCBpbiBTZWN0aW9uIDYgY291bGQgaGF2ZSBiZWVuIHNsaWdo dGx5IGJldHRlciB3cml0dGVuLg0KDQo+ICJNdWRyaWMsIER1c2FuIChEdXNhbikiIDxkbXVkcmlj QGF2YXlhLmNvbT4gd3JvdGU6DQo+IA0KPj4gSSB3YXMganVzdCBzYXlpbmcgdGhlIHZhbGlkYXRp b24gaXMgZG9uZSBpbiB0aGUgYXBwbGljYXRpb24gYmVjYXVzZSBESENQdjYgY2xpZW50IGNhbm5v dCBkbyBpdC4gSXQgaXMgYWJvdXQgdGhlIG5ldHdvcmsgcmVhY2hhYmlsaXR5IGFuZCBub3QgYWJv dXQgdGhlIGFwcGxpY2F0aW9uLiBTaXRlLUxvY2FsIChGRUMwOjovMTApLCBmb3IgZXhhbXBsZSwg Y2Fubm90IGJlIHVzZWQgYnkgYW55IGRldmljZSAoUkZDIDM4Nzk6IERlcHJlY2F0aW5nIFNpdGUg TG9jYWwgQWRkcmVzc2VzLiBUaGUgcHJlZml4IE1VU1QgTk9UIGJlIHJlYXNzaWduZWQgZm9yIG90 aGVyIHVzZSBleGNlcHQgYnkgYSBmdXR1cmUgSUVURiBzdGFuZGFyZHMgYWN0aW9uLikNCj4gDQo+ IDEpIEhvdyBkb2VzIHRoZSBhcHBsaWNhdGlvbiBrbm93IHRoYXQgYWxsb2NhdGlvbiBvZiBzdWNo IGFkZHJlc3NlcyBpc24ndCBhIGRlbGliZXJhdGUgcG9saWN5IGRlY2lzaW9uID8NCj4gMikgSXQn cyBhbiAiYWRtaW4gZXJyb3IiIGFueXdheSBhbmQgaXQgd2lsbCBlaXRoZXIgYSkgYmUgc3BvdHRl ZCBmYWlybHkgcXVpY2tseSBkdWUgdG8gdGhlIGxhY2sgb2YgY29ubmVjdGl2aXR5LCBiKSBvYnZp b3VzbHkgaXNuJ3QgdGhhdCBpbXBvcnRhbnQuDQo+IA0KPiBBbmQgYXMgSSBzYWlkIGJlZm9yZSwg dGhlcmUgaXMgbm90aGluZyB0byBzdG9wIHRoZSBhZG1pbiBwdXR0aW5nIChzYXkpIGFuIGluY29y cmVjdCByb3V0ZXIgYWRkcmVzcyBpbiBESENQdjQgLSBhbmQgSSBjYW4ndCBzYXkgSSd2ZSBzZWVu IGEgbG90IG9mIGNsYW1vdXIgZm9yICJ3ZSBtdXN0IGhhbmRsZSB0aGlzIGF1dG9tYXRpY2FsbHki IGZlYXR1cmVzLg0KDQpXZWxsLCBpdOKAmXMgYSByZWFzb24gd2h5IHRob3NlIHdobyBmYXZvdXIg aG9zdHMgZmF0ZS1zaGFyaW5nIHJvdXRlciBkaXNjb3Zlcnkgd2l0aCB0aGVpciByb3V0ZXIocykg dmlhIFJBcyBoYXZlIG9iamVjdGVkIHRvIGFkZGluZyBhIERIQ1B2NiBkZWZhdWx0IGdhdGV3YXkg b3B0aW9uLiBJbiBhIGNoYW5naW5nIG5ldHdvcmsgdG9wb2xvZ3kvc2NlbmFyaW8sIHRoZSBESENQ IHNlcnZlciBtYXkgbm90IGJlIGNvbmZpZ3VyZWQgd2l0aCB1cC10by1kYXRlIGluZm9ybWF0aW9u LCBvciBldmVuIGFmdGVyIGl0IGlzIGhvc3RzIG1heSBub3QgaGF2ZSByZXF1ZXN0ZWQgaXQuDQoN CknigJltIHdpdGggVGVkIGhlcmUgLSBJIGFtIG5vdCBzdXJlIHdoYXQgcHJvYmxlbSB0aGlzIHN1 Z2dlc3Rpb24gcmVhbGx5IHNvbHZlcy4gIE9yIG1heWJlIGl04oCZcyBhIHJlYXNvbiB0byB1c2Ug U0xBQUMuDQoNClRpbQ0KDQo= From nobody Fri Feb 10 06:35:11 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CB312952C for ; Fri, 10 Feb 2017 06:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 KAm4X-5QcCG7 for ; Fri, 10 Feb 2017 06:35:07 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2A31295EA for ; Fri, 10 Feb 2017 06:35:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GjAAC6zp1Y/xUHmMZeGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8hGCphgQkHjVqSDJMngg+BSkMnhXsCgnY/GAECAQEBAQEBAQN?= =?us-ascii?q?fKIJbPQYHAwEBAQEoAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAgESG0EQBwQCA?= =?us-ascii?q?QgNAQMEAQELHQcyFAkIAgQBEggaiU4IAQ2kcY0HJgKLKQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAR2GTYRugTyBW4EnGIMygjEFiQVvhxWES4YeAYZugyCKU4gIhi+TF?= =?us-ascii?q?R85fk8VPIQ/BR2BYXUBAYdiK4EDAYELAQEB?= X-IPAS-Result: =?us-ascii?q?A2GjAAC6zp1Y/xUHmMZeGQEBAQEBAQEBAQEBBwEBAQEBgm8?= =?us-ascii?q?hGCphgQkHjVqSDJMngg+BSkMnhXsCgnY/GAECAQEBAQEBAQNfKIJbPQYHAwEBA?= =?us-ascii?q?QEoAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAgESG0EQBwQCAQgNAQMEAQELHQc?= =?us-ascii?q?yFAkIAgQBEggaiU4IAQ2kcY0HJgKLKQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GT?= =?us-ascii?q?YRugTyBW4EnGIMygjEFiQVvhxWES4YeAYZugyCKU4gIhi+TFR85fk8VPIQ/BR2?= =?us-ascii?q?BYXUBAYdiK4EDAYELAQEB?= X-IronPort-AV: E=Sophos;i="5.35,141,1484024400"; d="scan'208,217";a="214805173" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Feb 2017 09:35:05 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2017 09:35:05 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 09:35:04 -0500 From: "Mudric, Dusan (Dusan)" To: Simon Hobson , dhcwg Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EAAKQI6AAB7vbSAAMyFpAABwmj1wANVT+AABigYKQA== Date: Fri, 10 Feb 2017 14:35:03 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <0540D77C-E307-4B96-A53B-81599408C8 F7@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> In-Reply-To: <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457AA18ED6AZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:35:10 -0000 --_000_9142206A0C5BF24CB22755C8EC422E457AA18ED6AZUS1EXMB03glob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for all the comments. Personally, I don't think DHCPv6 should be use= d for the address assignment. That topic is already discussed in a differen= t thread. Will not discuss it here. But, if it is used for the address assi= gnment, I would like all of the questions below to be addressed by the prot= ocol. On this topic, there are several open questions about DHCPv6 protocol: - If the key feature of the stateful DHCPv6 is the address assignment, why = there is no any address validation? - Why is the human intervention a part of the protocol? Why the protocol re= quires an administrator not to make mistakes? - Why the client must assign every address offered by the server? Why shoul= d the client save the advertised leases for every IAADDR in IA's, if the st= atus code is STATUS_Success? - Why the client must use the address that does not match any of the router= prefixes? - Why the client is not interworking with ND protocol? - Why the client does not return the address it does not use? - Why is DECLINE message associated with only one error code (DAD failed)? In terms of the implementation, when the problems are understood, both the = server and the client can be improved. The improvements can be done in flex= ible ways. For example, DHCPv6 client policies can be configured in the cli= ent configuration file. There is no need to change the client code. Regards, Dusan. -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simon Hobson Sent: Thursday, February 09, 2017 12:23 PM To: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition "Mudric, Dusan (Dusan)" > wrote= : > - Assignment of multiple IPV6 addresses, that the client cannot = support I thought it was part of the spec that a client must be capable of being co= nfigured with multiple addresses. As a minimum it must support 2 - one link= -local, and one globally unique if external connectivity is needed. On Thu, Feb 9, 2017 at 8:53 AM, Mudric, Dusan (Dusan) > wrote: > " By your own admission, the device **DOES** have a valid working address= , but for some reason the **APPLICATION** cannot use it." > > I was just saying the validation is done in the application because > DHCPv6 client cannot do it. It is about the network reachability and > not about the application. Site-Local (FEC0::/10), for example, cannot > be used by any device (RFC 3879: Deprecating Site Local Addresses. The > prefix MUST NOT be reassigned for other use except by a future IETF > standards action.) So you don't configure your DHCP server to give out those IP addresses. Pr= oblem solved. This doesn't need a protocol change. And should it (the FEC= 0::/10 prefix) be reassigned for other uses in a future IETF standards acti= on, then one would need to change your application again, and/or change the DHCP server again. And, the application may be in use in some network that already has that prefix in u= se because that network has not had the time to renumber that prefix into s= omething like a Unique Local IPv6 prefix (RFC 4193). -- Andre Kostur On Feb 9, 2017, at 11:47 AM, Mudric, Dusan (Dusan) > wrote: The server can do the same validation. If the server does the validation, i= t will be a new feature and there will be a mix of servers that do and do-n= ot provide this validation. The client either has to talk to the server tha= t does provide the validation or do the validation itself. So why is it easier to have the client do the validation than the server? = You're adding protocol to make this work, and in order for this to be usef= ul, changes are required on the server anyway. These changes are quite a = bit more complex than the changes required to simply do whatever validation= you are arguing should be done. So why not do it the easy way instead of= the hard way? This is the first problem statement. There are two more: - Assignment of multiple IPV6 addresses, that the client cannot su= pport Then the client is broken. Why not fix it instead of adding more protocol= ? - A change of IPv6 address, that the client cannot handle Again, the client is broken. Why not fix it instead of adding more protoc= ol? On Thu, Feb 9, 2017 at 8:47 AM, Mudric, Dusan (Dusan) > wrote: > This is the first problem statement. There are two more: > > - Assignment of multiple IPV6 addresses, that the client cannot > support Already dealt with by the protocol. The server OFFERs 2 addresses, the cli= ent just REQUESTs one of them. -- Andre Kostur "Mudric, Dusan (Dusan)" > wrote= : > I was just saying the validation is done in the application because DHCPv= 6 client cannot do it. It is about the network reachability and not about t= he application. Site-Local (FEC0::/10), for example, cannot be used by any = device (RFC 3879: Deprecating Site Local Addresses. The prefix MUST NOT be = reassigned for other use except by a future IETF standards action.) 1) How does the application know that allocation of such addresses isn't a = deliberate policy decision ? 2) It's an "admin error" anyway and it will either a) be spotted fairly qui= ckly due to the lack of connectivity, b) obviously isn't that important. And as I said before, there is nothing to stop the admin putting (say) an i= ncorrect router address in DHCPv4 - and I can't say I've seen a lot of clam= our for "we must handle this automatically" features. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dhcwg&d=3DDQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3D2pBdk64V6N1NIvcAysqRqvG-d1lULT9TqIVtrbk-o8w&= s=3D1tSJd7nDKcvuC97XDWtrkjskLaJPuQovExyz6N3kI_A&e=3D --_000_9142206A0C5BF24CB22755C8EC422E457AA18ED6AZUS1EXMB03glob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for all the comments. Personally, I don= 217;t think DHCPv6 should be used for the address assignment. That topic is= already discussed in a different thread. Will not discuss it here. But, if= it is used for the address assignment, I would like all of the questions below to be addressed by the protocol.

 

On  this topic, there are several open quest= ions about DHCPv6 protocol:

- If the key feature of the stateful DHCPv6 is th= e address assignment, why there is no any address validation?

- Why is the human intervention a part of the pro= tocol? Why the protocol requires an administrator not to make mistakes?

- Why the client must assign every address offere= d by the server? Why should the client save the advertised leases for every= IAADDR in IA’s, if the status code is STATUS_Success?

- Why the client must use the address that does n= ot match any of the router prefixes?

- Why the client is not interworking with ND prot= ocol?

- Why the client does not return the address it d= oes not use?

- Why is DECLINE message associated with only one= error code (DAD failed)?

 

In terms of the implementation, when the problems= are understood, both the server and the client can be improved. The improv= ements can be done in flexible ways. For example, DHCPv6 client policies ca= n be configured in the client configuration file. There is no need to change the client code.

 

Regards,

Dusan.

 =

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simon Hobson
Sent: Thursday, February 09, 2017 12:23 PM
To: dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition

 

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> wrote:

 

> -       &= nbsp;  Assignment of multiple IPV6 addresses, that the client cannot s= upport

 

I thought it was part of the spec that a client m= ust be capable of being configured with multiple addresses. As a minimum it= must support 2 - one link-local, and one globally unique if external conne= ctivity is needed.

 

On Thu, Feb 9, 2017 at 8:53 AM, Mudric, Dusan (Du= san) <dmudric@avaya.com> wro= te:

> " By your own admission, the device **D= OES** have a valid working address, but for some reason the **APPLICATION**= cannot use it."

> 

> I was just saying the validation is done in = the application because

> DHCPv6 client cannot do it. It is about the = network reachability and

> not about the application. Site-Local (FEC0:= :/10), for example, cannot

> be used by any device (RFC 3879: Deprecating= Site Local Addresses. The

> prefix MUST NOT be reassigned for other use = except by a future IETF

> standards action.)

 

So you don't configure your DHCP server to give o= ut those IP addresses.  Problem solved.  This doesn't need a prot= ocol change.  And should it (the FEC0::/10 prefix) be reassigned for o= ther uses in a future IETF standards action, then one would need to change your

application again, and/or change the DHCP server = again.   And, the

application may be in use in some network that al= ready has that prefix in use because that network has not had the time to r= enumber that prefix into something like a Unique Local IPv6 prefix (RFC 419= 3).

 

--

Andre Kostur

 

On Feb 9, 2017, at 11:47 AM, Mudric, Dusan (Dusan) &= lt;dmudric@avaya.com> wrote:

The server can do the = same validation. If the server does the validation, it will be a new featur= e and there will be a mix of servers that do and do-not provide this valida= tion. The client either has to talk to the server that does provide the validation or do the validation itself= .

 

So why is it easier to have the client do the valida= tion than the server?   You're adding protocol to make this work, and = in order for this to be useful, changes are required on the server anyway. =   These changes are quite a bit more complex than the changes required to simply do whatever validation you are arguing= should be done.   So why not do it the easy way instead of the hard w= ay?

 

This is the first prob= lem statement. There are two more:

-  &n= bsp;       Assignment of multiple= IPV6 addresses, that the client cannot support

 

Then the client is broken.   Why not fix it ins= tead of adding more protocol?



-  &n= bsp;       A change of IPv6 addre= ss, that the client cannot handle

 

Again, the client is broken.   Why not fix it i= nstead of adding more protocol?

 

On Thu, Feb 9, 2017 at 8:47 AM, Mudric, Dusan (Du= san) <dmudric@avaya.com> wro= te:

> This is the first problem statement. There a= re two more:

> 

> -       &= nbsp;  Assignment of multiple IPV6 addresses, that the client cannot

> support

 

Already dealt with by the protocol.  The ser= ver OFFERs 2 addresses, the client just REQUESTs one of them.

 

--

Andre Kostur

 

 

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> wrote:

 

> I was just saying the validation is done in = the application because DHCPv6 client cannot do it. It is about the network= reachability and not about the application. Site-Local (FEC0::/10), for ex= ample, cannot be used by any device (RFC 3879: Deprecating Site Local Addresses. The prefix MUST NOT be reassigned = for other use except by a future IETF standards action.)

 

1) How does the application know that allocation = of such addresses isn't a deliberate policy decision ?

2) It's an "admin error" anyway and it = will either a) be spotted fairly quickly due to the lack of connectivity, b= ) obviously isn't that important.

 

And as I said before, there is nothing to stop th= e admin putting (say) an incorrect router address in DHCPv4 - and I can't s= ay I've seen a lot of clamour for "we must handle this automatically&q= uot; features.

 

_______________________________________________

dhcwg mailing list

dhcwg@ietf.org=

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ww= w.ietf.org_mailman_listinfo_dhcwg&d=3DDQICAg&c=3DBFpWQw8bsuKpl1SgiZ= H64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D2pBdk64V6N= 1NIvcAysqRqvG-d1lULT9TqIVtrbk-o8w&s=3D1tSJd7nDKcvuC97XDWtrkjskLaJPuQovE= xyz6N3kI_A&e=3D

--_000_9142206A0C5BF24CB22755C8EC422E457AA18ED6AZUS1EXMB03glob_-- From nobody Fri Feb 10 08:25:26 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328061299E1 for ; Fri, 10 Feb 2017 08:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=incognito-com.20150623.gappssmtp.com 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 mz_sJWHZSomx for ; Fri, 10 Feb 2017 08:25:22 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77020129577 for ; Fri, 10 Feb 2017 08:25:22 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id v200so23873438ywc.3 for ; Fri, 10 Feb 2017 08:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=incognito-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=H+lYkFkUfuAzOshjEvN+3FM6G/qULH/nmxDeUrfoWxI=; b=eJ3lVidEJHM5E+7LcqOws/sWUqFv01OUBswTIa9AypDMClVuDDn3Gwxi/rahX6ODNv tXYkDtT1g+Iy3d4V+VWTJNpovOfV7uMzlhqf4ySsCno++lkpdGMhTEMghSh99Akn82UQ LQOEgwi0p7yx3MBD2CixiZv0t0dIjDXZQO33yAoGvVtbfO+1sgwzTVf6fjlFtbTZMnRW ZWGX9qE4x2IIKSuDBK86aQPWjYzSStqAI97JHceOxsRuXWJlIr4feugOIcIzGOcf1PSj Rs6o3CvD0rvvguZqPidhQftHV3amFZar/9SJBy7+m8xaj/6e5VZQ7iEOAvsN2x+j/eEg 4NRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=H+lYkFkUfuAzOshjEvN+3FM6G/qULH/nmxDeUrfoWxI=; b=DF6vXWI4uPJBOkCxybJoclkvIsMa0HsX9NlQsOZhYEqUb42hJzYEq2IkXuwHqdmSga Jkh21OGMAcfIJF7ScQlaSk6vlpzlb8Qhq2jz/NfCR48sRVu8AOjN6p0VI3V86xj7Y597 ywNsVv0xJDBdzozPEHtiFFEl9kZhLtDSRh6BCfBff3pU3eS8+UigG3wSxjuNBh/0eypB ZhO9LAS3GPNb+FxTtjqxfgIxCggv8BdNohjvhThPaq2GZpL2+4XFPZFqoLZGqAuNxWB/ TrZkji+T9ak8Tf2e0+qYLJ3HoXQnRARt2mvGBHK87JMA2oyin2rDv7KR5FLbG5ZhCJxq V2Bw== X-Gm-Message-State: AMke39l2mb0cY+ogoyNxVSuOTTeFJdmvwmtFXKBJULqXMZl7LiTrsf4h/HaUe2vlzkJS9bL71UY5n6MQ3s43RLhs X-Received: by 10.13.196.129 with SMTP id g123mr7199124ywd.17.1486743921304; Fri, 10 Feb 2017 08:25:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.113.5 with HTTP; Fri, 10 Feb 2017 08:25:20 -0800 (PST) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> From: Andre Kostur Date: Fri, 10 Feb 2017 08:25:20 -0800 Message-ID: To: "Mudric, Dusan (Dusan)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:25:24 -0000 On Fri, Feb 10, 2017 at 6:35 AM, Mudric, Dusan (Dusan) wrote: > - If the key feature of the stateful DHCPv6 is the address assignment, wh= y > there is no any address validation? You need to be clear on what you mean by "address validation". (Oh, and DHCPv6 is responsible for both address and prefix assignment) > - Why is the human intervention a part of the protocol? Why the protocol > requires an administrator not to make mistakes? Everything is susceptible to human error. You need to have more specific use-cases to get anywhere near this question. Also, the protocol does not mandate configuration management. Perhaps your DHCP server has the capability of comparing its configuration with that on a router to look for certain potential configuration mismatches. But that's a quality of implementation issue, not a protocol issue. > - Why the client must assign every address offered by the server? Why sho= uld > the client save the advertised leases for every IAADDR in IA=E2=80=99s, i= f the > status code is STATUS_Success? It doesn't have to. The client can pick and choose, preferably at the ADVERTISE/REQUEST stage. The server ADVERTISEs a dozen addresses, the client decides that it wants only 1 of them and REQUESTs it. Or a less well-behaved client could REQUEST them all, but only actually configure one of them on an interface. > - Why the client must use the address that does not match any of the rout= er > prefixes? The router may not be advertising any prefixes, so the client doesn't know any different. (Nor should it) > - Why the client is not interworking with ND protocol? Be more specific. ND covers a lot of ground. > - Why the client does not return the address it does not use? Talk to your client vendor. The client can return addresses by protocol. Either by not REQUESTing it in the first place (though this isn't returning an address, it's just not claiming it), or by RELEASEing it. > - Why is DECLINE message associated with only one error code (DAD failed)= ? No use-case has been presented that the DHC working group has agreed upon that a DECLINE for other reasons is the appropriate response. --=20 Andre Kostur From nobody Fri Feb 10 09:10:41 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5586C129A47 for ; Fri, 10 Feb 2017 09:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 mXA5BXwRUZTs for ; Fri, 10 Feb 2017 09:10:38 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8724B129A42 for ; Fri, 10 Feb 2017 09:10:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EYAQBg851Y/yYyC4deGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8hQmGBCQeDUooIkguTJ4IPgg2GIgIagl8/GAECAQEBAQEBAQN?= =?us-ascii?q?fKIRpAQEBAQIBEhEKRwUFBwQCAQgNAQMEAQEBCh0DAgICMBQJCAIEDgUIGolOC?= =?us-ascii?q?AGlPopigiUmAosiAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZNhG6BPIMCGBWCby6?= =?us-ascii?q?CMQWJBW+HFYRLhh4BlA6FF4NEhi+TFR85fk8VhHuCA3WHZCuBAwGBCwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2EYAQBg851Y/yYyC4deGQEBAQEBAQEBAQEBBwEBAQEBgm8?= =?us-ascii?q?hQmGBCQeDUooIkguTJ4IPgg2GIgIagl8/GAECAQEBAQEBAQNfKIRpAQEBAQIBE?= =?us-ascii?q?hEKRwUFBwQCAQgNAQMEAQEBCh0DAgICMBQJCAIEDgUIGolOCAGlPopigiUmAos?= =?us-ascii?q?iAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZNhG6BPIMCGBWCby6CMQWJBW+HFYRLh?= =?us-ascii?q?h4BlA6FF4NEhi+TFR85fk8VhHuCA3WHZCuBAwGBCwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,142,1484024400"; d="scan'208,217";a="227582928" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Feb 2017 12:10:36 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2017 12:10:36 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 12:10:35 -0500 From: "Mudric, Dusan (Dusan)" To: Andre Kostur Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EAAKQI6AAB7vbSAAMyFpAABwmj1wAK+Iqs8BXkNKMA== Date: Fri, 10 Feb 2017 17:10:35 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457AA1906FAZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:10:40 -0000 --_000_9142206A0C5BF24CB22755C8EC422E457AA1906FAZUS1EXMB03glob_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5kcmUsDQoNClBsZWFzZSBzZWUgaW5saW5lZA0KDQpUaGFua3MsDQpEdXNhbi4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFuZHJlIEtvc3R1ciBbbWFpbHRvOmFrb3N0 dXJAaW5jb2duaXRvLmNvbV0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTAsIDIwMTcgMTE6MjUg QU0NClRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikNCkNjOiBTaW1vbiBIb2Jzb247IGRoY3dnDQpT dWJqZWN0OiBSZTogW2RoY3dnXSBSRkMzMzE1IERFQ0xJTkUgZGVmaW5pdGlvbg0KDQpPbiBGcmks IEZlYiAxMCwgMjAxNyBhdCA2OjM1IEFNLCBNdWRyaWMsIER1c2FuIChEdXNhbikgPGRtdWRyaWNA YXZheWEuY29tPG1haWx0bzpkbXVkcmljQGF2YXlhLmNvbT4+IHdyb3RlOg0KPiAtIElmIHRoZSBr ZXkgZmVhdHVyZSBvZiB0aGUgc3RhdGVmdWwgREhDUHY2IGlzIHRoZSBhZGRyZXNzIGFzc2lnbm1l bnQsDQo+IHdoeSB0aGVyZSBpcyBubyBhbnkgYWRkcmVzcyB2YWxpZGF0aW9uPw0KDQpZb3UgbmVl ZCB0byBiZSBjbGVhciBvbiB3aGF0IHlvdSBtZWFuIGJ5ICJhZGRyZXNzIHZhbGlkYXRpb24iLiAg KE9oLCBhbmQgREhDUHY2IGlzIHJlc3BvbnNpYmxlIGZvciBib3RoIGFkZHJlc3MgYW5kIHByZWZp eCBhc3NpZ25tZW50KQ0KDQpbRHVzYW5dIC0gU3ludGF4IGNoZWNrcw0KICAgICAgICAgICAgICAt IFNlbWFudGljIGNoZWNrcw0KICAgICAgICAgICAgICAtIFByZWZpeCBjaGVja3MNCg0KPiAtIFdo eSBpcyB0aGUgaHVtYW4gaW50ZXJ2ZW50aW9uIGEgcGFydCBvZiB0aGUgcHJvdG9jb2w/IFdoeSB0 aGUNCj4gcHJvdG9jb2wgcmVxdWlyZXMgYW4gYWRtaW5pc3RyYXRvciBub3QgdG8gbWFrZSBtaXN0 YWtlcz8NCg0KRXZlcnl0aGluZyBpcyBzdXNjZXB0aWJsZSB0byBodW1hbiBlcnJvci4gIFlvdSBu ZWVkIHRvIGhhdmUgbW9yZSBzcGVjaWZpYyB1c2UtY2FzZXMgdG8gZ2V0IGFueXdoZXJlIG5lYXIg dGhpcyBxdWVzdGlvbi4gIEFsc28sIHRoZSBwcm90b2NvbCBkb2VzIG5vdCBtYW5kYXRlIGNvbmZp Z3VyYXRpb24gbWFuYWdlbWVudC4gIFBlcmhhcHMgeW91ciBESENQIHNlcnZlciBoYXMgdGhlIGNh cGFiaWxpdHkgb2YgY29tcGFyaW5nIGl0cyBjb25maWd1cmF0aW9uIHdpdGggdGhhdCBvbiBhIHJv dXRlciB0byBsb29rIGZvciBjZXJ0YWluIHBvdGVudGlhbCBjb25maWd1cmF0aW9uIG1pc21hdGNo ZXMuICBCdXQgdGhhdCdzIGEgcXVhbGl0eSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZSwgbm90IGEg cHJvdG9jb2wgaXNzdWUuDQoNCltEdXNhbl0gSWYgdGhlIHNlcnZlciBjb21tdW5pY2F0ZXMgd2l0 aCBhIHJvdXRlciB0byBjb21wYXJlIHRoZSBjb25maWd1cmF0aW9uLCBpdCBpcyBhIHByb3RvY29s DQoNCj4gLSBXaHkgdGhlIGNsaWVudCBtdXN0IGFzc2lnbiBldmVyeSBhZGRyZXNzIG9mZmVyZWQg YnkgdGhlIHNlcnZlcj8gV2h5DQo+IHNob3VsZCB0aGUgY2xpZW50IHNhdmUgdGhlIGFkdmVydGlz ZWQgbGVhc2VzIGZvciBldmVyeSBJQUFERFIgaW4gSUHigJlzLA0KPiBpZiB0aGUgc3RhdHVzIGNv ZGUgaXMgU1RBVFVTX1N1Y2Nlc3M/DQoNCkl0IGRvZXNuJ3QgaGF2ZSB0by4gIFRoZSBjbGllbnQg Y2FuIHBpY2sgYW5kIGNob29zZSwgcHJlZmVyYWJseSBhdCB0aGUgQURWRVJUSVNFL1JFUVVFU1Qg c3RhZ2UuICBUaGUgc2VydmVyIEFEVkVSVElTRXMgYSBkb3plbiBhZGRyZXNzZXMsIHRoZQ0KY2xp ZW50IGRlY2lkZXMgdGhhdCBpdCB3YW50cyBvbmx5IDEgb2YgdGhlbSBhbmQgUkVRVUVTVHMgaXQu ICAgT3IgYQ0KbGVzcyB3ZWxsLWJlaGF2ZWQgY2xpZW50IGNvdWxkIFJFUVVFU1QgdGhlbSBhbGws IGJ1dCBvbmx5IGFjdHVhbGx5IGNvbmZpZ3VyZSBvbmUgb2YgdGhlbSBvbiBhbiBpbnRlcmZhY2Uu DQoNCltEdXNhbl0gV2hpY2ggc2VjdGlvbiBpbiBSRkMzMzE1IGRlZmluZXMgaG93IERIQ1B2NiBj bGllbnQgc2VsZWN0cyB0aGUgbGVhc2VzPyBXaGljaCBzZWN0aW9uIGRlZmluZXMgd2hhdCB0aGUg Y2xpZW50IGRvZXMgd2l0aCBub24tc2VsZWN0ZWQgbGVhc2VzPw0KDQo+IC0gV2h5IHRoZSBjbGll bnQgbXVzdCB1c2UgdGhlIGFkZHJlc3MgdGhhdCBkb2VzIG5vdCBtYXRjaCBhbnkgb2YgdGhlDQo+ IHJvdXRlciBwcmVmaXhlcz8NCg0KVGhlIHJvdXRlciBtYXkgbm90IGJlIGFkdmVydGlzaW5nIGFu eSBwcmVmaXhlcywgc28gdGhlIGNsaWVudCBkb2Vzbid0IGtub3cgYW55IGRpZmZlcmVudC4gIChO b3Igc2hvdWxkIGl0KQ0KDQpbRHVzYW5dIFdoYXQgaWYgdGhlIHJvdXRlciBhZHZlcnRpc2VkIGEg cHJlZml4IGFuZCB0aGUgY2xpZW50IHJlY2VpdmVkIGFuIGFkZHJlc3MgdGhhdCBkb2VzIG5vdCBz dGFydCB3aXRoIHRoZSBwcmVmaXg/DQoNCj4gLSBXaHkgdGhlIGNsaWVudCBpcyBub3QgaW50ZXJ3 b3JraW5nIHdpdGggTkQgcHJvdG9jb2w/DQoNCkJlIG1vcmUgc3BlY2lmaWMuICBORCBjb3ZlcnMg YSBsb3Qgb2YgZ3JvdW5kLg0KDQpbRHVzYW5dIERIQ1B2NiBjbGllbnQgZG9lcyBub3Qga25vdyBh Ym91dCByb3V0ZXIgcHJlZml4ZXMgYW5kIGRvZXMgbm90IGtub3cgd2hpY2ggcm91dGVyIGlzIHJl YWNoYWJsZS4gV2hpY2ggc2VjdGlvbiBpbiBSRkMzMzE1IGRlZmluZXMgd2hhdCB0aGUgY2xpZW50 IHNob3VsZCBkbyB3aXRoIHRoZSBhZGRyZXNzOg0KLSBpZiBORCByZWNlaXZlcyBwcmVmaXggUDE/ DQotIGlmIHRoZSByb3V0ZXIgdGhhdCBhZHZlcnRpc2VkIFAxIGlzIG5vdCByZWFjaGFibGU/DQoN Cj4gLSBXaHkgdGhlIGNsaWVudCBkb2VzIG5vdCByZXR1cm4gdGhlIGFkZHJlc3MgaXQgZG9lcyBu b3QgdXNlPw0KDQpUYWxrIHRvIHlvdXIgY2xpZW50IHZlbmRvci4gIFRoZSBjbGllbnQgY2FuIHJl dHVybiBhZGRyZXNzZXMgYnkgcHJvdG9jb2wuICBFaXRoZXIgYnkgbm90IFJFUVVFU1RpbmcgaXQg aW4gdGhlIGZpcnN0IHBsYWNlICh0aG91Z2ggdGhpcyBpc24ndCByZXR1cm5pbmcgYW4gYWRkcmVz cywgaXQncyBqdXN0IG5vdCBjbGFpbWluZyBpdCksIG9yIGJ5IFJFTEVBU0VpbmcgaXQuDQoNCltE dXNhbl0gV2hpY2ggc2VjdGlvbiBpbiBSRkMzMzE1IGRlZmluZXMgd2hhdCB0aGUgY2xpZW50IHNo b3VsZCBSRUxFQVNFIGFmdGVyIEFEVkVSVElTRSBhbmQgUkVQTFk/IFdoeSBzaG91bGQgUkVMRUFT RSBiZSB1c2VkIGZvciB0aGUgYWRkcmVzcyB0aGF0IGlzIG5vdCBldmVuIGFzc2lnbmVkPw0KDQo+ IC0gV2h5IGlzIERFQ0xJTkUgbWVzc2FnZSBhc3NvY2lhdGVkIHdpdGggb25seSBvbmUgZXJyb3Ig Y29kZSAoREFEIGZhaWxlZCk/DQoNCk5vIHVzZS1jYXNlIGhhcyBiZWVuIHByZXNlbnRlZCB0aGF0 IHRoZSBESEMgd29ya2luZyBncm91cCBoYXMgYWdyZWVkIHVwb24gdGhhdCBhIERFQ0xJTkUgZm9y IG90aGVyIHJlYXNvbnMgaXMgdGhlIGFwcHJvcHJpYXRlIHJlc3BvbnNlLg0KDQpbRHVzYW5dIFRo YXQgaXMgd2h5IEkgYW0gcHJlc2VudGluZyB0aGVzZSB1c2UgY2FzZXMuDQoNCi0tDQpBbmRyZSBL b3N0dXINCg0K --_000_9142206A0C5BF24CB22755C8EC422E457AA1906FAZUS1EXMB03glob_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SGkgQW5kcmUsPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5QbGVhc2Ugc2VlIGlubGluZWQ8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+RHVzYW4uPC9kaXY+DQo8YSBuYW1lPSJfTWFpbEVuZENv bXBvc2UiPjwvYT4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KDQpGcm9tOiBBbmRyZSBLb3N0dXIgWzxhIGhyZWY9Im1haWx0bzpha29zdHVy QGluY29nbml0by5jb20iPm1haWx0bzpha29zdHVyQGluY29nbml0by5jb208L2E+XQ0KPGJyPg0K DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDEwLCAyMDE3IDExOjI1IEFNPGJyPg0KDQpUbzogTXVk cmljLCBEdXNhbiAoRHVzYW4pPGJyPg0KDQpDYzogU2ltb24gSG9ic29uOyBkaGN3Zzxicj4NCg0K U3ViamVjdDogUmU6IFtkaGN3Z10gUkZDMzMxNSBERUNMSU5FIGRlZmluaXRpb248L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk9uIEZyaSwgRmViIDEwLCAyMDE3IGF0IDY6MzUgQU0sIE11 ZHJpYywgRHVzYW4gKER1c2FuKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRtdWRyaWNAYXZheWEuY29t Ij5kbXVkcmljQGF2YXlhLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7IC0gSWYg dGhlIGtleSBmZWF0dXJlIG9mIHRoZSBzdGF0ZWZ1bCBESENQdjYgaXMgdGhlIGFkZHJlc3MgYXNz aWdubWVudCwgPC9kaXY+DQo8ZGl2PiZndDsgd2h5IHRoZXJlIGlzIG5vIGFueSBhZGRyZXNzIHZh bGlkYXRpb24/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Zb3UgbmVlZCB0byBiZSBj bGVhciBvbiB3aGF0IHlvdSBtZWFuIGJ5ICZxdW90O2FkZHJlc3MgdmFsaWRhdGlvbiZxdW90Oy4m bmJzcDsgKE9oLCBhbmQgREhDUHY2IGlzIHJlc3BvbnNpYmxlIGZvciBib3RoIGFkZHJlc3MgYW5k IHByZWZpeCBhc3NpZ25tZW50KTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+W0R1c2Fu XSAtIFN5bnRheCBjaGVja3M8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gU2Vt YW50aWMgY2hlY2tzPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFByZWZpeCBj aGVja3M8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsgLSBXaHkgaXMgdGhlIGh1 bWFuIGludGVydmVudGlvbiBhIHBhcnQgb2YgdGhlIHByb3RvY29sPyBXaHkgdGhlIDwvZGl2Pg0K PGRpdj4mZ3Q7IHByb3RvY29sIHJlcXVpcmVzIGFuIGFkbWluaXN0cmF0b3Igbm90IHRvIG1ha2Ug bWlzdGFrZXM/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5FdmVyeXRoaW5nIGlzIHN1 c2NlcHRpYmxlIHRvIGh1bWFuIGVycm9yLiZuYnNwOyBZb3UgbmVlZCB0byBoYXZlIG1vcmUgc3Bl Y2lmaWMgdXNlLWNhc2VzIHRvIGdldCBhbnl3aGVyZSBuZWFyIHRoaXMgcXVlc3Rpb24uJm5ic3A7 IEFsc28sIHRoZSBwcm90b2NvbCBkb2VzIG5vdCBtYW5kYXRlIGNvbmZpZ3VyYXRpb24gbWFuYWdl bWVudC4mbmJzcDsgUGVyaGFwcyB5b3VyIERIQ1Agc2VydmVyIGhhcyB0aGUgY2FwYWJpbGl0eSBv ZiBjb21wYXJpbmcgaXRzIGNvbmZpZ3VyYXRpb24NCndpdGggdGhhdCBvbiBhIHJvdXRlciB0byBs b29rIGZvciBjZXJ0YWluIHBvdGVudGlhbCBjb25maWd1cmF0aW9uIG1pc21hdGNoZXMuJm5ic3A7 IEJ1dCB0aGF0J3MgYSBxdWFsaXR5IG9mIGltcGxlbWVudGF0aW9uIGlzc3VlLCBub3QgYSBwcm90 b2NvbCBpc3N1ZS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PltEdXNhbl0gSWYgdGhl IHNlcnZlciBjb21tdW5pY2F0ZXMgd2l0aCBhIHJvdXRlciB0byBjb21wYXJlIHRoZSBjb25maWd1 cmF0aW9uLCBpdCBpcyBhIHByb3RvY29sPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4m Z3Q7IC0gV2h5IHRoZSBjbGllbnQgbXVzdCBhc3NpZ24gZXZlcnkgYWRkcmVzcyBvZmZlcmVkIGJ5 IHRoZSBzZXJ2ZXI/IFdoeSA8L2Rpdj4NCjxkaXY+Jmd0OyBzaG91bGQgdGhlIGNsaWVudCBzYXZl IHRoZSBhZHZlcnRpc2VkIGxlYXNlcyBmb3IgZXZlcnkgSUFBRERSIGluIElB4oCZcywgPC9kaXY+ DQo8ZGl2PiZndDsgaWYgdGhlIHN0YXR1cyBjb2RlIGlzIFNUQVRVU19TdWNjZXNzPzwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SXQgZG9lc24ndCBoYXZlIHRvLiZuYnNwOyBUaGUgY2xp ZW50IGNhbiBwaWNrIGFuZCBjaG9vc2UsIHByZWZlcmFibHkgYXQgdGhlIEFEVkVSVElTRS9SRVFV RVNUIHN0YWdlLiZuYnNwOyBUaGUgc2VydmVyIEFEVkVSVElTRXMgYSBkb3plbiBhZGRyZXNzZXMs IHRoZTwvZGl2Pg0KPGRpdj5jbGllbnQgZGVjaWRlcyB0aGF0IGl0IHdhbnRzIG9ubHkgMSBvZiB0 aGVtIGFuZCBSRVFVRVNUcyBpdC4mbmJzcDsmbmJzcDsgT3IgYTwvZGl2Pg0KPGRpdj5sZXNzIHdl bGwtYmVoYXZlZCBjbGllbnQgY291bGQgUkVRVUVTVCB0aGVtIGFsbCwgYnV0IG9ubHkgYWN0dWFs bHkgY29uZmlndXJlIG9uZSBvZiB0aGVtIG9uIGFuIGludGVyZmFjZS48L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2PltEdXNhbl0gV2hpY2ggc2VjdGlvbiBpbiBSRkMzMzE1IGRlZmluZXMg aG93IERIQ1B2NiBjbGllbnQgc2VsZWN0cyB0aGUgbGVhc2VzPyBXaGljaCBzZWN0aW9uIGRlZmlu ZXMgd2hhdCB0aGUgY2xpZW50IGRvZXMgd2l0aCBub24tc2VsZWN0ZWQgbGVhc2VzPzwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyAtIFdoeSB0aGUgY2xpZW50IG11c3QgdXNlIHRo ZSBhZGRyZXNzIHRoYXQgZG9lcyBub3QgbWF0Y2ggYW55IG9mIHRoZSA8L2Rpdj4NCjxkaXY+Jmd0 OyByb3V0ZXIgcHJlZml4ZXM/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGUgcm91 dGVyIG1heSBub3QgYmUgYWR2ZXJ0aXNpbmcgYW55IHByZWZpeGVzLCBzbyB0aGUgY2xpZW50IGRv ZXNuJ3Qga25vdyBhbnkgZGlmZmVyZW50LiZuYnNwOyAoTm9yIHNob3VsZCBpdCk8L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PltEdXNhbl0gV2hhdCBpZiB0aGUgcm91dGVyIGFkdmVydGlz ZWQgYSBwcmVmaXggYW5kIHRoZSBjbGllbnQgcmVjZWl2ZWQgYW4gYWRkcmVzcyB0aGF0IGRvZXMg bm90IHN0YXJ0IHdpdGggdGhlIHByZWZpeD88L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 PiZndDsgLSBXaHkgdGhlIGNsaWVudCBpcyBub3QgaW50ZXJ3b3JraW5nIHdpdGggTkQgcHJvdG9j b2w/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5CZSBtb3JlIHNwZWNpZmljLiZuYnNw OyBORCBjb3ZlcnMgYSBsb3Qgb2YgZ3JvdW5kLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+W0R1c2FuXSBESENQdjYgY2xpZW50IGRvZXMgbm90IGtub3cgYWJvdXQgcm91dGVyIHByZWZp eGVzIGFuZCBkb2VzIG5vdCBrbm93IHdoaWNoIHJvdXRlciBpcyByZWFjaGFibGUuIFdoaWNoIHNl Y3Rpb24gaW4gUkZDMzMxNSBkZWZpbmVzIHdoYXQgdGhlIGNsaWVudCBzaG91bGQgZG8gd2l0aCB0 aGUgYWRkcmVzczo8L2Rpdj4NCjxkaXY+LSBpZiBORCByZWNlaXZlcyBwcmVmaXggUDE/IDwvZGl2 Pg0KPGRpdj4tIGlmIHRoZSByb3V0ZXIgdGhhdCBhZHZlcnRpc2VkIFAxIGlzIG5vdCByZWFjaGFi bGU/IDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyAtIFdoeSB0aGUgY2xpZW50 IGRvZXMgbm90IHJldHVybiB0aGUgYWRkcmVzcyBpdCBkb2VzIG5vdCB1c2U/PC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5UYWxrIHRvIHlvdXIgY2xpZW50IHZlbmRvci4mbmJzcDsgVGhl IGNsaWVudCBjYW4gcmV0dXJuIGFkZHJlc3NlcyBieSBwcm90b2NvbC4mbmJzcDsgRWl0aGVyIGJ5 IG5vdCBSRVFVRVNUaW5nIGl0IGluIHRoZSBmaXJzdCBwbGFjZSAodGhvdWdoIHRoaXMgaXNuJ3Qg cmV0dXJuaW5nIGFuIGFkZHJlc3MsIGl0J3MganVzdCBub3QgY2xhaW1pbmcgaXQpLCBvciBieSBS RUxFQVNFaW5nIGl0LjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+W0R1c2FuXSBXaGlj aCBzZWN0aW9uIGluIFJGQzMzMTUgZGVmaW5lcyB3aGF0IHRoZSBjbGllbnQgc2hvdWxkIFJFTEVB U0UgYWZ0ZXIgQURWRVJUSVNFIGFuZCBSRVBMWT8gV2h5IHNob3VsZCBSRUxFQVNFIGJlIHVzZWQg Zm9yIHRoZSBhZGRyZXNzIHRoYXQgaXMgbm90IGV2ZW4gYXNzaWduZWQ/PC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7IC0gV2h5IGlzIERFQ0xJTkUgbWVzc2FnZSBhc3NvY2lhdGVk IHdpdGggb25seSBvbmUgZXJyb3IgY29kZSAoREFEIGZhaWxlZCk/PC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj5ObyB1c2UtY2FzZSBoYXMgYmVlbiBwcmVzZW50ZWQgdGhhdCB0aGUgREhD IHdvcmtpbmcgZ3JvdXAgaGFzIGFncmVlZCB1cG9uIHRoYXQgYSBERUNMSU5FIGZvciBvdGhlciBy ZWFzb25zIGlzIHRoZSBhcHByb3ByaWF0ZSByZXNwb25zZS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8ZGl2PltEdXNhbl0gVGhhdCBpcyB3aHkgSSBhbSBwcmVzZW50aW5nIHRoZXNlIHVzZSBj YXNlcy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0tPC9kaXY+DQo8ZGl2PkFuZHJl IEtvc3R1cjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_9142206A0C5BF24CB22755C8EC422E457AA1906FAZUS1EXMB03glob_-- From nobody Fri Feb 10 11:57:52 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D3612957A for ; Fri, 10 Feb 2017 11:57:51 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 tan5KHiKGSr7 for ; Fri, 10 Feb 2017 11:57:49 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [81.174.135.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66931129540 for ; Fri, 10 Feb 2017 11:57:49 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <91[...] Received: from [192.168.137.61] (magpiehouse.plus.com [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 90A9814366 for ; Fri, 10 Feb 2017 19:57:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> Date: Fri, 10 Feb 2017 19:57:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4A6CCC70-7348-4E90-BF4D-5887AF868B2A@thehobsons.co.uk> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457A A189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> To: dhcwg X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 19:57:51 -0000 "Mudric, Dusan (Dusan)" wrote: > Please see inlined If you learned the basics of how to quote stuff properly you wouldn't = need to say that ! Bottom quoting is really quite easy if you try ;-) >> You need to be clear on what you mean by "address validation". (Oh, = and DHCPv6 is responsible for both address and prefix assignment) > =20 > - Syntax checks What sort of syntax checks ? Apart from custom options, there's very = little an admin can do to cause the server to send packets that aren't = syntactically correct. So in most cases, for there to be a syntax issue, = it would indicate a programming error - ie a bug in rhw software. There are far more useful ways to detect that than complicating the = protocol. > - Semantic checks Ditto ? > - Prefix checks How ? Do you propose to equip the client with ESP as to the network = admin's intent ? > > - Why is the human intervention a part of the protocol? Why the > > protocol requires an administrator not to make mistakes? There is a limit to how far you can, or should, take that. The logical = endpoint of that is that "things" come preconfigured with a restricted = set of option that the vendor envisaged you might want to use - more = reliable, less scope for admin errors. Personally I find such systems a = right PITA when they make simple things easy but advanced things = impossible. > What if the router advertised a prefix and the client received an = address that does not start with the prefix? That's not an invalid configuration is it ? From nobody Fri Feb 10 12:01:17 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EDF1294DF for ; Fri, 10 Feb 2017 12:01:16 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 QmruJ3o5HMEX for ; Fri, 10 Feb 2017 12:01:15 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [81.174.135.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E05129B57 for ; Fri, 10 Feb 2017 12:01:07 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <91[...] Received: from [192.168.137.61] (magpiehouse.plus.com [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 946B614366 for ; Fri, 10 Feb 2017 20:01:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <4A6CCC70-7348-4E90-BF4D-5887AF868B2A@thehobsons.co.uk> Date: Fri, 10 Feb 2017 20:01:03 +0000 Content-Transfer-Encoding: 7bit Message-Id: <62605D8C-6FCD-4BAA-BB5F-B7A231EF46B6@thehobsons.co.uk> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457A A189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> <4A6CCC70-7348-4E90-BF4D-5887AF868B2A@thehobsons.co.uk> To: dhcwg X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:01:16 -0000 I wrote: > Bottom quoting is really quite easy if you try ;-) That should say "bottom posting" From nobody Fri Feb 10 12:10:04 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECFE129591 for ; Fri, 10 Feb 2017 12:10:01 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=incognito-com.20150623.gappssmtp.com 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 EbZat1cC6XZJ for ; Fri, 10 Feb 2017 12:10:00 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BAE1295A4 for ; Fri, 10 Feb 2017 12:09:59 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id o65so14766951ybo.2 for ; Fri, 10 Feb 2017 12:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=incognito-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DByg3alcfTIkcaX4/oynw3dSJABg4BDGap84uF7vu5U=; b=cZywq0g6Hqk0iIy1Qe6OK0Wk0q5Q2DGWWFB5JC4DUGkNhsclFOzxteVPllG4DgiCGf Xa9KzVoykHlyObvCZkBs8LirydDAF4kjruUc9lmx9WHO0UgTg15q0xxvka0V2xNYX5TN 9mbu5KSzgpeyAGteeEP6aNW5jKmBOTRj8A5p9j6bttWrEW92s9/qv5MlCJWqXSpirRzN RgxY1IHj/I/KlYADqzgbXz5VyMhn2KVDVnAE7ff1Cj4B2WmW7UN+AIFpPex0Tgzv3f2T YBETOjkFdHaq9t5xZ57RmJEx7qlvhLTgm1fE9SMztLa4kNc4ZHWLTbew3MBnWMoZOUaW XQag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DByg3alcfTIkcaX4/oynw3dSJABg4BDGap84uF7vu5U=; b=bmNl0NFWOvkPfHrTFzTxGPTYvMTnQG7T408q2x520yTnAl2zX6wYXpC1Q6CtcA/cZE WWuefKtgm5G9KIgEBMnRTGdDo8IjetGmLXtnf0BMOMkpwl0k4CIJvE4TbWFS93IQaRNi ScGzgoD71NQX8RmQ4FdR8xB/sk2HSr7HmX0rBaTKwAKscM8CWE8sZac36WvJxC3g6H6f z605CG8c5sBRV9Y94GBiHpQIHuSn0nS/OEJB9EVNoIKgo0xPaY7zwSFZaGXym0u8WJ2T 5Wu3F13sn89y+eo+hpqhQx26O819sRjZnlNKExt0Le5IWWXvuLL0+Zv68CrLt3m9nT8H u6fA== X-Gm-Message-State: AMke39nY/AidX19gn8b5Zo5r9aedXCq9aRfYaxxZ1YPwYUhRFJhHL+Vt/Iw5ExWrT3nAFDASAvyrmDCC6l/dW86L X-Received: by 10.37.197.74 with SMTP id v71mr7891670ybe.33.1486757398442; Fri, 10 Feb 2017 12:09:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.113.5 with HTTP; Fri, 10 Feb 2017 12:09:57 -0800 (PST) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> From: Andre Kostur Date: Fri, 10 Feb 2017 12:09:57 -0800 Message-ID: To: "Mudric, Dusan (Dusan)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 20:10:02 -0000 On Fri, Feb 10, 2017 at 9:10 AM, Mudric, Dusan (Dusan) wrote: >> - If the key feature of the stateful DHCPv6 is the address assignment, >> why there is no any address validation? > > You need to be clear on what you mean by "address validation". (Oh, and > DHCPv6 is responsible for both address and prefix assignment) > > [Dusan] - Syntax checks All of the addresses are necessarily syntactically correct. An address is a 16-byte value. > - Semantic checks Again, covers a lot of ground. Be more specific. > - Prefix checks A decent DHCP server will only allocate addresses that are appropriate to where the client is requesting from. How the DHCP server knows what prefixes are appropriate is a configuration issue and beyond the scope of the DHCPv6 protocol. >> - Why is the human intervention a part of the protocol? Why the >> protocol requires an administrator not to make mistakes? > > Everything is susceptible to human error. You need to have more specific > use-cases to get anywhere near this question. Also, the protocol does no= t > mandate configuration management. Perhaps your DHCP server has the > capability of comparing its configuration with that on a router to look f= or > certain potential configuration mismatches. But that's a quality of > implementation issue, not a protocol issue. > > [Dusan] If the server communicates with a router to compare the > configuration, it is a protocol Just not the DHCPv6 protocol. Which puts it beyond the scope of the working group. >> - Why the client must assign every address offered by the server? Why >> should the client save the advertised leases for every IAADDR in IA=E2= =80=99s, >> if the status code is STATUS_Success? > > It doesn't have to. The client can pick and choose, preferably at the > ADVERTISE/REQUEST stage. The server ADVERTISEs a dozen addresses, the > client decides that it wants only 1 of them and REQUESTs it. Or a > less well-behaved client could REQUEST them all, but only actually config= ure > one of them on an interface. > > [Dusan] Which section in RFC3315 defines how DHCPv6 client selects the > leases? Which section defines what the client does with non-selected leas= es? Beyond the scope of the protocol. The client may use whatever logic it wants to choose which leases it wishes to establish. It REQUESTs the ones it wants, does nothing with the rest. Most servers will quickly reclaim addresses which have been ADVERTISEd but not REQUESTed. That is why it is (by default) a 4-message exchange to establish a lease. The server already has to deal with the idea that its ADVERTISE is never answered. The client may have chosen a different server to get its leases from. >> - Why the client must use the address that does not match any of the >> router prefixes? > > The router may not be advertising any prefixes, so the client doesn't kno= w > any different. (Nor should it) > > [Dusan] What if the router advertised a prefix and the client received an > address that does not start with the prefix? The network administrator may still want to give out an address for an unadvertised prefix. >> - Why the client is not interworking with ND protocol? > > Be more specific. ND covers a lot of ground. > > [Dusan] DHCPv6 client does not know about router prefixes and does not kn= ow > which router is reachable. Which section in RFC3315 defines what the clie= nt > should do with the address: > - if ND receives prefix P1? > - if the router that advertised P1 is not reachable? Beyond the scope of the protocol. Again, the admin may be wishing to assign addresses for an unadvertised prefix. Or the admin may be wishing to give out an address that is intentionally unroutable. Not the protocol's role to decide that. >> - Why the client does not return the address it does not use? > > Talk to your client vendor. The client can return addresses by protocol. > Either by not REQUESTing it in the first place (though this isn't returni= ng > an address, it's just not claiming it), or by RELEASEing it. > > [Dusan] Which section in RFC3315 defines what the client should RELEASE > after ADVERTISE and REPLY? Why should RELEASE be used for the address tha= t > is not even assigned? Nothing to RELEASE after the ADVERTISE. The client does not yet have the lease. As you've already pointed out, the address had not yet been assigned. Section 18.1.6. >> - Why is DECLINE message associated with only one error code (DAD failed= )? > > No use-case has been presented that the DHC working group has agreed upon > that a DECLINE for other reasons is the appropriate response. > > [Dusan] That is why I am presenting these use cases. And so far none of them have been accepted (as problems) by the working group. You need to convince the working group that a problem exists, why the existing protocol can't deal with it, and what is the proposed solution to the problem (with at least some specificity), and why it's worth changing the protocol to deal with the problem. --=20 Andre Kostur From nobody Fri Feb 10 13:08:43 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57649129C0A for ; Fri, 10 Feb 2017 13:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 lj4yMKv9sHAQ for ; Fri, 10 Feb 2017 13:08:40 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CA7129BE3 for ; Fri, 10 Feb 2017 13:08:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F6AQCHK55Y/yYyC4deGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBCgWoHg1KKCJIOkyeCD4INhiICGoJhPxgBAgEBAQEBAQEDXyi?= =?us-ascii?q?EaQEBAQEDEhERQAUMBAIBCA0BAwQBAQMCBh0DAgICMBQBCAgCBA4FCBMHiVYBp?= =?us-ascii?q?UWKYoIlJgKLJgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VChG6BPIMCGIMELoI?= =?us-ascii?q?xBYkFiASKaQGcaYYvkxUfOX5PFYR7BR2BYXWHZCuBAwGBCwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2F6AQCHK55Y/yYyC4deGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?CgWoHg1KKCJIOkyeCD4INhiICGoJhPxgBAgEBAQEBAQEDXyiEaQEBAQEDEhERQ?= =?us-ascii?q?AUMBAIBCA0BAwQBAQMCBh0DAgICMBQBCAgCBA4FCBMHiVYBpUWKYoIlJgKLJgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VChG6BPIMCGIMELoIxBYkFiASKaQGca?= =?us-ascii?q?YYvkxUfOX5PFYR7BR2BYXWHZCuBAwGBCwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,142,1484024400"; d="scan'208";a="214850949" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Feb 2017 16:08:38 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2017 16:08:38 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 15:30:12 -0500 From: "Mudric, Dusan (Dusan)" To: Andre Kostur Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EAAKQI6AAB7vbSAAMyFpAABwmj1wAKewgpMBTtg0kA== Date: Fri, 10 Feb 2017 20:30:11 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:08:42 -0000 REhDUHY2IGlzIHRoZW4gdmVyeSBsaWdodCB3ZWlnaHQ6DQotIGFkZHJlc3MgYXNzaWdubWVudCBp cyBub3QgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbCwNCi0gYWRkcmVzcyBzZWxlY3Rpb24gaXMgbm90 IHBhcnQgb2YgdGhlIHByb3RvY29sLCBhbmQNCi0gaWYgdGhlIGNsaWVudCwgdXNpbmcgaXRzIG93 biBsb2dpYyB0byBzZWxlY3QgZnJvbSB0aGUgb2ZmZXJlZCBhZGRyZXNzZXMgKG5vdCBwYXJ0IG9m IHRoZSBwcm90b2NvbCksIGRvZXMgbm90IHNlbGVjdCBzb21lIG9yIGFueSwgdGhlIHByb3RvY29s IHNob3VsZCBub3QgcmVwb3J0IHRoYXQgdG8gdGhlIHNlcnZlciwgYW5kDQotIHRoZSBmYWN0IHRo YXQgdGhpcyBraW5kIG9mIHByb3RvY29sIGNhbiBsZWF2ZSBhIGRldmljZSB1bnJlYWNoYWJsZSBk b2VzIG5vdCBtYXR0ZXIgdG8gdGhlIHByb3RvY29sIHRoYXQgYXNzaWducyB0aGUgYWRkcmVzcy4N Cg0KRGlkIEkgZ2V0IGl0IGNvcnJlY3RseT8NCg0KUmVnYXJkcywNCkR1c2FuLg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5kcmUgS29zdHVyIFttYWlsdG86YWtvc3R1ckBp bmNvZ25pdG8uY29tXSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTAsIDIwMTcgMzoxMCBQTQ0K VG86IE11ZHJpYywgRHVzYW4gKER1c2FuKQ0KQ2M6IFNpbW9uIEhvYnNvbjsgZGhjd2cNClN1Ympl Y3Q6IFJlOiBbZGhjd2ddIFJGQzMzMTUgREVDTElORSBkZWZpbml0aW9uDQoNCk9uIEZyaSwgRmVi IDEwLCAyMDE3IGF0IDk6MTAgQU0sIE11ZHJpYywgRHVzYW4gKER1c2FuKSA8ZG11ZHJpY0BhdmF5 YS5jb20+IHdyb3RlOg0KDQo+PiAtIElmIHRoZSBrZXkgZmVhdHVyZSBvZiB0aGUgc3RhdGVmdWwg REhDUHY2IGlzIHRoZSBhZGRyZXNzIA0KPj4gYXNzaWdubWVudCwgd2h5IHRoZXJlIGlzIG5vIGFu eSBhZGRyZXNzIHZhbGlkYXRpb24/DQo+DQo+IFlvdSBuZWVkIHRvIGJlIGNsZWFyIG9uIHdoYXQg eW91IG1lYW4gYnkgImFkZHJlc3MgdmFsaWRhdGlvbiIuICAoT2gsIA0KPiBhbmQNCj4gREhDUHY2 IGlzIHJlc3BvbnNpYmxlIGZvciBib3RoIGFkZHJlc3MgYW5kIHByZWZpeCBhc3NpZ25tZW50KQ0K Pg0KPiBbRHVzYW5dIC0gU3ludGF4IGNoZWNrcw0KDQpBbGwgb2YgdGhlIGFkZHJlc3NlcyBhcmUg bmVjZXNzYXJpbHkgc3ludGFjdGljYWxseSBjb3JyZWN0LiAgQW4gYWRkcmVzcyBpcyBhIDE2LWJ5 dGUgdmFsdWUuDQoNCj4gICAgICAgICAgICAgICAtIFNlbWFudGljIGNoZWNrcw0KDQpBZ2Fpbiwg Y292ZXJzIGEgbG90IG9mIGdyb3VuZC4gIEJlIG1vcmUgc3BlY2lmaWMuDQoNCj4gICAgICAgICAg ICAgICAtIFByZWZpeCBjaGVja3MNCg0KQSBkZWNlbnQgREhDUCBzZXJ2ZXIgd2lsbCBvbmx5IGFs bG9jYXRlIGFkZHJlc3NlcyB0aGF0IGFyZSBhcHByb3ByaWF0ZSB0byB3aGVyZSB0aGUgY2xpZW50 IGlzIHJlcXVlc3RpbmcgZnJvbS4gIEhvdyB0aGUgREhDUCBzZXJ2ZXIga25vd3Mgd2hhdCBwcmVm aXhlcyBhcmUgYXBwcm9wcmlhdGUgaXMgYSBjb25maWd1cmF0aW9uIGlzc3VlIGFuZCBiZXlvbmQg dGhlIHNjb3BlIG9mIHRoZSBESENQdjYgcHJvdG9jb2wuDQoNCj4+IC0gV2h5IGlzIHRoZSBodW1h biBpbnRlcnZlbnRpb24gYSBwYXJ0IG9mIHRoZSBwcm90b2NvbD8gV2h5IHRoZSANCj4+IHByb3Rv Y29sIHJlcXVpcmVzIGFuIGFkbWluaXN0cmF0b3Igbm90IHRvIG1ha2UgbWlzdGFrZXM/DQo+DQo+ IEV2ZXJ5dGhpbmcgaXMgc3VzY2VwdGlibGUgdG8gaHVtYW4gZXJyb3IuICBZb3UgbmVlZCB0byBo YXZlIG1vcmUgDQo+IHNwZWNpZmljIHVzZS1jYXNlcyB0byBnZXQgYW55d2hlcmUgbmVhciB0aGlz IHF1ZXN0aW9uLiAgQWxzbywgdGhlIA0KPiBwcm90b2NvbCBkb2VzIG5vdCBtYW5kYXRlIGNvbmZp Z3VyYXRpb24gbWFuYWdlbWVudC4gIFBlcmhhcHMgeW91ciBESENQIA0KPiBzZXJ2ZXIgaGFzIHRo ZSBjYXBhYmlsaXR5IG9mIGNvbXBhcmluZyBpdHMgY29uZmlndXJhdGlvbiB3aXRoIHRoYXQgb24g DQo+IGEgcm91dGVyIHRvIGxvb2sgZm9yIGNlcnRhaW4gcG90ZW50aWFsIGNvbmZpZ3VyYXRpb24g bWlzbWF0Y2hlcy4gIEJ1dCANCj4gdGhhdCdzIGEgcXVhbGl0eSBvZiBpbXBsZW1lbnRhdGlvbiBp c3N1ZSwgbm90IGEgcHJvdG9jb2wgaXNzdWUuDQo+DQo+IFtEdXNhbl0gSWYgdGhlIHNlcnZlciBj b21tdW5pY2F0ZXMgd2l0aCBhIHJvdXRlciB0byBjb21wYXJlIHRoZSANCj4gY29uZmlndXJhdGlv biwgaXQgaXMgYSBwcm90b2NvbA0KDQpKdXN0IG5vdCB0aGUgREhDUHY2IHByb3RvY29sLiAgV2hp Y2ggcHV0cyBpdCBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSB3b3JraW5nIGdyb3VwLg0KDQo+PiAt IFdoeSB0aGUgY2xpZW50IG11c3QgYXNzaWduIGV2ZXJ5IGFkZHJlc3Mgb2ZmZXJlZCBieSB0aGUg c2VydmVyPyBXaHkgDQo+PiBzaG91bGQgdGhlIGNsaWVudCBzYXZlIHRoZSBhZHZlcnRpc2VkIGxl YXNlcyBmb3IgZXZlcnkgSUFBRERSIGluIA0KPj4gSUHigJlzLCBpZiB0aGUgc3RhdHVzIGNvZGUg aXMgU1RBVFVTX1N1Y2Nlc3M/DQo+DQo+IEl0IGRvZXNuJ3QgaGF2ZSB0by4gIFRoZSBjbGllbnQg Y2FuIHBpY2sgYW5kIGNob29zZSwgcHJlZmVyYWJseSBhdCB0aGUgDQo+IEFEVkVSVElTRS9SRVFV RVNUIHN0YWdlLiAgVGhlIHNlcnZlciBBRFZFUlRJU0VzIGEgZG96ZW4gYWRkcmVzc2VzLCB0aGUN Cj4gY2xpZW50IGRlY2lkZXMgdGhhdCBpdCB3YW50cyBvbmx5IDEgb2YgdGhlbSBhbmQgUkVRVUVT VHMgaXQuICAgT3IgYQ0KPiBsZXNzIHdlbGwtYmVoYXZlZCBjbGllbnQgY291bGQgUkVRVUVTVCB0 aGVtIGFsbCwgYnV0IG9ubHkgYWN0dWFsbHkgDQo+IGNvbmZpZ3VyZSBvbmUgb2YgdGhlbSBvbiBh biBpbnRlcmZhY2UuDQo+DQo+IFtEdXNhbl0gV2hpY2ggc2VjdGlvbiBpbiBSRkMzMzE1IGRlZmlu ZXMgaG93IERIQ1B2NiBjbGllbnQgc2VsZWN0cyB0aGUgDQo+IGxlYXNlcz8gV2hpY2ggc2VjdGlv biBkZWZpbmVzIHdoYXQgdGhlIGNsaWVudCBkb2VzIHdpdGggbm9uLXNlbGVjdGVkIGxlYXNlcz8N Cg0KQmV5b25kIHRoZSBzY29wZSBvZiB0aGUgcHJvdG9jb2wuICBUaGUgY2xpZW50IG1heSB1c2Ug d2hhdGV2ZXIgbG9naWMgaXQgd2FudHMgdG8gY2hvb3NlIHdoaWNoIGxlYXNlcyBpdCB3aXNoZXMg dG8gZXN0YWJsaXNoLiAgSXQgUkVRVUVTVHMgdGhlIG9uZXMgaXQgd2FudHMsIGRvZXMgbm90aGlu ZyB3aXRoIHRoZSByZXN0LiAgTW9zdCBzZXJ2ZXJzIHdpbGwgcXVpY2tseSByZWNsYWltIGFkZHJl c3NlcyB3aGljaCBoYXZlIGJlZW4gQURWRVJUSVNFZCBidXQgbm90IFJFUVVFU1RlZC4gIFRoYXQg aXMgd2h5IGl0IGlzIChieSBkZWZhdWx0KSBhIDQtbWVzc2FnZSBleGNoYW5nZSB0byBlc3RhYmxp c2ggYSBsZWFzZS4gIFRoZSBzZXJ2ZXIgYWxyZWFkeSBoYXMgdG8gZGVhbCB3aXRoIHRoZSBpZGVh IHRoYXQgaXRzIEFEVkVSVElTRSBpcyBuZXZlciBhbnN3ZXJlZC4gIFRoZSBjbGllbnQgbWF5IGhh dmUgY2hvc2VuIGEgZGlmZmVyZW50IHNlcnZlciB0byBnZXQgaXRzIGxlYXNlcyBmcm9tLg0KDQo+ PiAtIFdoeSB0aGUgY2xpZW50IG11c3QgdXNlIHRoZSBhZGRyZXNzIHRoYXQgZG9lcyBub3QgbWF0 Y2ggYW55IG9mIHRoZSANCj4+IHJvdXRlciBwcmVmaXhlcz8NCj4NCj4gVGhlIHJvdXRlciBtYXkg bm90IGJlIGFkdmVydGlzaW5nIGFueSBwcmVmaXhlcywgc28gdGhlIGNsaWVudCBkb2Vzbid0IA0K PiBrbm93IGFueSBkaWZmZXJlbnQuICAoTm9yIHNob3VsZCBpdCkNCj4NCj4gW0R1c2FuXSBXaGF0 IGlmIHRoZSByb3V0ZXIgYWR2ZXJ0aXNlZCBhIHByZWZpeCBhbmQgdGhlIGNsaWVudCByZWNlaXZl ZCANCj4gYW4gYWRkcmVzcyB0aGF0IGRvZXMgbm90IHN0YXJ0IHdpdGggdGhlIHByZWZpeD8NCg0K VGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvciBtYXkgc3RpbGwgd2FudCB0byBnaXZlIG91dCBhbiBh ZGRyZXNzIGZvciBhbiB1bmFkdmVydGlzZWQgcHJlZml4Lg0KDQo+PiAtIFdoeSB0aGUgY2xpZW50 IGlzIG5vdCBpbnRlcndvcmtpbmcgd2l0aCBORCBwcm90b2NvbD8NCj4NCj4gQmUgbW9yZSBzcGVj aWZpYy4gIE5EIGNvdmVycyBhIGxvdCBvZiBncm91bmQuDQo+DQo+IFtEdXNhbl0gREhDUHY2IGNs aWVudCBkb2VzIG5vdCBrbm93IGFib3V0IHJvdXRlciBwcmVmaXhlcyBhbmQgZG9lcyBub3QgDQo+ IGtub3cgd2hpY2ggcm91dGVyIGlzIHJlYWNoYWJsZS4gV2hpY2ggc2VjdGlvbiBpbiBSRkMzMzE1 IGRlZmluZXMgd2hhdCANCj4gdGhlIGNsaWVudCBzaG91bGQgZG8gd2l0aCB0aGUgYWRkcmVzczoN Cj4gLSBpZiBORCByZWNlaXZlcyBwcmVmaXggUDE/DQo+IC0gaWYgdGhlIHJvdXRlciB0aGF0IGFk dmVydGlzZWQgUDEgaXMgbm90IHJlYWNoYWJsZT8NCg0KQmV5b25kIHRoZSBzY29wZSBvZiB0aGUg cHJvdG9jb2wuICBBZ2FpbiwgdGhlIGFkbWluIG1heSBiZSB3aXNoaW5nIHRvIGFzc2lnbiBhZGRy ZXNzZXMgZm9yIGFuIHVuYWR2ZXJ0aXNlZCBwcmVmaXguICBPciB0aGUgYWRtaW4gbWF5IGJlIHdp c2hpbmcgdG8gZ2l2ZSBvdXQgYW4gYWRkcmVzcyB0aGF0IGlzIGludGVudGlvbmFsbHkgdW5yb3V0 YWJsZS4gIE5vdCB0aGUgcHJvdG9jb2wncyByb2xlIHRvIGRlY2lkZSB0aGF0Lg0KDQo+PiAtIFdo eSB0aGUgY2xpZW50IGRvZXMgbm90IHJldHVybiB0aGUgYWRkcmVzcyBpdCBkb2VzIG5vdCB1c2U/ DQo+DQo+IFRhbGsgdG8geW91ciBjbGllbnQgdmVuZG9yLiAgVGhlIGNsaWVudCBjYW4gcmV0dXJu IGFkZHJlc3NlcyBieSBwcm90b2NvbC4NCj4gRWl0aGVyIGJ5IG5vdCBSRVFVRVNUaW5nIGl0IGlu IHRoZSBmaXJzdCBwbGFjZSAodGhvdWdoIHRoaXMgaXNuJ3QgDQo+IHJldHVybmluZyBhbiBhZGRy ZXNzLCBpdCdzIGp1c3Qgbm90IGNsYWltaW5nIGl0KSwgb3IgYnkgUkVMRUFTRWluZyBpdC4NCj4N Cj4gW0R1c2FuXSBXaGljaCBzZWN0aW9uIGluIFJGQzMzMTUgZGVmaW5lcyB3aGF0IHRoZSBjbGll bnQgc2hvdWxkIA0KPiBSRUxFQVNFIGFmdGVyIEFEVkVSVElTRSBhbmQgUkVQTFk/IFdoeSBzaG91 bGQgUkVMRUFTRSBiZSB1c2VkIGZvciB0aGUgDQo+IGFkZHJlc3MgdGhhdCBpcyBub3QgZXZlbiBh c3NpZ25lZD8NCg0KTm90aGluZyB0byBSRUxFQVNFIGFmdGVyIHRoZSBBRFZFUlRJU0UuICBUaGUg Y2xpZW50IGRvZXMgbm90IHlldCBoYXZlIHRoZSBsZWFzZS4gIEFzIHlvdSd2ZSBhbHJlYWR5IHBv aW50ZWQgb3V0LCB0aGUgYWRkcmVzcyBoYWQgbm90IHlldCBiZWVuIGFzc2lnbmVkLiAgU2VjdGlv biAxOC4xLjYuDQoNCj4+IC0gV2h5IGlzIERFQ0xJTkUgbWVzc2FnZSBhc3NvY2lhdGVkIHdpdGgg b25seSBvbmUgZXJyb3IgY29kZSAoREFEIGZhaWxlZCk/DQo+DQo+IE5vIHVzZS1jYXNlIGhhcyBi ZWVuIHByZXNlbnRlZCB0aGF0IHRoZSBESEMgd29ya2luZyBncm91cCBoYXMgYWdyZWVkIA0KPiB1 cG9uIHRoYXQgYSBERUNMSU5FIGZvciBvdGhlciByZWFzb25zIGlzIHRoZSBhcHByb3ByaWF0ZSBy ZXNwb25zZS4NCj4NCj4gW0R1c2FuXSBUaGF0IGlzIHdoeSBJIGFtIHByZXNlbnRpbmcgdGhlc2Ug dXNlIGNhc2VzLg0KDQpBbmQgc28gZmFyIG5vbmUgb2YgdGhlbSBoYXZlIGJlZW4gYWNjZXB0ZWQg KGFzIHByb2JsZW1zKSBieSB0aGUgd29ya2luZyBncm91cC4gIFlvdSBuZWVkIHRvIGNvbnZpbmNl IHRoZSB3b3JraW5nIGdyb3VwIHRoYXQgYSBwcm9ibGVtIGV4aXN0cywgd2h5IHRoZSBleGlzdGlu ZyBwcm90b2NvbCBjYW4ndCBkZWFsIHdpdGggaXQsIGFuZCB3aGF0IGlzIHRoZSBwcm9wb3NlZCBz b2x1dGlvbiB0byB0aGUgcHJvYmxlbSAod2l0aCBhdCBsZWFzdCBzb21lIHNwZWNpZmljaXR5KSwg YW5kIHdoeSBpdCdzIHdvcnRoIGNoYW5naW5nIHRoZSBwcm90b2NvbCB0byBkZWFsIHdpdGggdGhl IHByb2JsZW0uDQoNCi0tDQpBbmRyZSBLb3N0dXINCg== From nobody Fri Feb 10 13:34:34 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9682D129C53 for ; Fri, 10 Feb 2017 13:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=incognito-com.20150623.gappssmtp.com 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 14z1MBItdKAG for ; Fri, 10 Feb 2017 13:34:30 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90A0129C4A for ; Fri, 10 Feb 2017 13:34:29 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id v200so28653117ywc.3 for ; Fri, 10 Feb 2017 13:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=incognito-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iQNU14iUu4yXhKZ5EKhKSKCOc7sAUTUJHQZ7z3Xi9fQ=; b=trfmZk9AAHgZcbu8LrQ0vpDadFEQb8JvaQ7lhAZayB1NC/2LncwQ/khMP/VYC+6a28 70XdyvtWN8dxt+5KtpYRx4X0FgbXDxqUxZ+SBagNBULXR/2BGIBx3UkqXJeVZoFJA+Ix 7ELjg8Mpdmx/h0y9sH4IRIM1bMt1RmKKmoQ8g1PzAvg4SjX8O5VDXKWyw7qRiYjiLORH VYw6z7dtyFmh0SIGZa5ajSuXrVXBylSTDhSZYad9cyv4HD3TffnpduLn69F1WlGwkL43 qapgiUiEE/bllFPiLjrGg4urQk/mSDMSstBxGIOkK5gYH39eESp8aQ0t9beqRByPEsRC P5KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iQNU14iUu4yXhKZ5EKhKSKCOc7sAUTUJHQZ7z3Xi9fQ=; b=DpukNJY/tXlPgh0kCQRukKYzTqUKIlfr8hGyFmJfUMYYhQhfl70k78xJ+d31VKVXCX eH6mi53Y4SZjZGjNDecF1t/W08QToGQwhfdgGgKxPJenjeHkAzLuIZJRYsFrfor8/FGy SREzEfzj3NIpKeqEDEFgRGH7wE1GLbDTYogGdLRIon2lNLYkbYcNZKXeNfEfQ30t67Fl W07WKIpefY9IpqVXLZtMjsqCDfgq4WoT7brhCDLZ7OA7wuFrwzPmCBY5YJQ6rz+eyv4J OeZKAX9uqp6X1jx182bg6/87rNXhKGQOCPozI6dWehvbMYe0zhR5ejfY+7mbNwYVKy9j Xziw== X-Gm-Message-State: AMke39kpWpwNFE8lLEB3mDi3Q9GKQsm1S5NcTuKJKRYX+jjK8c4i1nQZg4gRZrpzLx4rve9l/T3O6acIEdwlbCCM X-Received: by 10.13.196.129 with SMTP id g123mr8251178ywd.17.1486762468878; Fri, 10 Feb 2017 13:34:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.113.5 with HTTP; Fri, 10 Feb 2017 13:34:28 -0800 (PST) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com> From: Andre Kostur Date: Fri, 10 Feb 2017 13:34:28 -0800 Message-ID: To: "Mudric, Dusan (Dusan)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:34:31 -0000 On Fri, Feb 10, 2017 at 12:30 PM, Mudric, Dusan (Dusan) wrote: > DHCPv6 is then very light weight: Well.. I suspect a bunch of us DHCP implementers may not agree with that statement. > - address assignment is not a part of the protocol, Where did you get this idea from? DHCPv6 assigns addresses all day long. What the client does with that assignment is up to the client. > - address selection is not part of the protocol, and How the client selects which address to use? Nope. The protocol doesn't care, nor should it. The server determines what its willing to ADVERTISE to the client and sends it off. The client REQUESTs what it wants. The server REPLYs to complete the "contract" that the client may use those addresses named in the REPLY for the specified Valid Lifetime. This allows different clients to choose different methods for selecting an address. > - if the client, using its own logic to select from the offered addresses (not part of the protocol), does not select some or any, the protocol should not report that to the server, and It does not appear that anybody else here understands why you keep hammering on this point. You have not said why this is a problem beyond "I want to". A common implementation is that the server holds aside the ADVERTISEd addresses for a short while (maybe a few minutes, maybe 10s of seconds, its an implementation detail). If the client doesn't come back and REQUEST it, then release it back to the pool. In an address space that's 2^64 in size, who cares if a handful of addresses are being held aside for clients that have not yet come to REQUEST them. This worked perfectly fine even in the IPv4 cases where the address space is much smaller (possibly 10s of addresses). > - the fact that this kind of protocol can leave a device unreachable does not matter to the protocol that assigns the address. Nope. And the admin may be intentionally doing so. Not for the protocol to decide. > Did I get it correctly? No. I have to ask: what's the motivation behind asking these questions? There seems to be a more fundamental misunderstanding underlying this line of questioning. -- Andre Kostur From nobody Fri Feb 10 13:38:27 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD84A129C51; Fri, 10 Feb 2017 13:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 aPpe8gCBa-CU; Fri, 10 Feb 2017 13:38:23 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB8D129C58; Fri, 10 Feb 2017 13:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25670; q=dns/txt; s=iport; t=1486762702; x=1487972302; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QaeZZs15m6A+G7MGBBseh9ZTB1KiqDzswey4qiSqYEI=; b=aoS1DhIJNF6Is4GcggnoRUgoeGn5iEfXHDgWLEIJZhmwy1jtt1/gi2Qy kH5pxINNdkI4nOinLwd8SrmFEWZUqnXHufgbgyOPDVBGk+LnCe3br/BfK QVohRYK9eiO5jjbW8Z/i9bbQt34XFpFN3UjcIoA5zyPW+s39hRUS2Kj6j M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCdMZ5Y/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9jYYEJjWGSDogMjSqCDS6FdAKCez8YAQIBAQEBAQEBYiiEaQE?= =?us-ascii?q?BAQICLUELEAIBCBEDAQEBIQcHIREUCQgBAQQOBR+JQQMVDqxFhXaHLQ2EEwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFiFGCaoJRgW02FoJ+gjEFiQSIBYRLhWQ6AYZ?= =?us-ascii?q?ufIYQhBmBe4UXiXOKNYRGhBkBHzh+TxU8EQGGMHUBih0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,142,1484006400"; d="scan'208,217";a="383422943" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2017 21:38:21 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1ALcL8f026947 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 21:38:21 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 15:38:20 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Fri, 10 Feb 2017 15:38:20 -0600 From: "Bernie Volz (volz)" To: "Fang, Luyuan" Thread-Topic: WG meeting follow-up - Forcerenew Reconfiguration Extensions for DHCPv4 Thread-Index: AdJFrgUx4It+bot+S7WY8x3eyFGyNQGacxOAASTqXrAMnAjUgAAymE2K Date: Fri, 10 Feb 2017 21:38:20 +0000 Message-ID: <509D194F-52D0-4E8B-97C2-C099201A59AF@cisco.com> References: <3f436153e5004bd285f29ffb79c6865e@XCH-ALN-003.cisco.com> <66b668a7292c4a638be82b5029d3c070@XCH-ALN-003.cisco.com>, <5EDAFB65-056F-44B1-9F61-490422391068@ebay.com> In-Reply-To: <5EDAFB65-056F-44B1-9F61-490422391068@ebay.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_509D194F52D04E8B97C2C099201A59AFciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-dhc-dhcpv4-forcerenew-extensions@ietf.org" , "dhcwg@ietf.org" , "Deepak Bansal \(AZURE\)" , Fabio Chiussi Subject: Re: [dhcwg] WG meeting follow-up - Forcerenew Reconfiguration Extensions for DHCPv4 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:38:26 -0000 --_000_509D194F52D04E8B97C2C099201A59AFciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: Thanks. - Bernie (from iPad) On Feb 10, 2017, at 12:29 AM, Fang, Luyuan > wrote: Hi Bernie, Thank you for your review and discussion. Sorry for the late reply. MSFT Azure is working to have an implementation in CY17, we'll wait a bit b= efore WGLC. Regarding your comments for Section 2.3, good points, we removed both sente= nces in the updated version. https://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-forcerenew-extensions-02 Thanks, Luyuan From: "Bernie Volz (volz)" > Date: Wednesday, December 7, 2016 at 9:09 AM To: "Fang, Luyuan" >, "dhcwg@ietf.o= rg" > Cc: "draft-ietf-dhc-dhcpv4-forcerenew-extensions@ietf.org" >, "Deepak Bansal (AZURE)" >, Fabio Chiussi > Subject: RE: WG meeting follow-up - Forcerenew Reconfiguration Extensions f= or DHCPv4 Thanks Luyuan. So, at this point the next step is really to up to you ... seems to be: 1. Wait until MSFT has implemented and see if that generates any addi= tional changes to the document 2. Initiate WGLC (either now or after 1 - perhaps waiting is best) I do see that Section 2.3 discusses some potential work (as this alternativ= e mechanism is not defined): Alternatively, a mechanism for the client to explicit inform the server that it is declining the server-initiated DHCPINFOFORCERENEW reconfiguration procedure needs to be devised. It seems to me that this might be worth either removing? That 2.3 section a= lso has an odd sentence (This further aligns the client behavior in DHCPv4 = server-initiated reconfiguration with the corresponding behavior in DHCPv6.= ) as I don't recall any such capability in DHCPv6? In DHCPv6 a client can i= ndicate whether it supports Reconfigure, but not which of the Reconfigure m= essages (Renew, Rebind, or Information-Request). And, an issue with #1 is that you'd have to pick a message number to use as= IANA won't have assigned a new one for the DHCPFORCEINFORENEW message (and= that could possible conflict if there was something else assigned in the i= nterim, though I am not aware of anything.) - Bernie From: Fang, Luyuan [mailto:lufang@ebay.com] Sent: Friday, December 02, 2016 12:14 AM To: Bernie Volz (volz) >; dhcwg@ietf.= org Cc: draft-ietf-dhc-dhcpv4-forcerenew-extensions@ietf.org; Deepak Bansal (AZURE) >; Fabio Chiussi > Subject: Re: WG meeting follow-up - Forcerenew Reconfiguration Extensions f= or DHCPv4 Hi Tomek and Bernie, Thanks for presenting the draft in the last IETF and bring this to dhc wg d= iscussion. Sorry for the delayed response. Yes, we still have strong interests to complete this work. MSFT is working = to implement it in Azure. We will report the results when ready. At the meantime, we'll post a new version without content change. Thanks, Luyuan From: "Bernie Volz (volz)" > Date: Wednesday, November 23, 2016 at 10:50 AM To: "dhcwg@ietf.org" > Cc: "draft-ietf-dhc-dhcpv4-forcerenew-extensions@ietf.org" > Subject: WG meeting follow-up - Forcerenew Reconfiguration Extensions for D= HCPv4 Hi: At the IETF-97 (Seoul) DHC WG meeting, Tomek had a brief presentation regar= ding draft-ietf-dhc-dhcpv4-forcerenew-extensions (see https://www.ietf.org/= proceedings/97/slides/slides-97-dhc-next-steps-for-draft-ietf-dhc-dhcpv4-fo= rcerenew-extensions-00.pdf). This document has been inactive since WG adoption and has now expired. The = co-chairs made several attempts to contact the authors, but they were unres= ponsive. Tomek asked those in the room if there was any interest from someo= ne to take on this work. There was no interest expressed, but we want to ta= ke it to the WG mailing list to see if anyone has any interest. If you do have interest in working on this, please contact the DHC WG chair= s (dhc-chairs@ietf.org). You can view the current (expired) draft at https://tools.ietf.org/html/dra= ft-ietf-dhc-dhcpv4-forcerenew-extensions-00. If there is no interest, the document will just be left as it is today (exp= ired). Work on it can always be revived sometime in the future if a need de= velops. Thanks. - Tomek & Bernie --_000_509D194F52D04E8B97C2C099201A59AFciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi:

Thanks.

- Bernie (from iPad)

On Feb 10, 2017, at 12:29 AM, Fang, Luyuan <lufang@ebay.com> wrote:

Hi Bernie,

 

Thank you for your review and discussion. Sorry for = the late reply.

MSFT Azure is working to have an implementation in C= Y17, we’ll wait a bit before WGLC.

 

Regarding your comments for Section 2.3, good points= , we removed both sentences in the updated version.

https://tools.ietf.org/html/draft-ietf-d= hc-dhcpv4-forcerenew-extensions-02

 

Thanks,

Luyuan

 

From: "Bernie Volz (volz)" <volz@cisco.com>
Date: Wednesday, December 7, 2016 at 9:09 AM
To: "Fang, Luyuan" <= lufang@ebay.com>, "dhcwg@ietf= .org" <dhcwg@ietf.org>=
Cc: "draft-ietf-dhc-dhcpv4-forcerenew-extensions@ietf.org"= ; <draft-ietf-dhc-dhcpv4-forcerenew-extensions@ietf.org>, "Deepak Bansal (AZURE)" <dbansal@microsoft.com>, Fabio Chiussi <fabiochiussi@gmail.com>
Subject: RE: WG meeting follow-up - Forcerenew Reconfiguration Exten= sions for DHCPv4

 

Thanks Luyuan.<= o:p>

 

So, at this point the = next step is really to up to you … seems to be:

 

1.    &nbs= p;  Wait until MSFT h= as implemented and see if that generates any additional changes to the docu= ment

2.    &nbs= p;  Initiate WGLC (ei= ther now or after 1 – perhaps waiting is best)

 

I do see that Section = 2.3 discusses some potential work (as this alternative mechanism is not def= ined):

 

   Alternatively, a mechanism for th= e client to explicit inform the

   server that it is declining the s= erver-initiated DHCPINFOFORCERENEW

   reconfiguration procedure needs t= o be devised.

 

It seems to me that th= is might be worth either removing? That 2.3 section also has an odd sentenc= e (This further aligns the client behavior in DHCPv4 server-initiated recon= figuration with the corresponding behavior in DHCPv6.) as I don’t recall any such capability in DHCPv6? In DHCP= v6 a client can indicate whether it supports Reconfigure, but not which of = the Reconfigure messages (Renew, Rebind, or Information-Request).

 

And, an issue with #1 = is that you’d have to pick a message number to use as IANA won’= t have assigned a new one for the DHCPFORCEINFORENEW message (and that coul= d possible conflict if there was something else assigned in the interim, though I am not aware of anything.)

 

-     = ;     Bernie

 

From: Fang, Luyuan [mailto:lufang@ebay.com]
Sent: Friday, December 02, 2016 12:14 AM
To: Bernie Volz (volz) <volz@ci= sco.com>; dhcwg@ietf.org
Cc: draft-ietf-dhc-dhcpv4-forcerenew-extensions@ietf.org; Deepak Bansal (AZ= URE) <dbansal@microsoft.com= >; Fabio Chiussi <fabiochiu= ssi@gmail.com>
Subject: Re: WG meeting follow-up - Forcerenew Reconfiguration Exten= sions for DHCPv4

 

Hi Tomek and Bernie,

 

Thanks for presenting the draft in the last IETF and= bring this to dhc wg discussion. Sorry for the delayed response.

 

Yes, we still have strong interests to complete this= work. MSFT is working to implement it in Azure. We will report the results= when ready.

At the meantime, we’ll post a new version with= out content change.

 

Thanks,

Luyuan

 

From: "Bernie Volz (volz)" <volz@cisco.com>
Date: Wednesday, November 23, 2016 at 10:50 AM
To: "dhcwg@ietf.org"= <dhcwg@ietf.org>
Cc: "draft-ietf-dhc-dhcpv4-forcerenew-extensions@ietf.org"= ; <draft-ietf-dhc-dhcpv4-forcerenew-extensions@ietf.org>
Subject: WG meeting follow-up - Forcerenew Reconfiguration Extension= s for DHCPv4

 

Hi:

 

At the IETF-97 (Seoul) DHC WG meeting, Tomek had a brief presentation regarding draft-ietf-dhc-dhcpv4-forcerenew-e= xtensions (see https://www.ietf.org/proceedings/97/slides/slides-97-dhc-next-steps-for-dra= ft-ietf-dhc-dhcpv4-forcerenew-extensions-00.pdf).

 

This document has been inactive since WG adoption and has no= w expired. The co-chairs made several attempts to contact the authors, but = they were unresponsive. Tomek asked those in the room if there was any interest from someone to take on this w= ork. There was no interest expressed, but we want to take it to the WG mail= ing list to see if anyone has any interest.

 

If you do have interest in working on this, please contact t= he DHC WG chairs (dhc-chairs@ietf.or= g).

 

You can view the current (expired) draft at https://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-forcerenew-extensions-00<= /a>.

 

If there is no interest, the document will just be left as i= t is today (expired). Work on it can always be revived sometime in the futu= re if a need develops.

 

Thanks.

 

-     = ;     Tomek & Bernie

--_000_509D194F52D04E8B97C2C099201A59AFciscocom_-- From nobody Fri Feb 10 13:44:51 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFF9129C5A for ; Fri, 10 Feb 2017 13:44:49 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 Ovp17gq4jDwy for ; Fri, 10 Feb 2017 13:44:48 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [81.174.135.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FCE1294A9 for ; Fri, 10 Feb 2017 13:44:48 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <91[...] Received: from simons-macbookpro.lan (magpiehouse.plus.com [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 5DA0114366 for ; Fri, 10 Feb 2017 21:44:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com> Date: Fri, 10 Feb 2017 21:44:38 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6497B49C-AE2C-4C2E-9C13-B8E8764A64B7@thehobsons.co.uk> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457A A189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com> To: dhcwg X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:44:50 -0000 "Mudric, Dusan (Dusan)" wrote: > DHCPv6 is then very light weight: > - address assignment is not a part of the protocol, How do you come to that idea ? The primary function of DHCP is to = provide IP addresses. > - address selection is not part of the protocol, and Correct. The job of DHCP is to issue addresses - it can't know in = advance what any client might want to use it for. > - if the client, using its own logic to select from the offered = addresses (not part of the protocol), does not select some or any, the = protocol should not report that to the server, and There can be multiple servers, and no client is obliged to accept an = offer that doesn't meet it's requirements. For example, a VoIP phone = might be configured to only accept an offer which includes options to = configure the telephony aspects of the device. It's not that uncommon to have two servers on a network - one "general = IT" one, and one embedded in the PBX. The phones will only take leases = from the PBX, and the PBX will ignore clients other than the phones. The DHCP protocol specification cannot account for all such = eventualities. > - the fact that this kind of protocol can leave a device unreachable = does not matter to the protocol that assigns the address. "Doesn't matter" isn't the right way to describe it. That there are = cases where things won't work is inherent in any general purpose = protocol required to work in a flexible manner, with a wide range of = network topologies and clients, etc. From nobody Fri Feb 10 13:49:51 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4318E129C70 for ; Fri, 10 Feb 2017 13:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 HBmVyP9S-pp6 for ; Fri, 10 Feb 2017 13:49:49 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD3F129C5D for ; Fri, 10 Feb 2017 13:49:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HTAwAoNZ5Y/yYyC4deGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBCgWoHg1KcFpMngg+CDYYiAhqCYUAXAQIBAQEBAQEBA18ohGk?= =?us-ascii?q?BAQEBAgESERFFBQcEAgEIDQEDBAEBAQICBh0DAgICMBQBCAgCBA4FCBqJTggBp?= =?us-ascii?q?UWKYoIlJgKLJQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VChG6BPIMCGIMELoI?= =?us-ascii?q?xBZtyAZxphi+TFSECNX5PFYR7BR2BYXWJEgGBCwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2HTAwAoNZ5Y/yYyC4deGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?CgWoHg1KcFpMngg+CDYYiAhqCYUAXAQIBAQEBAQEBA18ohGkBAQEBAgESERFFB?= =?us-ascii?q?QcEAgEIDQEDBAEBAQICBh0DAgICMBQBCAgCBA4FCBqJTggBpUWKYoIlJgKLJQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VChG6BPIMCGIMELoIxBZtyAZxphi+TF?= =?us-ascii?q?SECNX5PFYR7BR2BYXWJEgGBCwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,142,1484024400"; d="scan'208";a="227608819" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Feb 2017 16:49:47 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2017 16:49:48 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 16:49:47 -0500 From: "Mudric, Dusan (Dusan)" To: Andre Kostur Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EAAKQI6AAB7vbSAAMyFpAABwmj1wAKS8ff4BSSOxkA== Date: Fri, 10 Feb 2017 21:49:45 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA1924E@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:49:50 -0000 VGhhbmtzIGZvciBhbnN3ZXJpbmcgdGhlc2UgcXVlc3Rpb24uIEkgdW5kZXJzdGFuZCB3aGF0IHRo ZSBwcm90b2NvbCBtYW5kYXRlIGlzIHNvIGZhci4NCg0KPj4gLSBhZGRyZXNzIGFzc2lnbm1lbnQg aXMgbm90IGEgcGFydCBvZiB0aGUgcHJvdG9jb2wsDQo+V2hlcmUgZGlkIHlvdSBnZXQgdGhpcyBp ZGVhIGZyb20/ICBESENQdjYgYXNzaWducyBhZGRyZXNzZXMgYWxsIGRheSBsb25nLiAgV2hhdCB0 aGUgY2xpZW50IGRvZXMgd2l0aCB0aGF0IGFzc2lnbm1lbnQgaXMgdXAgdG8gdGhlIGNsaWVudC4N CkkgbWVhbiB3aGljaCBhZGRyZXNzIGlzIGFzc2lnbmVkIGJ5IHRoZSBzZXJ2ZXIgaXMgbm90IHBh cnQgb2YgdGhlIHByb3RvY29sLiBUaGUgYWRtaW5pc3RyYXRvciAgZGVjaWRlcyB0aGF0Lg0KDQpU aGUgbGFzdCBxdWVzdGlvbjoNCklmIFJFQklORCBvZmZlcnMgYSBuZXcgYWRkcmVzcyBhbmQgdGhl IGNsaWVudCBkZWNpZGVzIG5vdCB0byB1c2UgaXQsIGRvZXMgdGhlIHNlcmVyIG5lZWQgdG8ga25v dyB0aGF0PyBTaG91bGQgdGhlIGNsaWVudCBzZW5kIERFQ0xJTkUgb3IgUkVMRUFTRT8NCg0KVGhh bmtzLA0KRHVzYW4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbmRyZSBL b3N0dXIgW21haWx0bzpha29zdHVyQGluY29nbml0by5jb21dIA0KU2VudDogRnJpZGF5LCBGZWJy dWFyeSAxMCwgMjAxNyA0OjM0IFBNDQpUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pDQpDYzogZGhj d2cNClN1YmplY3Q6IFJlOiBbZGhjd2ddIFJGQzMzMTUgREVDTElORSBkZWZpbml0aW9uDQoNCk9u IEZyaSwgRmViIDEwLCAyMDE3IGF0IDEyOjMwIFBNLCBNdWRyaWMsIER1c2FuIChEdXNhbikgPGRt dWRyaWNAYXZheWEuY29tPiB3cm90ZToNCj4gREhDUHY2IGlzIHRoZW4gdmVyeSBsaWdodCB3ZWln aHQ6DQoNCldlbGwuLiBJIHN1c3BlY3QgYSBidW5jaCBvZiB1cyBESENQIGltcGxlbWVudGVycyBt YXkgbm90IGFncmVlIHdpdGggdGhhdCBzdGF0ZW1lbnQuDQoNCj4gLSBhZGRyZXNzIGFzc2lnbm1l bnQgaXMgbm90IGEgcGFydCBvZiB0aGUgcHJvdG9jb2wsDQoNCldoZXJlIGRpZCB5b3UgZ2V0IHRo aXMgaWRlYSBmcm9tPyAgREhDUHY2IGFzc2lnbnMgYWRkcmVzc2VzIGFsbCBkYXkgbG9uZy4gIFdo YXQgdGhlIGNsaWVudCBkb2VzIHdpdGggdGhhdCBhc3NpZ25tZW50IGlzIHVwIHRvIHRoZSBjbGll bnQuDQoNCj4gLSBhZGRyZXNzIHNlbGVjdGlvbiBpcyBub3QgcGFydCBvZiB0aGUgcHJvdG9jb2ws IGFuZA0KDQpIb3cgdGhlIGNsaWVudCBzZWxlY3RzIHdoaWNoIGFkZHJlc3MgdG8gdXNlPyBOb3Bl LiAgVGhlIHByb3RvY29sIGRvZXNuJ3QgY2FyZSwgbm9yIHNob3VsZCBpdC4gIFRoZSBzZXJ2ZXIg ZGV0ZXJtaW5lcyB3aGF0IGl0cyB3aWxsaW5nIHRvIEFEVkVSVElTRSB0byB0aGUgY2xpZW50IGFu ZCBzZW5kcyBpdCBvZmYuICBUaGUgY2xpZW50IFJFUVVFU1RzIHdoYXQgaXQgd2FudHMuICBUaGUg c2VydmVyIFJFUExZcyB0byBjb21wbGV0ZSB0aGUgImNvbnRyYWN0IiB0aGF0IHRoZSBjbGllbnQg bWF5IHVzZSB0aG9zZSBhZGRyZXNzZXMgbmFtZWQgaW4gdGhlIFJFUExZIGZvciB0aGUgc3BlY2lm aWVkIFZhbGlkIExpZmV0aW1lLiAgVGhpcyBhbGxvd3MgZGlmZmVyZW50IGNsaWVudHMgdG8gY2hv b3NlIGRpZmZlcmVudCBtZXRob2RzIGZvciBzZWxlY3RpbmcgYW4gYWRkcmVzcy4NCg0KPiAtIGlm IHRoZSBjbGllbnQsIHVzaW5nIGl0cyBvd24gbG9naWMgdG8gc2VsZWN0IGZyb20gdGhlIG9mZmVy ZWQgDQo+IGFkZHJlc3NlcyAobm90IHBhcnQgb2YgdGhlIHByb3RvY29sKSwgZG9lcyBub3Qgc2Vs ZWN0IHNvbWUgb3IgYW55LCB0aGUgDQo+IHByb3RvY29sIHNob3VsZCBub3QgcmVwb3J0IHRoYXQg dG8gdGhlIHNlcnZlciwgYW5kDQoNCkl0IGRvZXMgbm90IGFwcGVhciB0aGF0IGFueWJvZHkgZWxz ZSBoZXJlIHVuZGVyc3RhbmRzIHdoeSB5b3Uga2VlcCBoYW1tZXJpbmcgb24gdGhpcyBwb2ludC4g IFlvdSBoYXZlIG5vdCBzYWlkIHdoeSB0aGlzIGlzIGEgcHJvYmxlbSBiZXlvbmQgIkkgd2FudCB0 byIuICBBIGNvbW1vbiBpbXBsZW1lbnRhdGlvbiBpcyB0aGF0IHRoZSBzZXJ2ZXIgaG9sZHMgYXNp ZGUgdGhlIEFEVkVSVElTRWQgYWRkcmVzc2VzIGZvciBhIHNob3J0IHdoaWxlIChtYXliZSBhIGZl dyBtaW51dGVzLCBtYXliZSAxMHMgb2Ygc2Vjb25kcywgaXRzIGFuIGltcGxlbWVudGF0aW9uIGRl dGFpbCkuICBJZiB0aGUgY2xpZW50IGRvZXNuJ3QgY29tZSBiYWNrIGFuZCBSRVFVRVNUIGl0LCB0 aGVuIHJlbGVhc2UgaXQgYmFjayB0byB0aGUgcG9vbC4NCkluIGFuIGFkZHJlc3Mgc3BhY2UgdGhh dCdzIDJeNjQgaW4gc2l6ZSwgd2hvIGNhcmVzIGlmIGEgaGFuZGZ1bCBvZiBhZGRyZXNzZXMgYXJl IGJlaW5nIGhlbGQgYXNpZGUgZm9yIGNsaWVudHMgdGhhdCBoYXZlIG5vdCB5ZXQgY29tZSB0byBS RVFVRVNUIHRoZW0uICBUaGlzIHdvcmtlZCBwZXJmZWN0bHkgZmluZSBldmVuIGluIHRoZSBJUHY0 IGNhc2VzIHdoZXJlIHRoZSBhZGRyZXNzIHNwYWNlIGlzIG11Y2ggc21hbGxlciAocG9zc2libHkg MTBzIG9mIGFkZHJlc3NlcykuDQoNCj4gLSB0aGUgZmFjdCB0aGF0IHRoaXMga2luZCBvZiBwcm90 b2NvbCBjYW4gbGVhdmUgYSBkZXZpY2UgdW5yZWFjaGFibGUgZG9lcyBub3QgbWF0dGVyIHRvIHRo ZSBwcm90b2NvbCB0aGF0IGFzc2lnbnMgdGhlIGFkZHJlc3MuDQoNCk5vcGUuICBBbmQgdGhlIGFk bWluIG1heSBiZSBpbnRlbnRpb25hbGx5IGRvaW5nIHNvLiAgTm90IGZvciB0aGUgcHJvdG9jb2wg dG8gZGVjaWRlLg0KDQo+IERpZCBJIGdldCBpdCBjb3JyZWN0bHk/DQoNCk5vLg0KDQoNCkkgaGF2 ZSB0byBhc2s6IHdoYXQncyB0aGUgbW90aXZhdGlvbiBiZWhpbmQgYXNraW5nIHRoZXNlIHF1ZXN0 aW9ucz8NClRoZXJlIHNlZW1zIHRvIGJlIGEgbW9yZSBmdW5kYW1lbnRhbCBtaXN1bmRlcnN0YW5k aW5nIHVuZGVybHlpbmcgdGhpcyBsaW5lIG9mIHF1ZXN0aW9uaW5nLg0KDQotLQ0KQW5kcmUgS29z dHVyDQo= From nobody Fri Feb 10 13:58:55 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5459E129DF2 for ; Fri, 10 Feb 2017 13:58:54 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=incognito-com.20150623.gappssmtp.com 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 nlnd7rn6goQy for ; Fri, 10 Feb 2017 13:58:53 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10DB129DD4 for ; Fri, 10 Feb 2017 13:58:52 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id j82so15505726ybg.1 for ; Fri, 10 Feb 2017 13:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=incognito-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6Q+U1J8jrVyJSJr6kmqPv3mdZXCOR3fybpPCzVKYe2k=; b=2Qpi1OR+J1ooyBNE/mnBrjckEy2KYC71NO+evdQapD9VlimoC1FI4gZJsIvf6FjNbz DPAAHqJ/kD5gl5Bh+tU/+AMHs/6tMQmbvSsapN96FYtPRJMafehX1rmu2fe5JnWjo+Qx vd8gr2BQ02te+CBQtbxwDkgFptJhYAVfKDHKnR/o0Rl0ZqHjrs/MeI/Y+DUGCpCZJFVr 5TmsjSWixzsm7FTpug8ZCA5f0n2z9prvov8b3qrKVfEjToKdWbNhHQeb+7ltBRSZUYRe +KieiM3iCTlWM0yYg++9hKCLfcRo+R75mGWyuzR+x6a4YaRkPpFMXD98aTaR/oGOPtid xAvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6Q+U1J8jrVyJSJr6kmqPv3mdZXCOR3fybpPCzVKYe2k=; b=Atr+TowdXhO/6vl/9cebjDH6tGxyXvYeXVosDqIHZLaXeNE5zFgUwef8E2LsfQNdVc tTKqw34hOSvFqLV3iDTXbKI+4TVPzxXsUlpx1c7Jdfpxtcu/AvPw4Y1V7J/HTKZJmFl4 xpgSvHXdoUS+gYzY7N++JK0EcWaSVPHcYHO2lsj32J3ufFGIN1BODizZZDPO2ZV88r8y IjGlBy+tetRRX67nKPPCpmHTZ4v+qhJyZ4+JuvZwyfKLWT5L8A9VTbvwNCstsoCz+IMp UtsyIoN6f41YqkNPWQ9GxuLQkWaRaxr+wf4biIlRciHtFCJJ7UIF7DoFGz04ZifHtjQN bnhg== X-Gm-Message-State: AMke39mmxM1zuzlb1D1SK1PORGtamIQopwN6HF6xNertwlB8q6lb61WA3yBaOhdAKij/iEuExQP4j587kPL1+0i1 X-Received: by 10.37.161.2 with SMTP id z2mr7750116ybh.50.1486763931951; Fri, 10 Feb 2017 13:58:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.113.5 with HTTP; Fri, 10 Feb 2017 13:58:51 -0800 (PST) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA1924E@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1924E@AZ-US1EXMB03.global.avaya.com> From: Andre Kostur Date: Fri, 10 Feb 2017 13:58:51 -0800 Message-ID: To: "Mudric, Dusan (Dusan)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:58:54 -0000 On Fri, Feb 10, 2017 at 1:49 PM, Mudric, Dusan (Dusan) wrote: > The last question: > If REBIND offers a new address and the client decides not to use it, does the serer need to know that? Should the client send DECLINE or RELEASE? That depends. Did the client detect that the new address is in use by another node? DECLINE (s18.1.7). Otherwise, RELEASE (s18.1.6). -- Andre Kostur From nobody Fri Feb 10 14:47:06 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E9F129F2F for ; Fri, 10 Feb 2017 14:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 89PzRFBQnkAS for ; Fri, 10 Feb 2017 14:47:02 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504D9129F2D for ; Fri, 10 Feb 2017 14:47:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1AMl16b053257; Fri, 10 Feb 2017 15:47:01 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1AMkx3w053226 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 10 Feb 2017 15:46:59 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 10 Feb 2017 14:46:58 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 10 Feb 2017 14:46:58 -0800 From: "Templin, Fred L" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , Lishan Li Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSglOjbTsgor1qYk63PeyrUa0poqFi1e9w Date: Fri, 10 Feb 2017 22:46:58 +0000 Message-ID: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 22:47:05 -0000 Hi, I have not reviewed this latest version of the draft but in my understa= nding from past discussions is that this mechanism always encrypts and there is n= o longer an "authentication-only" mode. That being the case, if this work is = to go forward the WG must first resurrect the Relay Agent Assignment Notification (RAAN) draft: https://www.ietf.org/mail-archive/web/dhcwg/current/msg17651.html Otherwise, sedhcpv6 would be incompatible with Relays that must glean route information during DHCPv6 PD exchanges. Chairs - what do we need to do to make RAAN a working group item? Thanks - Fred > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of ???? > Sent: Wednesday, February 08, 2017 1:38 PM > To: Lishan Li > Cc: dhcwg > Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sed= hcpv6-20.txt >=20 > At Mon, 16 Jan 2017 17:10:26 +0800, > Lishan Li wrote: >=20 > > We have submitted a new version of secure DHCPv6. Thanks a lot for Bern= ie's > > valuable comment. >=20 > I apologize for having been inactive on this draft, especially despite > being listed as a coauthor. I've finally found time to take a closer > look at it. I see the 20 version has been improved a lot; it's much > more readable than (some of the) older versions and many of the > technical questions I raised before seem to be addressed. I > personally think we still need to discuss and address some more > technical details, but IMO this version is now much closer to WGLC. >=20 > ...with one big reservation: I'd very much like to see at least one > attempt of implementing the spec. This is a quite complicated > protocol specification, and no matter how hard we review the paper > spec, I'm quite sure that an actual implementation attempt will find > many more unclear points or protocol defects. Although I understand > that's not a requirement for a WGLC or even for an RFC (the spirit of > "believing in running code" has been the thing of past at the IETF, > sadly) but I still hope we won't end up shipping a protocol spec with > full of defects mainly because there is not even an attempt of > implementing it before publishing it. >=20 > Specific comments on the 20 version follow. There is one thing that I > guess needs broader attention, so I'm noting it here: I think we need > more discussion on the meaning and justification of "Non-SigAlg" and > "Non-EncryAlg" (especially the latter). See below for more details. >=20 > - general: it's still not clear to me how we use this mechanism for > Reconfigure. >=20 > - Section 1 >=20 > [...] Such communications are already protected using the > mechanism described in section 21.1 in [RFC3315]. >=20 > Perhaps a better reference today would be > draft-ietf-dhc-relay-server-security. >=20 > - Section 1 >=20 > [...] The > Algorithm, Certificate, Signature, and Increasing-number options are > used for authentication. The Encryption-Query message, Encryption- > Response message, Encrypted-message option and Encryption-Key-Tag > option are used for encryption. >=20 > I suspect this is not 100% accurate. Except for the signature > option, everything can also be used for (or related to) encryption. >=20 > - Section 5.3 >=20 > [...] The same client and server SHOULD use the > same algorithm in a single communication session. >=20 > Shouldn't this be a MUST? Especially now that the client and the > server negotiate and fix a specific set of algorithms initially, I > don't see any possibility for an exception to this requirement. >=20 > - Section 5.3 >=20 > The sender can > offer a set of algorithms, and then the receiver selects one > algorithm for the future communication. >=20 > s/sender/client/ and s/receiver/server/. Only the client offers an > algorithm set using the algorithm option. >=20 > - Section 5.5: s/The One/One/ >=20 > The One feasible environment in > an early deployment stage would be enterprise networks. >=20 > - Section 5.5 >=20 > In > enterprise networks, the client is manually pre-configured with the > trusted servers' public key and the server is also manually pre- > configured with the trusted clients' public keys. >=20 > I suggest s/is (also) manually/can (also) be manually/ since manual > configuration wouldn't be the absolute only option. >=20 > - Section 6 >=20 > And then the client first checks acknowledged hash, signature and > encryption algorithms that the server supports. If the hash > algorithm field is zero, then it indicates that the hash algorithm is > fixed according to the corresponding signature algorithm. The client > also uses the acknowledged algorithms in the return messages. >=20 > It's not clear to me from this text how the client checks the > algorithms. By examining the certification option for the > signature/encryption algorithms and examining the signature option > for the hash ID? If so, I think it should be clearly described. >=20 > I'd note that the signature ID in the certificate must be equal to > the signature ID of the signature option. And, generalizing this, > what if the client doesn't support these algorithms? (This shouldn't > happen as long as the server handles the algorithm option correctly, > so this is basically a bug of the server implementation). >=20 > The description of zero hash algorithm field seems to suggest the > signature and hash algorithms are tightly related in practice. So > it may be better to define the algorithm option so that > signature/hash algorithms are listed as pairs. >=20 > - Section 6: s/return/subsequent/ >=20 > [...] The client > also uses the acknowledged algorithms in the return messages. >=20 > - Section 6 >=20 > The first DHCPv6 message sent from the client to the server, such as > Solicit message, MUST contain the Certificate option, Signature > option and Increasing-number option for client authentication.[...] > [...] One and only one Increasing-number option SHOULD be > contained, >=20 > Isn't there a MUST vs SHOULD conflict here? >=20 > - Section 6 >=20 > [...] In this document, it is assumed > that the client uses only one certificate for the encrypted DHCPv6 > configuration. So, the corresponding private key is used for > decryption. >=20 > I'm not sure if this is okay. And, in fact, Section 11 talks about > a case where multiple key pairs (so multiple certificates) are used: >=20 > If the client tries more than one cert for client authentication, the > server can easily get a client that implements this to enumerate its > entire cert list and probably learn a lot about a client that way. >=20 > Perhaps this is intended to handle encrypted Reconfigure? If that's > the only reason for this limitation, I think we should address the > reconfigure case in some other way and keep the general specification > more flexible. >=20 > - Section 7 >=20 > [...] If it is the target server, according to > the Encryption-Key-Tag option, the server identifies the used public/ > private key pair and decrypts the Encrypted-message option using the > corresponding private key. >=20 > The key tag is not necessarily unique for different public keys (so > different key pairs), even if it should normally be unique in > practice. If multiple public keys share the same tag value, the > server MUST try all corresponding key pairs. >=20 > Also, since the key tag option isn't covered by a signature, it may > have been forged by an intermediate attacker. We may want to > describe what the server should do in such a case (just discarding > it is probably okay as it's forged anyway, but the server could also > try all possible keys just in case the key tag is the only forged > field). >=20 > - Section 7 >=20 > The server validates the client's certificate through the local pre- > configured trusted certificates list. >=20 > I'm not sure if this paragraph covers the "opportunistic encryption" > mode, i.e, when the server doesn't know the certificate but chooses > to use it for encryption only. (I'm assuming our intent is to > support such mode, right?). >=20 > - Section 7 >=20 > To provide > the replay protection, the Increasing-number option can be contained > in the encrypted DHCPv6 message. >=20 > Shouldn't this be either SHOULD or MUST to be consistent with other > part of this spec? (see also the possible SHOULD vs MUST conflict > commented above). >=20 > - Section 9.1 >=20 > [...] And the client can forget the increasing number > information after the transaction is finished. The client's initial > locally stored increasing number is set to zero. >=20 > I'm not sure if I understand it and I'm not sure if it's okay > whatever it means...does this mean the server can (or always does?) > reset the increasing number to 0 for messages it sends to the server > at the beginning of a new DHCPv6 session? Doesn't it lead to an > easy replay attack? Or is the assumption that the server first > sends an error and the client will resend the message with an > adjusted increasing number? >=20 > - Section 10.1.1 >=20 > The mandatory encryption > algorithms MUST be included. >=20 > Which algorithm is it? >=20 > - Section 10.1.2 >=20 > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | EA-id | SA-id | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . Certificate . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > This seems to assume a single certificate (which I assume means a > single public key) can be used for both encryption and signature. > Is my understanding correct? If so, can we always assume that? >=20 > - Section 10.1.2 >=20 > It should be noticed that the scenario where the values of EA-id and > SA-id are both 0 makes no sense and the client MUST discard a message > with such values. >=20 > The 0 EA-id/SA-id values are not described earlier in this > document. I think it should explicitly define its semantics before > this text (perhaps in Section 10.1.1). >=20 > And, from the description of Section 12: >=20 > Non-SigAlg | 0x00 | this document > Non-EncryAlg | 0x00 | this document >=20 > I guess it means the signature is (effectively) not provided and the > message is (effectively) not encrypted, respectively. If my > understanding is correct, is it okay to allow that, especially about > encryption? I vaguely recall a discussion about someone hoping to > introduce a non-encryption mode, but I thought we rejected the idea > because it would be against the "always encrypt" consensus. >=20 > - Section 10.1.5 >=20 > encryption key tag A variable length field containing the encryption > key tag sent from the client to server to identify the used > public/private key pair. The encryption key tag is calculated > from the public key data, like fingerprint of a specific public > key. How to generate the encryption key tag adopts the method > define in Appendix B in [RFC4034] and section 5.5 in [RFC6840]. > The data of the public key is used as input of the generation > function. >=20 > If we derive the tag calculation from RFC4034, the length is not > variable: it's fixed to 16 bits. >=20 > Also, I don't think we have to mention RFC6840 section 5.5. We'd > only use the method described in Appendix B of RFC4034 for > algorithms other than type 1. >=20 > And, although it may be quite straightforward, I don't think this > description is enough to actually calculate the tag value for a > given public key. We should provide some more specific here. >=20 > - Section 11 >=20 > [RFC6273] has analyzed possible threats to the hash algorithms used > in SEND. Since Secure DHCPv6 defined in this document uses the same > hash algorithms in similar way to SEND, analysis results could be > applied as well: [...] >=20 > Does this matter even when the hash value is in an encrypted > message? >=20 > - Section 11 >=20 > I think we should also discuss a few more security issues in this > section: > - Since the algorithm option isn't protected by a signature, the > list can be forged without detection, which can lead to a > downgrade attack. > - Likewise, since the Encryption-Key-Tag Option isn't protected, an > attacker that can intercept the message can forge the value > without detection (see also the relevant comment on Section 7). >=20 > - Section 12 >=20 > Hash Algorithm for Secure DHCPv6. The values in this table are 8-bit > unsigned integers. >=20 > Shouldn't this be 16-bit? It's defined as an 16-bit value for the > HA-id field of various options. Same for the signature algorithm > and encryption algorithm. >=20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Sat Feb 11 08:12:23 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879FB12995F for ; Sat, 11 Feb 2017 08:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 N8WPlIv6PYUC for ; Sat, 11 Feb 2017 08:12:19 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFB212995D for ; Sat, 11 Feb 2017 08:12:19 -0800 (PST) X-AuditID: c1b4fb30-b99fe70000007389-6a-589f37df883d Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id C6.5B.29577.FD73F985; Sat, 11 Feb 2017 17:12:17 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 11 Feb 2017 17:12:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D8Pl6xmRUhtiHx9pAiD++5nBI/KehMesIEoMGb/T7kA=; b=moQaG+GT9TdMLInpxgtdb6mVbcKUGgrTTICI7+NlKTief0rMWDEaONJOs/pzaKI9t+2P+hPYg8quHnvo2fXvqbrhx1E/OoCNui+D/1OVJ4A7jXOUQvfrqum4uaql3u5+faOttRPYF6yVJavC7pCKqkA5W2srArN6Xl9dbtI7tzY= Received: from VI1PR0701MB1920.eurprd07.prod.outlook.com (10.167.209.20) by HE1PR07MB0988.eurprd07.prod.outlook.com (10.162.27.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Sat, 11 Feb 2017 16:12:13 +0000 Received: from VI1PR0701MB1920.eurprd07.prod.outlook.com ([10.167.209.20]) by VI1PR0701MB1920.eurprd07.prod.outlook.com ([10.167.209.20]) with mapi id 15.01.0888.029; Sat, 11 Feb 2017 16:12:10 +0000 From: Srinivasa Rao Nalluri To: "dhcwg@ietf.org" Thread-Topic: New Version Notification for draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt Thread-Index: AQHShH+xed7omrhlUk+o8l+2EDxk2KFj9oiQ Date: Sat, 11 Feb 2017 16:12:10 +0000 Message-ID: References: <148682868951.11037.15038580652851094524.idtracker@ietfa.amsl.com> In-Reply-To: <148682868951.11037.15038580652851094524.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=srinivasa.rao.nalluri@ericsson.com; x-originating-ip: [203.212.244.141] x-ld-processed: 92e84ceb-fbfd-47ab-be52-080c6b87953f,ExtAddr x-microsoft-exchange-diagnostics: 1; HE1PR07MB0988; 7:AIUYQ8z0pEepnbDSmHL6JpQE1M3+ih5qfzvoWx8rLTC/0plyouKZTkoYbiCB38Ax1aZhzRnrQd0gE4ExWLRJmiNf8AYyzsi/MW8miJFuLKmr3RO0snckdpNM4dt6zn97sDw7AKtiKSlL7cSACJ+K6hYs0XrfgfDvZWOiAs48SxC3u1SNuu3hOB4tu6yrxgZMnghBE73abj6ssUCnMiHqbWzXHpOs63N5vPUNbQP/Lemy0zBgcliEIeyKTSA0hbuSFNJ3cA2jCjwjieiYscU7gd1dPBVRhrwVN/he7Wz16+wDBlzSEW+lVVEE1mycVeiDVDg0XgV4AkkyaKoKLFbJbRKwCJGHbVnDxZd2tFFxy0SvLsAfur6L2nnnCpHQySZ2GHKI1urpItQFGFp1Ahtspnxaa36yyJ7AynvnoDYNj6It5z/f2KOfWgYoPesG7ZG92hxQoq/fKWNjHNcSz+RjUEWzUxzObYfOXseSjwvRIKp8US48LW6tqG6jkULVlruS68ECaxI/XOSZLkNx6E1urg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(13464003)(189002)(377424004)(199003)(107886003)(53936002)(81156014)(8676002)(2900100001)(3660700001)(110136004)(38730400002)(1730700003)(8936002)(2351001)(97736004)(189998001)(54356999)(81166006)(9686003)(66066001)(33656002)(3846002)(2501003)(6116002)(102836003)(74316002)(50986999)(2473003)(105586002)(99286003)(106356001)(55016002)(6306002)(7736002)(305945005)(5640700003)(92566002)(106116001)(25786008)(7696004)(86362001)(15650500001)(6436002)(76176999)(2906002)(4326007)(77096006)(6506006)(230783001)(229853002)(6916009)(122556002)(450100001)(68736007)(3280700002)(5660300001)(101416001)(2950100002)(54906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0988; H:VI1PR0701MB1920.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: a8169a0d-39d0-4aa7-6354-08d45298bc00 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR07MB0988; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:HE1PR07MB0988; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0988; x-forefront-prvs: 0215D7173F received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2017 16:12:10.7049 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0988 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SXUiTURjHOXtft9fp4DS1PZo3LaRM0jlCi8QMvOii0q4aJuVyLzrUOfbO oV6ExiSdWebHmlumFyszS6XMLyzdyM8EnZiFESIaZs2PktCVSNveCd39nvP/Pec8DxyKELrI MEqp0tIalTxXzOWTDbKeyycW45tkEr0t5NSXcj1KQuetVhcnFaXxExR0rlJHa2ISM/jZY4vJ 6uqgwm/zQ0QJmhYaEEUBPgmljkAD4lNC3I6g/ruVyxZjCNZreglPQeIqAvq6dvwMyN+dGDnw U5/IWhMIll6/5XkCLk4Co/Er18PBOAJabbU8j0TgSQSjuwscTxCEM8Gw8dEnKaDjySOCZSnU jpi8Duludq2NEZ75BDgDLNNx7MOXoKZ00Kv74xRod254GeGDsD3x3NtKYBHMLzd5GTAG68AU wXIIrC7t+bE+DZbRT77zI1B3f4VkOQFMlQ+8GwOeJGGkopFki3kujN+e4LLWRXjvaiH2udYx h1jOAX13g8+5ACW2H76bzBwY2pnxSeFQ1jxHsOvQ0PKiDFWjKPN/k5vdSxM4Ejr6Y9jjw1BX ucjzsAAfgPGGZbIZkc9QCEMzN/KypNJoWqPMZJh8VbSK1r5E7g9h6/or6UWrK+fsCFNIHChQ f2iUCf3kOqYoz46AIsTBgk1Jk0woUMiLimlN/nVNQS7N2NEhihSLBHGtC1eEOEuupXNoWk1r 9lMO5R9WgnSFn9NrhuvfdIQWOMfbyzslD4/NhJ6OsqwNSM84783SsY+HR4t+/e7s3nbO3pUp 9VSP6VbApog3KTq7PZUXvps8GKneFUaYq/puOhrjc66+Qm3rnfYt49wd2ty2F5BOabkpR0vD /qQ7TNb+0C0dL9M2LSquSL1mSXv6rlDRIiaZbHnscULDyP8BCSlF1gwDAAA= Archived-At: Cc: Amit Gupta X , Jan Melen , =?utf-8?B?QXJpIEtlcsOkbmVu?= , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= Subject: [dhcwg] FW: New Version Notification for draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 16:12:21 -0000 SGksDQoNCk5ldyB2ZXJzaW9uIHVwbG9hZGVkLiANCg0KQ29tbWVudHMgZnJvbSBCZXJuaWUgVm9s eiBhZGRyZXNzZWQgaW4gdGhpcyBuZXcgdmVyc2lvbi4NCg0KV2l0aCBSZWdhcmRzDQpTcmluaXZh cw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFNhdHVyZGF5 LCBGZWJydWFyeSAxMSwgMjAxNyA5OjI4IFBNDQpUbzogU3Jpbml2YXNhIFJhbyBOYWxsdXJpOyBT cmluaXZhc2EgUmFvIE5hbGx1cmkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtbmFsbHVyaS1kaGMtZGhjcHY2LWx3bTJtLWJvb3RzdHJhcC1vcHRpb25zLTAyLnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1uYWxsdXJpLWRoYy1kaGNwdjYtbHdt Mm0tYm9vdHN0cmFwLW9wdGlvbnMtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFNyaW5pdmFzIFJhbyBOYWxsdXJpIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZToJCWRyYWZ0LW5hbGx1cmktZGhjLWRoY3B2Ni1sd20ybS1ib290c3RyYXAt b3B0aW9ucw0KUmV2aXNpb246CTAyDQpUaXRsZToJCURIQ1B2NiBPcHRpb25zIGZvciBMV00yTSBi b290c3RyYXAgaW5mb3JtYXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTctMDItMTENCkdyb3VwOgkJ SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTkNClVSTDogICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbmFsbHVyaS1kaGMtZGhjcHY2LWx3 bTJtLWJvb3RzdHJhcC1vcHRpb25zLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW5hbGx1cmktZGhjLWRoY3B2Ni1sd20ybS1ib290 c3RyYXAtb3B0aW9ucy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbmFsbHVyaS1kaGMtZGhjcHY2LWx3bTJtLWJvb3RzdHJhcC1vcHRpb25zLTAyDQpE aWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW5h bGx1cmktZGhjLWRoY3B2Ni1sd20ybS1ib290c3RyYXAtb3B0aW9ucy0wMg0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90 b2NvbCBhbmQgRHluYW1pYw0KICAgSG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIHZlcnNpb24g NiAoREhDUHY2KSBPcHRpb25zIGZvciBMV00yTQ0KICAgY2xpZW50IGJvb3RzdHJhcCBpbmZvcm1h dGlvbiwgd2hpY2ggYXJlIHVzZWQgdG8gY2FycnkgVW5pZm9ybQ0KICAgUmVzb3VyY2UgTG9jYXRl ciBvZiBMV00yTSBib290c3RyYXAgc2VydmVyIGFuZCBjZXJ0aWZpY2F0ZSB0aGF0DQogICB2YWxp ZGF0ZXMgdGhlIHB1YmxpYyBrZXkgcHJlc2VudGVkIGJ5IHNlcnZlci4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Feb 13 06:02:53 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFCF1295A1 for ; Mon, 13 Feb 2017 06:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 PCEYkwnWe5Dw for ; Mon, 13 Feb 2017 06:02:51 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80BA129535 for ; Mon, 13 Feb 2017 06:02:50 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HlAgA0vKFY/xUHmMZeGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBCgXGDUq86gg+CDIYiAhqCTUAXAQIBAQEBAQEBA18ohGoCAQM?= =?us-ascii?q?SERFVAgEIDQ0CBiACAgIwFRACBAEaGolIAaNGimKCJSYCixsBAQEBAQUBAQEBA?= =?us-ascii?q?QEBASCBC4VChG6BPIMCGIMELoIxBZtyAZxphi+TFSABN4EAURWHAIhoK4EDAYE?= =?us-ascii?q?LAQEB?= X-IPAS-Result: =?us-ascii?q?A2HlAgA0vKFY/xUHmMZeGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?CgXGDUq86gg+CDIYiAhqCTUAXAQIBAQEBAQEBA18ohGoCAQMSERFVAgEIDQ0CB?= =?us-ascii?q?iACAgIwFRACBAEaGolIAaNGimKCJSYCixsBAQEBAQUBAQEBAQEBASCBC4VChG6?= =?us-ascii?q?BPIMCGIMELoIxBZtyAZxphi+TFSABN4EAURWHAIhoK4EDAYELAQEB?= X-IronPort-AV: E=Sophos;i="5.35,156,1484024400"; d="scan'208";a="227791568" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Feb 2017 09:02:23 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Feb 2017 09:02:23 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0319.002; Mon, 13 Feb 2017 09:02:23 -0500 From: "Mudric, Dusan (Dusan)" To: dhcp-users , dhcwg Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EAAKQI6AAB7vbSAAMyFpAABwmj1wAKS8ff4BSSOxkAKHSe+ABJNGvAA= Date: Mon, 13 Feb 2017 14:02:22 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA194E5@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1924E@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 14:02:52 -0000 VGhhbmtzIHRvIERIQ1dHIGdyb3VwIGZvciB0aGVpciBjb21tZW50cy4gSSBiZWxpZXZlIHRoZSBw cm9wb3NhbHMgd291bGQgYmVuZWZpdCBESEN2NiB1c2Vycy4NCg0KRm9yIHRoZSByZWNvcmQ6DQoN ClBST0JMRU0gU1RBVEVNRU5UUzoNCi0gQSBuZXR3b3JrIG9wZXJhdG9yIGNhbiBzZXQgY2xpZW50 IElQdjYgYWRkcmVzc2VzIG9uIERIQ1B2NiBzZXJ2ZXIuIEFuIGFkZHJlc3MgY2FuIGJlIGludmFs aWQgb3IgbWFrZSBhIGNsaWVudCB1bnJlYWNoYWJsZS4NCi0gQSBuZXR3b3JrIG9wZXJhdG9yIGNh biBjaGFuZ2UgYW4gYWRkcmVzcyBwcmVmaXggb24gYSByb3V0ZXIuIEEgY2xpZW50IGFkZHJlc3Mg Y2FuIGJlY29tZSB1bnJlYWNoYWJsZQ0KLSBBIGRlZmF1bHQgcm91dGVyIG9mZmVyaW5nIGEgcHJl Zml4IHRvIGEgY2xpZW50IGNhbiBiZWNvbWUgdW5yZWFjaGFibGUuIEEgY2xpZW50IGFkZHJlc3Mg Y2FuIGJlY29tZSB1bnJlYWNoYWJsZSBvbiBhIGxvY2FsIGxpbmsgDQotIEEgY2xpZW50IGRvZXMg bm90IHJlbGVhc2UgdW51c2VkIGFkZHJlc3Nlcw0KDQpQUk9QT1NFRCBGQUlMVVJFIElORElDQVRJ T05TDQotIEEgY2xpZW50IHZhbGlkYXRlcyB0aGUgYWRkcmVzc2VzIGFuZCB0aGUgYWRkcmVzcyBw cmVmaXhlcyBhbmQgbm90aWZpZXMgREhDUHY2IHNlcnZlciBhYm91dCB0aGUgcHJvYmxlbXMNCi0g QSBjbGllbnQgcmV0dXJucyB1bnVzZWQgYWRkcmVzc2VzDQotIERIQ1B2NiBzZXJ2ZXI6DQogIC0t IGxvZ3MgZXJyb3IgbWVzc2FnZXMgKGludmFsaWQgJiB1bnJlYWNoYWJsZSBhZGRyZXNzZXMgd2l0 aCBkZXZpY2UgSURzKQ0KICAtLSBkb2VzIG5vdCBhc3NpZ24gdGhlIGludmFsaWQgYWRkcmVzc2Vz DQogIC0tIHBlcmlvZGljYWxseSBjaGVja3MgZm9yIHRoZSByZWFjaGFiaWxpdHkgb2YgdW5yZWFj aGFibGUgYWRkcmVzc2VzIGFuZCwgd2hlbiB0aGV5IGJlY29tZSByZWFjaGFibGUsIGFzc2lnbnMg dGhlbSBhZ2Fpbg0KLSBBbiBvcGVyYXRvcg0KIC0tIGNoZWNrcyBpZiB0aGVyZSBhcmUgdW5yZWFj aGFibGUgZGV2aWNlcyBhbmQgdGhlIHJlYXNvbiBjb2Rlcw0K From nobody Mon Feb 13 06:57:27 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD244129698 for ; Mon, 13 Feb 2017 06:57:26 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 AOtMfhxjhaXU for ; Mon, 13 Feb 2017 06:57:24 -0800 (PST) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [81.174.135.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664071295B2 for ; Mon, 13 Feb 2017 06:57:24 -0800 (PST) X-Quarantine-ID: <9OcAHIiNVQx9> X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <91[...] Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 8CE701BC91 for ; Mon, 13 Feb 2017 14:57:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA194E5@AZ-US1EXMB03.global.avaya.com> Date: Mon, 13 Feb 2017 14:57:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457A A189F9@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA1924E@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA194E5@AZ-US1EXMB03.global.avaya.com> To: dhcwg X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 14:57:27 -0000 "Mudric, Dusan (Dusan)" wrote: > PROBLEM STATEMENTS: > - A network operator can set client IPv6 addresses on DHCPv6 server. That is the primary function of the DHCP server ! I don't see that as a = problem. > An address can be invalid or make a client unreachable. There are a lot of other ways to bo**ox up a network ! Such configurations may be deliberate. Until recently I did in fact run = a network with unroutable (as in valid IP, but no router for that = subnet) addresses because there was a policy decision that this = particular network would be isolated - it was a backend network to carry = traffic independently of the traffic on the public facing front end = network. > - A network operator can change an address prefix on a router. A = client address can become unreachable Ditto. This is simply failing to co-ordinate network changes. Before = removing/changing the prefix, the DHCP admin should have removed the = pool IFF it is desired that the addresses be usable for external = connectivity. As previously mentioned, this may be deliberate on the = part of the Admin. > - A default router offering a prefix to a client can become = unreachable. "Sh*t happens". Not only that, but what happens if the server hands out = a load of IPv6 addresses which are all valid AT THE TIME OF ALLOCATION ? = Even if your proposal were implemented, these addresses would be = accepted and configured because they would be valid AT THE TIME OF = ALLOCATION. The DHCP server and client cannot do anything about it if, = say, 5 seconds into a 60 day lease, a router stops advertising a prefix = appropriate to that address. It would be for the OS to detect that situation, and simply stop using = that address for outbound connections. IMO it would be inappropriate for = all the clients to somehow tell the server that all these addresses are = bad - only to have 20,000 clients all contact the server again a few = minutes later when the router comes back up and the prefix becomes valid = again. That would be designing in network instability. > A client address can become unreachable on a local link=20 ? > - A client does not release unused addresses So ? There's 2^64 addresses in a minimal IPv6 prefix. How many billion = addresses do you intend using for each client ? Even if your 20,000 = clients all took and held onto 1000 addresses each, that's still a tiny = tiny fraction of the available addresses. > - A client validates the addresses and the address prefixes and = notifies DHCPv6 server about the problems HOW ? You will need to define the algorithm for validating addresses. So far = you've only come up with "isn't on any prefix advertised by a router" = (as above, not a valid test) and "in a deprecated prefix" (as mentioned = in an earlier message, not a valid test). You will also need to define a mechanism whereby all clients can have = the algorithm updated as policies change - eg prefixes get deprecated = (as previously discussed), new prefixes come into use (eg I assume you = would expect currently unused prefixes to be rejected, but they could = come into use at any time when it's considered that they are needed). You will also need to define a mechanism for the local admins to = over-ride the stock algorithm - eg where the admins have made a policy = decision to run isolated networks. This introduces a catch-22 situation = where new devices might not be configurable (they won't attach to the = network) until they have been configured (policy edited to allow them to = connect). This is critical to your proposal - until you can come up with an easily = defined, and robust, algorithm then your proposal CANNOT work. Worse, it = may cause far more problems than it is supposed to solve. > - A client returns unused addresses > - DHCPv6 server: > -- logs error messages (invalid & unreachable addresses with device = IDs) > -- does not assign the invalid addresses > -- periodically checks for the reachability of unreachable addresses = and, when they become reachable, assigns them again Define "valid" and "reachable" here ? The implication from this and your earlier emails is that you define = "reachable" as "has an IP which is routable to/from 'the internet'". See = my comment above about running isolated networks, that backend isolated = network runs a DHCP service - so the addresses on it are "reachable" in = terms of "the DHCP server can reach them", but they aren't globally = routable (they are actually RFC1918 IPv4 addresses, but the argument = stands). With a previous hat on, I had 2 Class C public IPv4 allocations which = weren't globally routable. There is also the issue that the server (in the general case) CANNOT = determine the reachability/routability of any prefix. There are plenty = of network topologies where the server may lose connectivity to = "something" while clients don't, or vice-versa, while connectivity = between server and client network is still working. Similarly, there are = topologies while server-client comms could be lost, while both still = have connectivity to "something". This is the reason that, out of the = box, DHCP4 servers in failover do NOT automatically go into partner-down = state when they lose connectivity between them. > - An operator > -- checks if there are unreachable devices and the reason codes An alternative: The site/organisation admins take care to co-ordinate = changes, and test changes in configuration. They should employ = monitoring to detect issues, and respond appropriately to helpdesk = tickets. Configuration management (and especially automation) will detect many of = the issues you've raised. From nobody Mon Feb 13 07:28:49 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652031296BE for ; Mon, 13 Feb 2017 07:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UW1jQEAqV-Us for ; Mon, 13 Feb 2017 07:28:43 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9E312961D for ; Mon, 13 Feb 2017 07:28:43 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id x49so85958947qtc.2 for ; Mon, 13 Feb 2017 07:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f+e2TQVy5SYt2oBLsNMtcBwLBsomTLkP+UWIMsebEi4=; b=uSXdW+6D20TeV1DHeX9bs+It9dhp66BeX9/HS3gC9clhK8IPmwt9ObFNvJe6I54Ct2 Vkz+GWoDqc8yerpNmo9F4O9WrQKyQNShxHk0ACMOYeigBx9GfrubkzXM1MOClFI3klzd YlKh3v17k5VB7eEXWw4Ry6rLMHq9vbrvMUWSNgAv0ZB+wp3jVOHL4qcNEuuIPzTxCaYm sm/JtJZdO/uHqWx8pG0+w2jmIix2CbGzHv2wrAcAnR/ijtXixei6tCrYGsSEGMFKaxnY BfmwLu12/s099sklvPOqE1WZrvnPtYavIyHDvtp27C/S7XfzoLAis/t+XoZCopWPaFCl 2JZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f+e2TQVy5SYt2oBLsNMtcBwLBsomTLkP+UWIMsebEi4=; b=CeSN2r68obVFVFhnIFdmU56ivEH+gEQXB3TAZ16mtdrXr7txNiRM9nHWTL/WWarmAL LVJJAqxRpWBiYJC0J7g+AJ/J4qN4XOphpG5khNiakbf+CktG3HjQT9iPs+YWfU871Nus UKzazSxlvcVg7PWquID/6rJhKpKViJub/Ifj7UUZCva+Prnw+SR70s1IB2TmbjlR2ekL pwxDgKel7FVOYpPeeYGWv26zhbUa4d96R30svqWd5vNzktsGGVgbLfaKvsSdzx741mS2 k8GgmqkTXP5T7BTfKHWXFd7xx995/0CbiqdH2+KAnh5kf8tX+fMe2srnYyRidQsHDSSp aKIg== X-Gm-Message-State: AMke39nvKO9UQ3YGN/Glke6xUuCOrhxIchvyfRLFgLUCyFD23QC5Nz1/4gRHgI9Xk1ykB7Fz7MhPfwSlXrKQzg== X-Received: by 10.200.44.83 with SMTP id e19mr20440157qta.260.1486999721821; Mon, 13 Feb 2017 07:28:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.117 with HTTP; Mon, 13 Feb 2017 07:28:41 -0800 (PST) In-Reply-To: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> From: Lishan Li Date: Mon, 13 Feb 2017 23:28:41 +0800 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=001a11406f743376e505486b1a00 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:28:47 -0000 --001a11406f743376e505486b1a00 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2017-02-09 5:38 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 : > At Mon, 16 Jan 2017 17:10:26 +0800, > Lishan Li wrote: > > > We have submitted a new version of secure DHCPv6. Thanks a lot for > Bernie's > > valuable comment. > > I apologize for having been inactive on this draft, especially despite > being listed as a coauthor. I've finally found time to take a closer > look at it. I see the 20 version has been improved a lot; it's much > more readable than (some of the) older versions and many of the > technical questions I raised before seem to be addressed. I > personally think we still need to discuss and address some more > technical details, but IMO this version is now much closer to WGLC. > [LS]: Thanks a lot for your comments. As a coauthor, you have contributed a lot and gave many valuable comments. > > ...with one big reservation: I'd very much like to see at least one > attempt of implementing the spec. This is a quite complicated > protocol specification, and no matter how hard we review the paper > spec, I'm quite sure that an actual implementation attempt will find > many more unclear points or protocol defects. Although I understand > that's not a requirement for a WGLC or even for an RFC (the spirit of > "believing in running code" has been the thing of past at the IETF, > sadly) but I still hope we won't end up shipping a protocol spec with > full of defects mainly because there is not even an attempt of > implementing it before publishing it. > > Specific comments on the 20 version follow. There is one thing that I > guess needs broader attention, so I'm noting it here: I think we need > more discussion on the meaning and justification of "Non-SigAlg" and > "Non-EncryAlg" (especially the latter). See below for more details. > > - general: it's still not clear to me how we use this mechanism for > Reconfigure. > [LS]: According to my understanding: 1. The server sends the encrypted Reconfigure message to the client; 2. If the Reconfigure option indicates the Renew message, then the client sends the encrypted Renew message to the server. For this Encrypted-Query message, it includes the server identifier option. 3. If the Reconfigure option indicates the Information-request message, then the client send the encrypted Information-request message to the server. For this Encrypted-Query message, it does not include the server identifier option. In this way, the Information message is received by all the servers which share the same certificate. If the client does not obtain the proper parameters, the client can choose other servers and sends the encrypted information-request message. > - Section 6 > > And then the client first checks acknowledged hash, signature and > encryption algorithms that the server supports. If the hash > algorithm field is zero, then it indicates that the hash algorithm is > fixed according to the corresponding signature algorithm. The client > also uses the acknowledged algorithms in the return messages. > > It's not clear to me from this text how the client checks the > algorithms. By examining the certification option for the > signature/encryption algorithms and examining the signature option > for the hash ID? If so, I think it should be clearly described. > [LS]: Yes. The signature and encryption algorithms are checked through the certificate option. And the signature and hash algorithms are checked through the signature option. And the signature algorithms id in the two options must be equal. Will describe it more clearly. > > I'd note that the signature ID in the certificate must be equal to > the signature ID of the signature option. And, generalizing this, > what if the client doesn't support these algorithms? (This shouldn't > happen as long as the server handles the algorithm option correctly, > so this is basically a bug of the server implementation). > [LS]: For this error, then the client drops the Reply message. > > The description of zero hash algorithm field seems to suggest the > signature and hash algorithms are tightly related in practice. So > it may be better to define the algorithm option so that > signature/hash algorithms are listed as pairs. > [LS]: Yes. In some cases, the signature and hash algorithm are tightly related and cannot be separate. Sorry that I don't understand that "it may be better to define the algorithm option so that signature/hash algorithms are listed as pairs", Could you please explain it more clearly? > > > - Section 6 > > The first DHCPv6 message sent from the client to the server, such as > Solicit message, MUST contain the Certificate option, Signature > option and Increasing-number option for client authentication.[...] > [...] One and only one Increasing-number option SHOULD be > contained, > > Isn't there a MUST vs SHOULD conflict here? > [LS]: The increasing-number option is optional, not must be contained. In the before version of secure DHCPv6 without encryption, the timestamp option is optional. But in fact, I don't know why it is optional. > > - Section 6 > > [...] In this document, it is assumed > that the client uses only one certificate for the encrypted DHCPv6 > configuration. So, the corresponding private key is used for > decryption. > > I'm not sure if this is okay. And, in fact, Section 11 talks about > a case where multiple key pairs (so multiple certificates) are used: > > If the client tries more than one cert for client authentication, the > server can easily get a client that implements this to enumerate its > entire cert list and probably learn a lot about a client that way. > > Perhaps this is intended to handle encrypted Reconfigure? If that's > the only reason for this limitation, I think we should address the > reconfigure case in some other way and keep the general specification > more flexible. > [LS]: So we deletes the description in section 11. > > - Section 7 > > [...] If it is the target server, according to > the Encryption-Key-Tag option, the server identifies the used public/ > private key pair and decrypts the Encrypted-message option using the > corresponding private key. > > The key tag is not necessarily unique for different public keys (so > different key pairs), even if it should normally be unique in > practice. If multiple public keys share the same tag value, the > server MUST try all corresponding key pairs. > [LS]: Got it. Will modify the related sentences. > > Also, since the key tag option isn't covered by a signature, it may > have been forged by an intermediate attacker. We may want to > describe what the server should do in such a case (just discarding > it is probably okay as it's forged anyway, but the server could also > try all possible keys just in case the key tag is the only forged > field). > [LS]: If the server then tries all the possible keys, then it is easy to cause the attack to the server. So I think it is better to just drop it, like the action of decryption fail. So we need to add the following text for this case. If the server cannot find the corresponding private key of the key tag or the corresponding private key of the key tag is invalid for decryption, then the server drops the Encrypted-Query message > > - Section 7 > > The server validates the client's certificate through the local pre- > configured trusted certificates list. > > I'm not sure if this paragraph covers the "opportunistic encryption" > mode, i.e, when the server doesn't know the certificate but chooses > to use it for encryption only. (I'm assuming our intent is to > support such mode, right?). > [LS]: Yes, will add some description about it. > > - Section 7 > > To provide > the replay protection, the Increasing-number option can be contained > in the encrypted DHCPv6 message. > > Shouldn't this be either SHOULD or MUST to be consistent with other > part of this spec? (see also the possible SHOULD vs MUST conflict > commented above). > [LS]: The increasing-number option is optional. > > - Section 9.1 > > [...] And the client can forget the increasing number > information after the transaction is finished. The client's initial > locally stored increasing number is set to zero. > > I'm not sure if I understand it and I'm not sure if it's okay > whatever it means...does this mean the server can (or always does?) > reset the increasing number to 0 for messages it sends to the server > at the beginning of a new DHCPv6 session? Doesn't it lead to an > easy replay attack? Or is the assumption that the server first > sends an error and the client will resend the message with an > adjusted increasing number? > [LS]: For the first received increasing-number option, the client cannot check it and just need to change the local increasing number into the received number. So for this purpose, i add the above statement. Looking forward to your further guidance. > > - Section 10.1.1 > > The mandatory encryption > algorithms MUST be included. > > Which algorithm is it? > [LS]: The mandatory encryption algorithm is RSA. How about the following text: The mandatory encryption algorithm, such as RSA, MUST be included. > > - Section 10.1.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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | EA-id | SA-id | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . Certificate . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This seems to assume a single certificate (which I assume means a > single public key) can be used for both encryption and signature. > Is my understanding correct? If so, can we always assume that? > [LS]: Yes, it means a single certificate and a single public key. If EA-id =3D 0 & SA-id !=3D0, then the public key is used for signature. If EA-id !=3D 0 & SA-id =3D0, then the public key is used for encryption. If EA-id !=3D 0 & SA-id !=3D0, then the public key is used for signature an= d encryption. > > - Section 10.1.2 > > It should be noticed that the scenario where the values of EA-id and > SA-id are both 0 makes no sense and the client MUST discard a message > with such values. > > The 0 EA-id/SA-id values are not described earlier in this > document. I think it should explicitly define its semantics before > this text (perhaps in Section 10.1.1). > [LS]: Agree, will add some description before it. > > And, from the description of Section 12: > > Non-SigAlg | 0x00 | this document > Non-EncryAlg | 0x00 | this document > > I guess it means the signature is (effectively) not provided and the > message is (effectively) not encrypted, respectively. If my > understanding is correct, is it okay to allow that, especially about > encryption? I vaguely recall a discussion about someone hoping to > introduce a non-encryption mode, but I thought we rejected the idea > because it would be against the "always encrypt" consensus. > [LS]: Sorry for the not clear expression. In the before part, if the EA-id is set to zero, then the certificate is not used for encryption. If the SA-id is set to zero, then the certificate is not used for signature. > > - Section 10.1.5 > > encryption key tag A variable length field containing the encryption > key tag sent from the client to server to identify the used > public/private key pair. The encryption key tag is calculated > from the public key data, like fingerprint of a specific public > key. How to generate the encryption key tag adopts the method > define in Appendix B in [RFC4034] and section 5.5 in [RFC6840]. > The data of the public key is used as input of the generation > function. > > If we derive the tag calculation from RFC4034, the length is not > variable: it's fixed to 16 bits. > [LS]: Will modify it to 16 bits > > Also, I don't think we have to mention RFC6840 section 5.5. We'd > only use the method described in Appendix B of RFC4034 for > algorithms other than type 1. > [LS]: Got it. > > And, although it may be quite straightforward, I don't think this > description is enough to actually calculate the tag value for a > given public key. We should provide some more specific here. > [LS]: Add some more specific text about how to compute it? In the before, I prepared some text about it. Key Tag Calculation The Encryption Key Tag in the Encrypted-Query message provides a mechanism for selecting the corresponding private key for decryption. In most cases, the encryption key tag can efficiently identify a private key record. The Encryption Key Tag option can be used to help select the corresponding private key when more than one candidate private key is available. However, it is essential to note that the encryption key tag is not a unique identifier. It is theoretically possible for two different public keys to share one common encryption key tag. The encryption key tag is used to limit the possible candidate keys, bu it does not uniquely identify a public/private key pair. Implements MUST NOT assume that the key tag uniquelly identifier a public/private key pair. The encryption key tag is the same for all encryption algorithm types except algorithm 1 (please see Appendix A.1 for the defination of the key tag for algorithm 1). The key tag generation algorithm is the sum of the public key data broken into 2 octet groups. First, the public key date is treated as a series of 2 octet groups. These groups are then added together. A reference implementation of the key tag algorithm is as the below function, with the data of the public key is used as input. It is not necessary to use the following reference code verbatim, but the numerical value fo teh encryption key tag MUST be identical to what the referencr implementation would generate for the same input. The following reference implementation calculates the value of the encryption key tag. This reference implementation applies to all algorithm types except algorithm 1 (see Appendix A.1). The input is the data of the public key. The code is written for clarity, not efficiency. /* * Assumes that int is at least 16 bits. * First octet of the key tag is the most significant 8 bits of the * return value; * Second octet of the key tag is the least significant 8 bits of the * return value. */ unsigned int keytag ( unsigned char key[], /* the RDATA part of the DNSKEY RR */ unsigned int keysize /* the RDLENGTH */ ) { unsigned long ac; /* assumed to be 32 bits or larger */ int i; /* loop index */ for ( ac =3D 0, i =3D 0; i < keysize; ++i ) ac +=3D (i & 1) ? key[i] : key[i] << 8; ac +=3D (ac >> 16) & 0xFFFF; return ac & 0xFFFF; } A.1. Key Tag for Algorithm 1 (RSA/MD5) The encryption key tag for algorithm 1 (RSA/MD5) is defined differently from the encryption key tag for all other algorithms, for historical reasons. For a public key with algorithm 1, the encryption key tag is defined to be the most significant 16 bits of the least significant 24 bits in the public key modulus (in other words, the 4th to last and 3rd to last octets of the public key modulus). > - Section 11 > > [RFC6273] has analyzed possible threats to the hash algorithms used > in SEND. Since Secure DHCPv6 defined in this document uses the same > hash algorithms in similar way to SEND, analysis results could be > applied as well: [...] > > Does this matter even when the hash value is in an encrypted > message? > [LS]: Got it. Will delete it. > > - Section 11 > > I think we should also discuss a few more security issues in this > section: > - Since the algorithm option isn't protected by a signature, the > list can be forged without detection, which can lead to a > downgrade attack. > - Likewise, since the Encryption-Key-Tag Option isn't protected, an > attacker that can intercept the message can forge the value > without detection (see also the relevant comment on Section 7). > [LS]: Agree. Will add it. > > - Section 12 > > Hash Algorithm for Secure DHCPv6. The values in this table are 8-bit > unsigned integers. > > Shouldn't this be 16-bit? It's defined as an 16-bit value for the > HA-id field of various options. Same for the signature algorithm > and encryption algorithm. > [LS]: Will modify it. Thanks again, Lishan --001a11406f743376e505486b1a00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017-02-09 5:38 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 <jinmei@wide.ad.jp>:
At Mon, 16 Jan 2017 17:10:26 +080= 0,
Lis= han Li <lilish= an48@gmail.com> wrote:

> We have submitted a new version of secure DHCPv6. Thanks a lot for Ber= nie's
> valuable comment.

I apologize for having been inactive on this draft, especially despi= te
being listed as a coauthor.=C2=A0 I've finally found time to take a clo= ser
look at it.=C2=A0 I see the 20 version has been improved a lot; it's mu= ch
more readable than (some of the) older versions and many of the
technical questions I raised before seem to be addressed.=C2=A0 I
personally think we still need to discuss and address some more
technical details, but IMO this version is now much closer to WGLC.
[LS]: Thanks a lot for your comments. As a coauthor, you have= contributed
a lot and gave many valuable comments.

...with one big reservation: I'd very much like to see at least one
attempt of implementing the spec.=C2=A0 This is a quite complicated
protocol specification, and no matter how hard we review the paper
spec, I'm quite sure that an actual implementation attempt will find many more unclear points or protocol defects.=C2=A0 Although I understand that's not a requirement for a WGLC or even for an RFC (the spirit of "believing in running code" has been the thing of past at the IET= F,
sadly) but I still hope we won't end up shipping a protocol spec with full of defects mainly because there is not even an attempt of
implementing it before publishing it.

Specific comments on the 20 version follow.=C2=A0 There is one thing that I=
guess needs broader attention, so I'm noting it here: I think we need more discussion on the meaning and justification of "Non-SigAlg" = and
"Non-EncryAlg" (especially the latter).=C2=A0 See below for more = details.

- general: it's still not clear to me how we use this mechanism for
=C2=A0 Reconfigure.
[LS]: According to my understandin= g:
1. The server sends the encrypted Reconfigure message to the c= lient;
2. If the Reconfigure option indicates the Renew message, = then the client=C2=A0
sends the encrypted Renew message to the se= rver. For this Encrypted-Query
message, it includes the server id= entifier option.
3. If the Reconfigure option indicates the Infor= mation-request message, then=C2=A0
the client send the encrypted = Information-request message to the server.=C2=A0
For this Encrypt= ed-Query message, it does not include the server identifier=C2=A0
option. In this way, the Information message is received by all the server= s which=C2=A0
share the same certificate. If the client does not = obtain the proper parameters,=C2=A0
the client can choose other s= ervers and sends the encrypted information-request
message.
=


- Section 6

=C2=A0 =C2=A0And then the client first checks acknowledged hash, signature = and
=C2=A0 =C2=A0encryption algorithms that the server supports.=C2=A0 If the h= ash
=C2=A0 =C2=A0algorithm field is zero, then it indicates that the hash algor= ithm is
=C2=A0 =C2=A0fixed according to the corresponding signature algorithm.=C2= =A0 The client
=C2=A0 =C2=A0also uses the acknowledged algorithms in the return messages.<= br>
=C2=A0 It's not clear to me from this text how the client checks the =C2=A0 algorithms.=C2=A0 By examining the certification option for the
=C2=A0 signature/encryption algorithms and examining the signature option =C2=A0 for the hash ID?=C2=A0 If so, I think it should be clearly described= .
[LS]: Yes. The signature and encryption algorithms a= re checked through=C2=A0
the certificate option. And the signatur= e and hash algorithms are checked
through the signature option. A= nd the signature algorithms id in the two=C2=A0
options must be e= qual. Will describe it more clearly.=C2=A0

=C2=A0 I'd note that the signature ID in the certificate must be equal = to
=C2=A0 the signature ID of the signature option.=C2=A0 And, generalizing th= is,
=C2=A0 what if the client doesn't support these algorithms? (This shoul= dn't
=C2=A0 happen as long as the server handles the algorithm option correctly,=
=C2=A0 so this is basically a bug of the server implementation).
[LS]: For this error, then the client drops the Reply message.= =C2=A0

=C2=A0 The description of zero hash algorithm field seems to suggest the =C2=A0 signature and hash algorithms are tightly related in practice.=C2=A0= So
=C2=A0 it may be better to define the algorithm option so that
=C2=A0 signature/hash algorithms are listed as pairs.
= [LS]: Yes. In some cases, the signature and hash algorithm are tightly=C2= =A0
related and cannot be separate. Sorry that I don't unders= tand that=C2=A0
"it may be better to define the algorithm op= tion so that signature/hash
algorithms are listed as pairs",= Could you please explain it more clearly?
=C2=A0


- Section 6

=C2=A0 =C2=A0The first DHCPv6 message sent from the client to the server, s= uch as
=C2=A0 =C2=A0Solicit message, MUST contain the Certificate option, Signatur= e
=C2=A0 =C2=A0option and Increasing-number option for client authentication.= [...]
=C2=A0 =C2=A0[...]=C2=A0 One and only one Increasing-number option SHOULD b= e
=C2=A0 =C2=A0contained,

=C2=A0 Isn't there a MUST vs SHOULD conflict here?
[LS]: The increasing-number option is optional, not must be contained.=C2= =A0
In the before version of secure DHCPv6 without encryption, th= e timestamp
option is optional. But in fact, I don't know why= it is optional.

- Section 6

=C2=A0 =C2=A0[...] In this document, it is assumed
=C2=A0 =C2=A0that the client uses only one certificate for the encrypted DH= CPv6
=C2=A0 =C2=A0configuration.=C2=A0 So, the corresponding private key is used= for
=C2=A0 =C2=A0decryption.

=C2=A0 I'm not sure if this is okay.=C2=A0 And, in fact, Section 11 tal= ks about
=C2=A0 a case where multiple key pairs (so multiple certificates) are used:=

=C2=A0 =C2=A0If the client tries more than one cert for client authenticati= on, the
=C2=A0 =C2=A0server can easily get a client that implements this to enumera= te its
=C2=A0 =C2=A0entire cert list and probably learn a lot about a client that = way.

=C2=A0Perhaps this is intended to handle encrypted Reconfigure?=C2=A0 If th= at's
=C2=A0the only reason for this limitation, I think we should address the =C2=A0reconfigure case in some other way and keep the general specification=
=C2=A0more flexible.
[LS]: So we deletes the descripti= on in section 11.=C2=A0

- Section 7

=C2=A0 =C2=A0[...] If it is the target server, according to
=C2=A0 =C2=A0the Encryption-Key-Tag option, the server identifies the used = public/
=C2=A0 =C2=A0private key pair and decrypts the Encrypted-message option usi= ng the
=C2=A0 =C2=A0corresponding private key.

=C2=A0 The key tag is not necessarily unique for different public keys (so<= br> =C2=A0 different key pairs), even if it should normally be unique in
=C2=A0 practice.=C2=A0 If multiple public keys share the same tag value, th= e
=C2=A0 server MUST try all corresponding key pairs.
[L= S]: Got it. Will modify the related sentences.

=C2=A0 Also, since the key tag option isn't covered by a signature, it = may
=C2=A0 have been forged by an intermediate attacker.=C2=A0 We may want to =C2=A0 describe what the server should do in such a case (just discarding =C2=A0 it is probably okay as it's forged anyway, but the server could = also
=C2=A0 try all possible keys just in case the key tag is the only forged =C2=A0 field).
[LS]: If the server then tries all the = possible keys, then it is easy to=C2=A0
cause the attack to the s= erver. So I think it is better to just drop it, like=C2=A0
the ac= tion of decryption fail.
So we need to add the following text for= this case.
If the server cannot find the corresponding private k= ey of the key tag
or the corresponding private key of the key tag= is invalid for decryption,=C2=A0
then the server drops the Encry= pted-Query message

- Section 7

=C2=A0 =C2=A0The server validates the client's certificate through the = local pre-
=C2=A0 =C2=A0configured trusted certificates list.

=C2=A0 I'm not sure if this paragraph covers the "opportunistic en= cryption"
=C2=A0 mode, i.e, when the server doesn't know the certificate but choo= ses
=C2=A0 to use it for encryption only.=C2=A0 (I'm assuming our intent is= to
=C2=A0 support such mode, right?).
[LS]: Yes, will add= some description about it.

- Section 7

=C2=A0 =C2=A0To provide
=C2=A0 =C2=A0the replay protection, the Increasing-number option can be con= tained
=C2=A0 =C2=A0in the encrypted DHCPv6 message.

=C2=A0 Shouldn't this be either SHOULD or MUST to be consistent with ot= her
=C2=A0 part of this spec?=C2=A0 (see also the possible SHOULD vs MUST confl= ict
=C2=A0 commented above).
[LS]: The increasing-number o= ption is optional.=C2=A0

- Section 9.1

=C2=A0 =C2=A0[...]=C2=A0 And the client can forget the increasing number =C2=A0 =C2=A0information after the transaction is finished.=C2=A0 The clien= t's initial
=C2=A0 =C2=A0locally stored increasing number is set to zero.

=C2=A0 I'm not sure if I understand it and I'm not sure if it's= okay
=C2=A0 whatever it means...does this mean the server can (or always does?)<= br> =C2=A0 reset the increasing number to 0 for messages it sends to the server=
=C2=A0 at the beginning of a new DHCPv6 session?=C2=A0 Doesn't it lead = to an
=C2=A0 easy replay attack?=C2=A0 Or is the assumption that the server first=
=C2=A0 sends an error and the client will resend the message with an
=C2=A0 adjusted increasing number?
[LS]: For the first= received increasing-number option, the client cannot
check it an= d just need to change the local increasing number into the=C2=A0
= received number. So for this purpose, i add the above statement.=C2=A0
Looking forward to your further guidance.=C2=A0

- Section 10.1.1

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The mandatory encryp= tion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0algorithms MUST be i= ncluded.

=C2=A0 Which algorithm is it?
[LS]: The mandatory encr= yption algorithm is RSA. How about the following=C2=A0
text:
The mandatory encryption algorithm, such as RSA, MUST be included. = =C2=A0

- Section 10.1.2

=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A03
=C2=A0 =C2=A0 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
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 OPTION_CERTIFICATE=C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option-len=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EA-id=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 SA-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Certificate=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+

=C2=A0 This seems to assume a single certificate (which I assume means a =C2=A0 single public key) can be used for both encryption and signature. =C2=A0 Is my understanding correct?=C2=A0 If so, can we always assume that?=
[LS]: Yes, it means a single certificate and a single= public key.=C2=A0
If EA-id =3D 0 & SA-id !=3D0, then the pub= lic key is used for signature.
If EA-id !=3D 0 & SA-id =3D0, = then the public key is used for encryption.
If EA-id !=3D 0 &= amp; SA-id !=3D0, then the public key is used for signature and encryption.=

- Section 10.1.2

=C2=A0 =C2=A0It should be noticed that the scenario where the values of EA-= id and
=C2=A0 =C2=A0SA-id are both 0 makes no sense and the client MUST discard a = message
=C2=A0 =C2=A0with such values.

=C2=A0 The 0 EA-id/SA-id values are not described earlier in this
=C2=A0 document.=C2=A0 I think it should explicitly define its semantics be= fore
=C2=A0 this text (perhaps in Section 10.1.1).
[LS]: Ag= ree, will add some description before it.=C2=A0

=C2=A0 And, from the description of Section 12:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Non-SigAlg=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A00x00=C2=A0 | this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Non-EncryAlg=C2=A0 |=C2=A0 =C2=A00= x00=C2=A0 | this document

=C2=A0 I guess it means the signature is (effectively) not provided and the=
=C2=A0 message is (effectively) not encrypted, respectively.=C2=A0 If my =C2=A0 understanding is correct, is it okay to allow that, especially about=
=C2=A0 encryption?=C2=A0 I vaguely recall a discussion about someone hoping= to
=C2=A0 introduce a non-encryption mode, but I thought we rejected the idea<= br> =C2=A0 because it would be against the "always encrypt" consensus= .
[LS]: Sorry for the not clear expression.=C2=A0
In the before part, if the EA-id is set to zero, then the certificate= is not used
for encryption. If the SA-id is set to zero, then th= e certificate is not used for=C2=A0
signature. =C2=A0

- Section 10.1.5

=C2=A0 =C2=A0encryption key tag=C2=A0 A variable length field containing th= e encryption
=C2=A0 =C2=A0 =C2=A0 key tag sent from the client to server to identify the= used
=C2=A0 =C2=A0 =C2=A0 public/private key pair.=C2=A0 The encryption key tag = is calculated
=C2=A0 =C2=A0 =C2=A0 from the public key data, like fingerprint of a specif= ic public
=C2=A0 =C2=A0 =C2=A0 key.=C2=A0 How to generate the encryption key tag adop= ts the method
=C2=A0 =C2=A0 =C2=A0 define in Appendix B in [RFC4034] and section 5.5 in [= RFC6840].
=C2=A0 =C2=A0 =C2=A0 The data of the public key is used as input of the gen= eration
=C2=A0 =C2=A0 =C2=A0 function.

=C2=A0 If we derive the tag calculation from RFC4034, the length is not
=C2=A0 variable: it's fixed to 16 bits.
[LS]: Will= modify it to 16 bits=C2=A0

=C2=A0 Also, I don't think we have to mention RFC6840 section 5.5.=C2= =A0 We'd
=C2=A0 only use the method described in Appendix B of RFC4034 for
=C2=A0 algorithms other than type 1.
[LS]: Got it.=C2= =A0

=C2=A0 And, although it may be quite straightforward, I don't think thi= s
=C2=A0 description is enough to actually calculate the tag value for a
=C2=A0 given public key.=C2=A0 We should provide some more specific here.
[LS]: Add some more specific text about how to compute = it?
In the before, I prepared some text about it.
=C2= =A0Key Tag Calculation

The Encryption Key Tag in t= he Encrypted-Query message provides a mechanism for selecting=C2=A0
the corresponding private key for decryption. In most cases, the encrypt= ion key tag=C2=A0
can efficiently identify a private key record. = The Encryption Key Tag option can=C2=A0
be used to help select th= e corresponding private key when more than one candidate
private = key is available.

However, it is essential to note= that the encryption key tag is not a unique identifier.
It is th= eoretically possible for two different public keys to share one common encr= yption
key tag. The encryption key tag is used to limit the possi= ble candidate keys, bu it=C2=A0
does not uniquely identify a publ= ic/private key pair. Implements MUST NOT assume that=C2=A0
the ke= y tag uniquelly identifier a public/private key pair.

<= div>The encryption key tag is the same for all encryption algorithm types e= xcept algorithm
1 (please see Appendix A.1 for the defination of = the key tag for algorithm 1). The key
tag generation algorithm is= the sum of the public key data broken into 2 octet groups.=C2=A0
First, the public key date is treated as a series of 2 octet groups. These= groups are
then added together.

A refer= ence implementation of the key tag algorithm is as the below function, with= the=C2=A0
data of the public key is used as input. It is not nec= essary to use the following=C2=A0
reference code verbatim, but th= e numerical value fo teh encryption key tag MUST be=C2=A0
identic= al to what the referencr implementation would generate for the same input.<= /div>

The following reference implementation calculates = the value of the encryption key tag.
This reference implementatio= n applies to all algorithm types except algorithm 1 (see
Appendix= A.1). The input is the data of the public key. The code is written for cla= rity,
not efficiency.

/*
=C2= =A0 =C2=A0 * Assumes that int is at least 16 bits.
=C2=A0 =C2=A0 = * First octet of the key tag is the most significant 8 bits of the
=C2=A0 =C2=A0 * return value;
=C2=A0 =C2=A0 * Second octet of t= he key tag is the least significant 8 bits of the
=C2=A0 =C2=A0 *= return value.
=C2=A0 =C2=A0 */

=C2=A0 = =C2=A0unsigned int
=C2=A0 =C2=A0keytag (
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0unsigned char key[], =C2=A0/* the RDATA part of = the DNSKEY RR */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unsigne= d int keysize =C2=A0/* the RDLENGTH */
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 )
=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0unsigned long ac; =C2=A0 =C2=A0 /* assumed to be 32 bits or l= arger */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int i; =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* loop index */
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for ( ac =3D 0, i = =3D 0; i < keysize; ++i )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ac +=3D (i & 1) ? key[i] : key[i] <= ;< 8;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ac +=3D (ac >= ;> 16) & 0xFFFF;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= return ac & 0xFFFF;
=C2=A0 =C2=A0}

= =C2=A0 =C2=A0A.1.=C2=A0 Key Tag for Algorithm 1 (RSA/MD5)

=C2=A0 =C2=A0The encryption key tag for algorithm 1 (RSA/MD5) is de= fined differently from=C2=A0
=C2=A0 =C2=A0the encryption key tag = for all other algorithms, for historical reasons.=C2=A0 For a
=C2= =A0 =C2=A0public key with algorithm 1, the encryption key tag is defined to= be the most
=C2=A0 =C2=A0significant 16 bits of the least signif= icant 24 bits in the public key modulus=C2=A0
=C2=A0 =C2=A0(in ot= her words, the 4th to last and 3rd to last octets of the public key modulus= ).


- Section 11

=C2=A0 =C2=A0[RFC6273] has analyzed possible threats to the hash algorithms= used
=C2=A0 =C2=A0in SEND.=C2=A0 Since Secure DHCPv6 defined in this document us= es the same
=C2=A0 =C2=A0hash algorithms in similar way to SEND, analysis results could= be
=C2=A0 =C2=A0applied as well: [...]

=C2=A0 Does this matter even when the hash value is in an encrypted
=C2=A0 message?
[LS]: Got it. Will delete it.=C2=A0

- Section 11

=C2=A0 I think we should also discuss a few more security issues in this =C2=A0 section:
=C2=A0 - Since the algorithm option isn't protected by a signature, the=
=C2=A0 =C2=A0 list can be forged without detection, which can lead to a
=C2=A0 =C2=A0 downgrade attack.
=C2=A0 - Likewise, since the Encryption-Key-Tag Option isn't protected,= an
=C2=A0 =C2=A0 attacker that can intercept the message can forge the value =C2=A0 =C2=A0 without detection (see also the relevant comment on Section 7= ).
[LS]: Agree. Will add it.=C2=A0

- Section 12

=C2=A0 =C2=A0Hash Algorithm for Secure DHCPv6.=C2=A0 The values in this tab= le are 8-bit
=C2=A0 =C2=A0unsigned integers.

=C2=A0 Shouldn't this be 16-bit?=C2=A0 It's defined as an 16-bit va= lue for the
=C2=A0 HA-id field of various options.=C2=A0 Same for the signature algorit= hm
=C2=A0 and encryption algorithm.
[LS]: Will modify it.=

Thanks again,
Lishan=C2=A0
<= br>
--001a11406f743376e505486b1a00-- From nobody Mon Feb 13 08:01:21 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20530129454 for ; Mon, 13 Feb 2017 08:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 YBkJUxBfAN6l for ; Mon, 13 Feb 2017 08:01:16 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57018128E19 for ; Mon, 13 Feb 2017 08:01:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GeAADe16FY/xUHmMZeGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgxBCYYEJB41akgyTJ4IPgUlDJoV8AoIqPxgBAgEBAQEBAQEDXyi?= =?us-ascii?q?CWz0GBy8BAQEBAQEBAQEBAQEBHAIPQQEBGAEBAQECARIoNAMNBwQCAQgNAQMEA?= =?us-ascii?q?QELFAkHMhQJCAIEARIIGolACAGjXY0HJgKLHAEBAQEBAQQBAQEBAQEBAQEBHoZ?= =?us-ascii?q?NhG6BPIMCBhKDMoIxBYkdh2yKaQGGbo1ziAiGL5MVHzmBAFEVPYRFHYFhdYdzK?= =?us-ascii?q?4EDAYELAQEB?= X-IPAS-Result: =?us-ascii?q?A2GeAADe16FY/xUHmMZeGQEBAQEBAQEBAQEBBwEBAQEBgxB?= =?us-ascii?q?CYYEJB41akgyTJ4IPgUlDJoV8AoIqPxgBAgEBAQEBAQEDXyiCWz0GBy8BAQEBA?= =?us-ascii?q?QEBAQEBAQEBHAIPQQEBGAEBAQECARIoNAMNBwQCAQgNAQMEAQELFAkHMhQJCAI?= =?us-ascii?q?EARIIGolACAGjXY0HJgKLHAEBAQEBAQQBAQEBAQEBAQEBHoZNhG6BPIMCBhKDM?= =?us-ascii?q?oIxBYkdh2yKaQGGbo1ziAiGL5MVHzmBAFEVPYRFHYFhdYdzK4EDAYELAQEB?= X-IronPort-AV: E=Sophos;i="5.35,156,1484024400"; d="scan'208";a="190447287" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Feb 2017 11:00:38 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Feb 2017 11:00:24 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0319.002; Mon, 13 Feb 2017 11:00:23 -0500 From: "Mudric, Dusan (Dusan)" To: Simon Hobson , dhcwg , "dhcp-users@lists.isc.org" Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9wgAA6TwCAAFLTEP//ubmAgABS6jD//68/gIAAUzJQ//+28gAACnV4EAAKQI6AAB7vbSAAMyFpAABwmj1wAKS8ff4BSSOxkAKHSe+ABJNGvAAJGbPkgBI78p5w Date: Mon, 13 Feb 2017 16:00:23 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA19659@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA194E5@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 16:01:19 -0000 I would like to get more feedback from DHCPv6 users. Preferably, to priorit= ize the list below. What would be the number one priority item from this li= st that DHCPv6 users would like to address? Thanks, Dusan -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simon Hobson Sent: Monday, February 13, 2017 9:57 AM To: dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition "Mudric, Dusan (Dusan)" wrote: > PROBLEM STATEMENTS: > - A network operator can set client IPv6 addresses on DHCPv6 server. That is the primary function of the DHCP server ! I don't see that as a pro= blem. > An address can be invalid or make a client unreachable. There are a lot of other ways to bo**ox up a network ! Such configurations may be deliberate. Until recently I did in fact run a n= etwork with unroutable (as in valid IP, but no router for that subnet) addr= esses because there was a policy decision that this particular network woul= d be isolated - it was a backend network to carry traffic independently of = the traffic on the public facing front end network. > - A network operator can change an address prefix on a router. A client a= ddress can become unreachable Ditto. This is simply failing to co-ordinate network changes. Before removing/chan= ging the prefix, the DHCP admin should have removed the pool IFF it is desi= red that the addresses be usable for external connectivity. As previously m= entioned, this may be deliberate on the part of the Admin. > - A default router offering a prefix to a client can become unreachable. "Sh*t happens". Not only that, but what happens if the server hands out a l= oad of IPv6 addresses which are all valid AT THE TIME OF ALLOCATION ? Even = if your proposal were implemented, these addresses would be accepted and co= nfigured because they would be valid AT THE TIME OF ALLOCATION. The DHCP se= rver and client cannot do anything about it if, say, 5 seconds into a 60 da= y lease, a router stops advertising a prefix appropriate to that address. It would be for the OS to detect that situation, and simply stop using that= address for outbound connections. IMO it would be inappropriate for all th= e clients to somehow tell the server that all these addresses are bad - onl= y to have 20,000 clients all contact the server again a few minutes later w= hen the router comes back up and the prefix becomes valid again. That would= be designing in network instability. > A client address can become unreachable on a local link=20 ? > - A client does not release unused addresses So ? There's 2^64 addresses in a minimal IPv6 prefix. How many billion addr= esses do you intend using for each client ? Even if your 20,000 clients all= took and held onto 1000 addresses each, that's still a tiny tiny fraction = of the available addresses. > - A client validates the addresses and the address prefixes and notifies = DHCPv6 server about the problems HOW ? You will need to define the algorithm for validating addresses. So far you'= ve only come up with "isn't on any prefix advertised by a router" (as above= , not a valid test) and "in a deprecated prefix" (as mentioned in an earlie= r message, not a valid test). You will also need to define a mechanism whereby all clients can have the a= lgorithm updated as policies change - eg prefixes get deprecated (as previo= usly discussed), new prefixes come into use (eg I assume you would expect c= urrently unused prefixes to be rejected, but they could come into use at an= y time when it's considered that they are needed). You will also need to define a mechanism for the local admins to over-ride = the stock algorithm - eg where the admins have made a policy decision to ru= n isolated networks. This introduces a catch-22 situation where new devices= might not be configurable (they won't attach to the network) until they ha= ve been configured (policy edited to allow them to connect). This is critical to your proposal - until you can come up with an easily de= fined, and robust, algorithm then your proposal CANNOT work. Worse, it may = cause far more problems than it is supposed to solve. > - A client returns unused addresses > - DHCPv6 server: > -- logs error messages (invalid & unreachable addresses with device IDs) > -- does not assign the invalid addresses > -- periodically checks for the reachability of unreachable addresses and= , when they become reachable, assigns them again Define "valid" and "reachable" here ? The implication from this and your earlier emails is that you define "reach= able" as "has an IP which is routable to/from 'the internet'". See my comme= nt above about running isolated networks, that backend isolated network run= s a DHCP service - so the addresses on it are "reachable" in terms of "the = DHCP server can reach them", but they aren't globally routable (they are ac= tually RFC1918 IPv4 addresses, but the argument stands). With a previous hat on, I had 2 Class C public IPv4 allocations which weren= 't globally routable. There is also the issue that the server (in the general case) CANNOT determ= ine the reachability/routability of any prefix. There are plenty of network= topologies where the server may lose connectivity to "something" while cli= ents don't, or vice-versa, while connectivity between server and client net= work is still working. Similarly, there are topologies while server-client = comms could be lost, while both still have connectivity to "something". Thi= s is the reason that, out of the box, DHCP4 servers in failover do NOT auto= matically go into partner-down state when they lose connectivity between th= em. > - An operator > -- checks if there are unreachable devices and the reason codes An alternative: The site/organisation admins take care to co-ordinate chang= es, and test changes in configuration. They should employ monitoring to det= ect issues, and respond appropriately to helpdesk tickets. Configuration management (and especially automation) will detect many of th= e issues you've raised. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dhcwg&d=3DDQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3D-9s7e0Ks0EQLldj5oI4E9zLJKH-0ehGNzPg6r665zKo&= s=3DyZV16lh2Yih0GhvVieDz2J5SHShPy-iKWBYCkGKJkSo&e=3D=20 -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mudric, Dusan (Dus= an) Sent: Monday, February 13, 2017 9:02 AM To: dhcp-users; dhcwg Subject: Re: [dhcwg] RFC3315 DECLINE definition Thanks to DHCWG group for their comments. I believe the proposals would ben= efit DHCv6 users. For the record: PROBLEM STATEMENTS: - A network operator can set client IPv6 addresses on DHCPv6 server. An add= ress can be invalid or make a client unreachable. - A network operator can change an address prefix on a router. A client add= ress can become unreachable - A default router offering a prefix to a client can become unreachable. A = client address can become unreachable on a local link - A client does not release unused addresses PROPOSED FAILURE INDICATIONS - A client validates the addresses and the address prefixes and notifies DH= CPv6 server about the problems - A client returns unused addresses - DHCPv6 server: -- logs error messages (invalid & unreachable addresses with device IDs) -- does not assign the invalid addresses -- periodically checks for the reachability of unreachable addresses and,= when they become reachable, assigns them again - An operator -- checks if there are unreachable devices and the reason codes __________= _____________________________________ dhcwg mailing list dhcwg@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_dhcwg&d=3DDQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3DQxk02ZIjaVguViwH6GFfRlZ1P5VOsYQOjA3jNkynsoA&= s=3D2J3Xq9IQVsoMl7JTQP52olq6E_tc1b6kLGRuJ0RnkWE&e=3D From nobody Mon Feb 13 11:20:38 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A596129862 for ; Mon, 13 Feb 2017 11:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 wsX1hTECQsrW for ; Mon, 13 Feb 2017 11:20:31 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2042C129858 for ; Mon, 13 Feb 2017 11:20:31 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id w20so92057939qtb.1 for ; Mon, 13 Feb 2017 11:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=F6aptgqsY67Lj+ksFG7H7DzDLCJmHUcPi+PkgwXIr9k=; b=pfjXsMODX0sSLCP3JRaevrpF0OmhVBCsB5uNvViOFpKxFEp6fxhwNVA2up9/gIFxQ8 wzJI8IIOCg2M/MDfnaisXK/zFDeu5V6lbSK1UEg8EYyUkZ5vm4axRext0aCYzNoSZ3gI N4SH1psStXB3juKyFx+mjQlKZOeQgUbranOFvZV3NqU1uyS+ZL1Hblhx92l+t60Ma3eU NqhnARy6R7yzEddyb7yFMWkMT9w16a+f4sHXCraMcOrJzj4ld1Gis1ydxh4C4NBElunL 8dIGWD2IY1cW7N8RjYgp/9hrBVXEkY00cpvsR3+08qT+i8MKg66P4t+nSPJQtcSNtN1b 2mbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=F6aptgqsY67Lj+ksFG7H7DzDLCJmHUcPi+PkgwXIr9k=; b=hux+60fd8BPEM0z9qH02ztoY7JZPKYIyMgdVyaAuf+458uM94yKp3cAlVTM/bgeSA0 /ycxfnsCIuuCe9ToJ4JtzkOY0iZiDNK+pr3CtvGp6nG8EAgLu5BYWny2X7dlMTlQDoaU svVwLx6D6NX2GvQWYpRZr+QIDWr6z9xM9PHeAUtnD4BA5C5APDNGMSRJi/KNCZAMJpY/ A8LmlvzycXpIrR0B2RZ43tlDfxNe/MbUV0z+Vz3eZjwJtJ3tMnNlnW9CD3bnZUMS97o4 bTSxMWq+9ZZpa6vwmkLmCDu0OssR7Ta3FD/YAzehw5Mr8i1iCht1NEXyAVHD9si33QWv oOUw== X-Gm-Message-State: AMke39lIO4Vkiw4B/T5scJ/uCjvJl3hqsV+M/bRK3rRYYk8XFoLKo9Pk7R1d4vrjIzkvyQ== X-Received: by 10.200.51.186 with SMTP id c55mr22532615qtb.270.1487013630140; Mon, 13 Feb 2017 11:20:30 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id e3sm8114299qtg.7.2017.02.13.11.20.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Feb 2017 11:20:28 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C1522BA2-C405-4991-A6BE-D29A3586A026" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Feb 2017 14:20:27 -0500 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA19659@AZ-US1EXMB03.global.avaya.com> To: "Mudric, Dusan (Dusan)" References: <9142206A0C5BF24CB22755C8EC422E457AA194E5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA19659@AZ-US1EXMB03.global.avaya.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhcwg , "dhcp-users@lists.isc.org" , Simon Hobson Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:20:35 -0000 --Apple-Mail=_C1522BA2-C405-4991-A6BE-D29A3586A026 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 13, 2017, at 11:00 AM, Mudric, Dusan (Dusan) = wrote: > I would like to get more feedback from DHCPv6 users. Preferably, to = prioritize the list below. What would be the number one priority item = from this list that DHCPv6 users would like to address? You have gotten as much feedback as you're likely to get on the working = group mailing list. As far as I can tell, the feedback is that none of = the things you've listed are priorities, and for good reason. --Apple-Mail=_C1522BA2-C405-4991-A6BE-D29A3586A026 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Feb 13, 2017, at 11:00 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote:
I would like to get more feedback from DHCPv6 = users. Preferably, to prioritize the list below. What would be the = number one priority item from this list that DHCPv6 users would like to = address?

You = have gotten as much feedback as you're likely to get on the working = group mailing list.   As far as I can tell, the feedback is that = none of the things you've listed are priorities, and for good = reason.

= --Apple-Mail=_C1522BA2-C405-4991-A6BE-D29A3586A026-- From nobody Mon Feb 13 13:26:33 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB496129959 for ; Mon, 13 Feb 2017 13:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 gqvED875CBU0 for ; Mon, 13 Feb 2017 13:26:27 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03F81298C8 for ; Mon, 13 Feb 2017 13:26:27 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ETAQCPI6JY/yYyC4deGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8hQmGBCQeNWpINlTaCAAwfAYYCAoFuPxgBAgEBAQEBAQEDXyi?= =?us-ascii?q?EaQEBAQEDAREbQQsQAgEIDQEDBAEBCx0HKAoUCQgCBA4FCBqJSAGkIY0HJgKLL?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GTYRugTyDGjSCfoIxBYl0kX4BjHmPcIY?= =?us-ascii?q?vkxUfOYEAURU9hkN1iSEBgQsBAQE?= X-IPAS-Result: =?us-ascii?q?A2ETAQCPI6JY/yYyC4deGQEBAQEBAQEBAQEBBwEBAQEBgm8?= =?us-ascii?q?hQmGBCQeNWpINlTaCAAwfAYYCAoFuPxgBAgEBAQEBAQEDXyiEaQEBAQEDAREbQ?= =?us-ascii?q?QsQAgEIDQEDBAEBCx0HKAoUCQgCBA4FCBqJSAGkIY0HJgKLLwEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAR2GTYRugTyDGjSCfoIxBYl0kX4BjHmPcIYvkxUfOYEAURU9h?= =?us-ascii?q?kN1iSEBgQsBAQE?= X-IronPort-AV: E=Sophos;i="5.35,157,1484024400"; d="scan'208,217";a="227858825" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Feb 2017 16:26:26 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Feb 2017 16:26:26 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0319.002; Mon, 13 Feb 2017 16:26:25 -0500 From: "Mudric, Dusan (Dusan)" To: Ted Lemon Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AQHShi47VzCckicuS8ujStD5DUW3kaFncoOQ Date: Mon, 13 Feb 2017 21:26:25 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457AA197FD@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457AA194E5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA19659@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457AA197FDAZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: Cc: dhcwg , "dhcp-users@lists.isc.org" , Simon Hobson Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 21:26:31 -0000 --_000_9142206A0C5BF24CB22755C8EC422E457AA197FDAZUS1EXMB03glob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anyone else that would benefit from a list of devices (their MAC addresses)= with assigned IPv6 addresses that are not valid or are unreachable? Dusan From: Ted Lemon [mailto:mellon@fugue.com] Sent: Monday, February 13, 2017 2:20 PM To: Mudric, Dusan (Dusan) Cc: Simon Hobson; dhcwg; dhcp-users@lists.isc.org Subject: Re: [dhcwg] RFC3315 DECLINE definition On Feb 13, 2017, at 11:00 AM, Mudric, Dusan (Dusan) > wrote: I would like to get more feedback from DHCPv6 users. Preferably, to priorit= ize the list below. What would be the number one priority item from this li= st that DHCPv6 users would like to address? You have gotten as much feedback as you're likely to get on the working gro= up mailing list. As far as I can tell, the feedback is that none of the t= hings you've listed are priorities, and for good reason. --_000_9142206A0C5BF24CB22755C8EC422E457AA197FDAZUS1EXMB03glob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anyone else that would be= nefit from a list of devices (their MAC addresses) with assigned IPv6 addre= sses that are not valid or are unreachable?

 <= /p>

Dusan

 

From: Ted Lemo= n [mailto:mellon@fugue.com]
Sent: Monday, February 13, 2017 2:20 PM
To: Mudric, Dusan (Dusan)
Cc: Simon Hobson; dhcwg; dhcp-users@lists.isc.org
Subject: Re: [dhcwg] RFC3315 DECLINE definition

 

On Feb 13, 2017, at 11:00 AM, Mudric, Dusan (Dusan) = <dmudric@avaya.com> wrote:

I would like to get more feedback from= DHCPv6 users. Preferably, to prioritize the list below. What would be the = number one priority item from this list that DHCPv6 users would like to address?

 

You have gotten as much feedback as you're likely to= get on the working group mailing list.   As far as I can tell, the fe= edback is that none of the things you've listed are priorities, and for goo= d reason.

 

--_000_9142206A0C5BF24CB22755C8EC422E457AA197FDAZUS1EXMB03glob_-- From nobody Mon Feb 13 15:37:02 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D3112958B for ; Mon, 13 Feb 2017 15:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xZLGJJvfXsIw for ; Mon, 13 Feb 2017 15:36:58 -0800 (PST) Received: from smfilter3.kt.com (smfilter3.kt.com [14.63.245.79]) by ietfa.amsl.com (Postfix) with ESMTP id 72BB312941C for ; Mon, 13 Feb 2017 15:36:57 -0800 (PST) Received: from external ([147.6.42.87]) by smfilter3.kt.com (1.0) id v1DNZQV00D2F; Tue, 14 Feb 2017 08:35:26 +0900 Received: by KTEX2.localdomain (Postfix, from userid 600) id 3vMhk644ySz418P1; Tue, 14 Feb 2017 08:35:03 +0900 (KST) Received: from MAIL-FRT-01.corp.ktad.kt.com (unknown [147.6.42.85]) by KTEX2.localdomain (Postfix) with ESMTP id 3vMhjg3Xlsz4180L; Tue, 14 Feb 2017 08:35:03 +0900 (KST) Received: from MAIL-MBX-02.corp.ktad.kt.com ([10.215.33.72]) by MAIL-FRT-01.corp.ktad.kt.com ([10.215.33.51]) with mapi id 14.03.0210.002; Tue, 14 Feb 2017 08:35:03 +0900 From: =?ks_c_5601-1987?B?sei/7MXCKE5ldHdvcmsgSW5ub3ZhdGlvbiBQcm9qZWMp?= To: "Mudric, Dusan (Dusan)" , Ted Lemon Thread-Topic: [dhcwg] RFC3315 DECLINE definition Thread-Index: AdKCVGJ7VzCckicuS8ujStD5DUW3kQAAXlQAAADH2iAAAEJQgAAATJqQAAClqeAAH3aUcAAClxKAAAGY9gD///saAIAADr9w//9PnQCAAAvYgIAAALWAgAABlgCAAACTgIAABP0AgAAFJgCAAAESAIAAAJWAgAAB4ICAAACZAIAAAlcAgAAJ8gCAAWNTgIAAHtAAgAAMpICAADIegIAABaeAgAAR9gCAAARFgIAAAouAgAQx3QCAAA9YgIAAEaKAgAA35oCAACMxgP//RZ8Q Date: Mon, 13 Feb 2017 23:35:02 +0000 Message-ID: <67EB6F85A7D7C04F9395712F712DAABC36C2EDFC@MAIL-MBX-02> References: <9142206A0C5BF24CB22755C8EC422E457AA194E5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA19659@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA197FD@AZ-US1EXMB03.global.avaya.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA197FD@AZ-US1EXMB03.global.avaya.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.207.248.34] Content-Type: multipart/alternative; boundary="_000_67EB6F85A7D7C04F9395712F712DAABC36C2EDFCMAILMBX02_" MIME-Version: 1.0 Archived-At: Cc: dhcwg , "dhcp-users@lists.isc.org" , Simon Hobson Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 23:37:01 -0000 --_000_67EB6F85A7D7C04F9395712F712DAABC36C2EDFCMAILMBX02_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSB0aGluayBJUHY2IGlzIGNvLWV4aXN0ZWQgd2l0aCBJUHY0IGZvciBhIHdoaWxlLg0KRGV2aWNl cyBoYXZlIGR1YWwgc3RhY2sgd2l0aCBJUHY0IGFuZCBJUHY2IGFkZHJlc3MuDQpBbmQgdGhlcmUg YXJlIGNhc2VzIHRoYXQgdHJhY2VzIHRoZSBwcm9ibGVtIHdpdGggSVB2NCAmIElQdjYgYWRkcmVz cyBpbmZvcm1hdGlvbi4NCkJ1dCwgbm93IHRoZXJlIGhhdmUgbm8gY29tbW9uIGtleSBiZXR3ZWVu IHRoZW0uDQpTbywgSSB0aGluayBJUHY2IGluZm9ybWF0aW9uIGlzIGluY2x1ZGVkIHdpdGggZGV2 aWNlIG1hYyBhZGRyZXNzIGZvciB0cmFjaW5nIElQdjQuDQoNClV0YWUuDQoNCkZyb206IGRoY3dn IFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE11ZHJpYywgRHVz YW4gKER1c2FuKQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTQsIDIwMTcgNjoyNiBBTQ0KVG86 IFRlZCBMZW1vbg0KQ2M6IGRoY3dnOyBkaGNwLXVzZXJzQGxpc3RzLmlzYy5vcmc7IFNpbW9uIEhv YnNvbg0KU3ViamVjdDogUmU6IFtkaGN3Z10gUkZDMzMxNSBERUNMSU5FIGRlZmluaXRpb24NCg0K QW55b25lIGVsc2UgdGhhdCB3b3VsZCBiZW5lZml0IGZyb20gYSBsaXN0IG9mIGRldmljZXMgKHRo ZWlyIE1BQyBhZGRyZXNzZXMpIHdpdGggYXNzaWduZWQgSVB2NiBhZGRyZXNzZXMgdGhhdCBhcmUg bm90IHZhbGlkIG9yIGFyZSB1bnJlYWNoYWJsZT8NCg0KRHVzYW4NCg0KRnJvbTogVGVkIExlbW9u IFttYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbV0NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTMsIDIw MTcgMjoyMCBQTQ0KVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKQ0KQ2M6IFNpbW9uIEhvYnNvbjsg ZGhjd2c7IGRoY3AtdXNlcnNAbGlzdHMuaXNjLm9yZzxtYWlsdG86ZGhjcC11c2Vyc0BsaXN0cy5p c2Mub3JnPg0KU3ViamVjdDogUmU6IFtkaGN3Z10gUkZDMzMxNSBERUNMSU5FIGRlZmluaXRpb24N Cg0KT24gRmViIDEzLCAyMDE3LCBhdCAxMTowMCBBTSwgTXVkcmljLCBEdXNhbiAoRHVzYW4pIDxk bXVkcmljQGF2YXlhLmNvbTxtYWlsdG86ZG11ZHJpY0BhdmF5YS5jb20+PiB3cm90ZToNCkkgd291 bGQgbGlrZSB0byBnZXQgbW9yZSBmZWVkYmFjayBmcm9tIERIQ1B2NiB1c2Vycy4gUHJlZmVyYWJs eSwgdG8gcHJpb3JpdGl6ZSB0aGUgbGlzdCBiZWxvdy4gV2hhdCB3b3VsZCBiZSB0aGUgbnVtYmVy IG9uZSBwcmlvcml0eSBpdGVtIGZyb20gdGhpcyBsaXN0IHRoYXQgREhDUHY2IHVzZXJzIHdvdWxk IGxpa2UgdG8gYWRkcmVzcz8NCg0KWW91IGhhdmUgZ290dGVuIGFzIG11Y2ggZmVlZGJhY2sgYXMg eW91J3JlIGxpa2VseSB0byBnZXQgb24gdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0LiAg IEFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0aGUgZmVlZGJhY2sgaXMgdGhhdCBub25lIG9mIHRoZSB0 aGluZ3MgeW91J3ZlIGxpc3RlZCBhcmUgcHJpb3JpdGllcywgYW5kIGZvciBnb29kIHJlYXNvbi4N Cg0KDQoNCsDMILjewM/AuiDB9sGktcggvPbD68DOuLjAuyDAp8fYIMDbvLq1x776wLi45ywgwd+/ 5MfRIMGkurizqiDA+sDbscfAuyDG98fUx8+w7SDA1sC7ILz2IMDWvcC0z7TZLiC+7rawx9EgscfH 0SC++MDMLCC6uyC5rrytv6EgxvfH1LXIIMGkurjAxyDA/LrOILbHtMIgwM+6zrimILmrtNzAuLfO IMGmM8Dav6Gw1CCw+LCzLCC56Mb3LCC6ubvnILbHtMIgu+e/68fPtMIgsM3AuyC+9rDdyPcgsd3B 9sfVtM+02S4guLi+4CwgursguN7Az8DMIMDfuPggwPy827XIILDmv+wsILnfvcXAziC2x7TCILTn u+e/oSC+y7fBwda9w7DtLCC6uyC43sDPwLsgwe+9wyC76MGmx8+/qSDB1r3DseIgudm2+LTPtNku DQpUaGlzIEUtbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kL29y IGNvcHlyaWdodCBtYXRlcmlhbC4gVGhpcyBlbWFpbCBpcyBpbnRlbmRlZCBmb3IgdGhlIHVzZSBv ZiB0aGUgYWRkcmVzc2VlIG9ubHkuIElmIHlvdSByZWNlaXZlIHRoaXMgZW1haWwgYnkgbWlzdGFr ZSwgcGxlYXNlIGVpdGhlciBkZWxldGUgaXQgd2l0aG91dCByZXByb2R1Y2luZywgZGlzdHJpYnV0 aW5nIG9yIHJldGFpbmluZyBjb3BpZXMgdGhlcmVvZiBvciBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseS4NCg== --_000_67EB6F85A7D7C04F9395712F712DAABC36C2EDFCMAILMBX02_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

I think IPv6 is co-existed with IPv4 for a while.<= /p>

Devices have dual stack with IPv4 and IPv6 address.

And there are cases that traces the problem with IPv4 & IPv6 add= ress information.

But, now there have no common key between them.

So, I think IPv6 information is included with device mac address for= tracing IPv4.

 

Utae.

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mudric, Dusan (Dusan)
Sent: Tuesday, February 14, 2017 6:26 AM
To: Ted Lemon
Cc: dhcwg; dhcp-users@lists.isc.org; Simon Hobson
Subject: Re: [dhcwg] RFC3315 DECLINE definition

 

Anyone els= e that would benefit from a list of devices (their MAC addresses) with assi= gned IPv6 addresses that are not valid or are unreachable?

 = ;

Dusan=

 

From: Ted Lemon [mailto= :mellon@fugue.com]
Sent: Monday, February 13, 2017 2:20 PM
To: Mudric, Dusan (Dusan)
Cc: Simon Hobson; dhcwg; dhcp-users@lists.isc.org
Subject: Re: [dhcwg] RFC3315 DECLINE definition

 

On Feb 13, 2017, at 11:00 AM, M= udric, Dusan (Dusan) <dmudric@avaya= .com> wrote:

I would like to get mor= e feedback from DHCPv6 users. Preferably, to prioritize the list below. Wha= t would be the number one priority item from this list that DHCPv6 users would like to address?=

 

You have gotten as much feedbac= k as you're likely to get on the working group mailing list.   As far = as I can tell, the feedback is that none of the things you've listed are pr= iorities, and for good reason.

 

 

=C0=CC =B8=DE=C0=CF=C0=BA =C1=F6=C1=A4=B5=C8 =BC=F6=C3=EB=C0=CE=B8=B8=C0=BB= =C0=A7=C7=D8 =C0=DB=BC=BA=B5=C7=BE=FA=C0=B8=B8=E7, =C1=DF=BF=E4=C7=D1 =C1= =A4=BA=B8=B3=AA =C0=FA=C0=DB=B1=C7=C0=BB =C6=F7=C7=D4=C7=CF=B0=ED =C0=D6=C0= =BB =BC=F6 =C0=D6=BD=C0=B4=CF=B4=D9. =BE=EE=B6=B0=C7=D1 =B1=C7=C7=D1 =BE=F8= =C0=CC, =BA=BB =B9=AE=BC=AD=BF=A1 =C6=F7=C7=D4=B5=C8 =C1=A4=BA=B8=C0=C7 =C0= =FC=BA=CE =B6=C7=B4=C2 =C0=CF=BA=CE=B8=A6 =B9=AB=B4=DC=C0=B8=B7=CE =C1=A63= =C0=DA=BF=A1=B0=D4 =B0=F8=B0=B3, =B9=E8=C6=F7, =BA=B9=BB=E7 =B6=C7=B4=C2 = =BB=E7=BF=EB=C7=CF=B4=C2 =B0=CD=C0=BB =BE=F6=B0=DD=C8=F7 =B1=DD=C1=F6=C7=D5= =B4=CF=B4=D9. =B8=B8=BE=E0, =BA=BB =B8=DE=C0=CF=C0=CC =C0=DF=B8=F8 =C0=FC= =BC=DB=B5=C8 =B0=E6=BF=EC, =B9=DF=BD=C5=C0=CE =B6=C7=B4=C2 =B4=E7=BB=E7=BF= =A1 =BE=CB=B7=C1=C1=D6=BD=C3=B0=ED, =BA=BB =B8=DE=C0=CF=C0=BB =C1=EF=BD=C3 = =BB=E8=C1=A6=C7=CF=BF=A9 =C1=D6=BD=C3=B1=E2 =B9=D9=B6=F8=B4=CF=B4=D9.
This E-mail may contain confidential information and/or copyright material.= This email is intended for the use of the addressee only. If you receive t= his email by mistake, please either delete it without reproducing, distribu= ting or retaining copies thereof or notify the sender immediately.

--_000_67EB6F85A7D7C04F9395712F712DAABC36C2EDFCMAILMBX02_-- From nobody Tue Feb 14 05:44:03 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4971294CE for ; Tue, 14 Feb 2017 05:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wpi.edu 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 O23xiUfB0m0u for ; Tue, 14 Feb 2017 05:43:59 -0800 (PST) Received: from MAIL1.WPI.EDU (mail1.wpi.edu [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id A80B91295D3 for ; Tue, 14 Feb 2017 05:43:59 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v1EDhwxh019537; Tue, 14 Feb 2017 08:43:58 -0500 DKIM-Filter: OpenDKIM Filter v2.10.3 MAIL1.WPI.EDU v1EDhwxh019537 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1487079838; bh=NPuEi67lblaMRpj5DVHYauV6/gfAuWCi6vcjNzbiuQc=; h=Date:From:To:Subject:References:In-Reply-To; b=Jylznj39nQApl2HSEKEeKBh/BRQkMe7UQMGMMr7xs1lEGDcOsjcaZMlAKXVtp59GO L+y8FQ2xSyvMZ0uMD9qMlnMI5xevR9d8THVNgCBMrbZwcLK4gWC4efofO4x3hEas8Q Dfo6js0OpF11dmFtTzq6GLWMTDiD29PXC5hj/ox0= Received: from milter1.wpi.edu (milter1.wpi.edu [130.215.36.49]) by MAIL1.WPI.EDU (8.15.1/8.15.1) with ESMTP id v1EDhwMC019534; Tue, 14 Feb 2017 08:43:58 -0500 Received: from angus.ind.wpi.edu (angus.ind.wpi.edu [130.215.130.21]) by milter1.wpi.edu (8.14.4/8.14.4) with ESMTP id v1EDhuVt000443; Tue, 14 Feb 2017 08:43:57 -0500 (envelope-from cra@WPI.EDU) Received: by angus.ind.wpi.edu (Postfix, from userid 10002) id D2908E0C23; Tue, 14 Feb 2017 08:43:56 -0500 (EST) Date: Tue, 14 Feb 2017 08:43:56 -0500 From: Chuck Anderson To: dhcp-users@lists.isc.org, dhcwg Message-ID: <20170214134356.GJ12074@angus.ind.wpi.edu> Mail-Followup-To: dhcp-users@lists.isc.org, dhcwg References: <9142206A0C5BF24CB22755C8EC422E457AA194E5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457AA19659@AZ-US1EXMB03.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA19659@AZ-US1EXMB03.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-PerlMx-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_MONEY_DENOMINATION 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __IN_REP_TO 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_URI_TEXT 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __STOCK_PHRASE_6 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_NO_NAME 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Subject: Re: [dhcwg] RFC3315 DECLINE definition X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 13:44:02 -0000 I do not think any of those statements are problems, or are problems that should be solved with any changes to the DHCPv6 protocol. On Mon, Feb 13, 2017 at 04:00:23PM +0000, Mudric, Dusan (Dusan) wrote: > I would like to get more feedback from DHCPv6 users. Preferably, to prioritize the list below. What would be the number one priority item from this list that DHCPv6 users would like to address? > > Thanks, > Dusan > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simon Hobson > Sent: Monday, February 13, 2017 9:57 AM > To: dhcwg > Subject: Re: [dhcwg] RFC3315 DECLINE definition > > "Mudric, Dusan (Dusan)" wrote: > > > PROBLEM STATEMENTS: > > - A network operator can set client IPv6 addresses on DHCPv6 server. > > That is the primary function of the DHCP server ! I don't see that as a problem. > > > An address can be invalid or make a client unreachable. > > There are a lot of other ways to bo**ox up a network ! > Such configurations may be deliberate. Until recently I did in fact run a network with unroutable (as in valid IP, but no router for that subnet) addresses because there was a policy decision that this particular network would be isolated - it was a backend network to carry traffic independently of the traffic on the public facing front end network. > > > - A network operator can change an address prefix on a router. A client address can become unreachable > > Ditto. > This is simply failing to co-ordinate network changes. Before removing/changing the prefix, the DHCP admin should have removed the pool IFF it is desired that the addresses be usable for external connectivity. As previously mentioned, this may be deliberate on the part of the Admin. > > > - A default router offering a prefix to a client can become unreachable. > > "Sh*t happens". Not only that, but what happens if the server hands out a load of IPv6 addresses which are all valid AT THE TIME OF ALLOCATION ? Even if your proposal were implemented, these addresses would be accepted and configured because they would be valid AT THE TIME OF ALLOCATION. The DHCP server and client cannot do anything about it if, say, 5 seconds into a 60 day lease, a router stops advertising a prefix appropriate to that address. > > It would be for the OS to detect that situation, and simply stop using that address for outbound connections. IMO it would be inappropriate for all the clients to somehow tell the server that all these addresses are bad - only to have 20,000 clients all contact the server again a few minutes later when the router comes back up and the prefix becomes valid again. That would be designing in network instability. > > > A client address can become unreachable on a local link > > ? > > > - A client does not release unused addresses > > So ? There's 2^64 addresses in a minimal IPv6 prefix. How many billion addresses do you intend using for each client ? Even if your 20,000 clients all took and held onto 1000 addresses each, that's still a tiny tiny fraction of the available addresses. > > > > > - A client validates the addresses and the address prefixes and notifies DHCPv6 server about the problems > > HOW ? > You will need to define the algorithm for validating addresses. So far you've only come up with "isn't on any prefix advertised by a router" (as above, not a valid test) and "in a deprecated prefix" (as mentioned in an earlier message, not a valid test). > > You will also need to define a mechanism whereby all clients can have the algorithm updated as policies change - eg prefixes get deprecated (as previously discussed), new prefixes come into use (eg I assume you would expect currently unused prefixes to be rejected, but they could come into use at any time when it's considered that they are needed). > You will also need to define a mechanism for the local admins to over-ride the stock algorithm - eg where the admins have made a policy decision to run isolated networks. This introduces a catch-22 situation where new devices might not be configurable (they won't attach to the network) until they have been configured (policy edited to allow them to connect). > > This is critical to your proposal - until you can come up with an easily defined, and robust, algorithm then your proposal CANNOT work. Worse, it may cause far more problems than it is supposed to solve. > > > > - A client returns unused addresses > > - DHCPv6 server: > > -- logs error messages (invalid & unreachable addresses with device IDs) > > -- does not assign the invalid addresses > > -- periodically checks for the reachability of unreachable addresses and, when they become reachable, assigns them again > > Define "valid" and "reachable" here ? > The implication from this and your earlier emails is that you define "reachable" as "has an IP which is routable to/from 'the internet'". See my comment above about running isolated networks, that backend isolated network runs a DHCP service - so the addresses on it are "reachable" in terms of "the DHCP server can reach them", but they aren't globally routable (they are actually RFC1918 IPv4 addresses, but the argument stands). > With a previous hat on, I had 2 Class C public IPv4 allocations which weren't globally routable. > > There is also the issue that the server (in the general case) CANNOT determine the reachability/routability of any prefix. There are plenty of network topologies where the server may lose connectivity to "something" while clients don't, or vice-versa, while connectivity between server and client network is still working. Similarly, there are topologies while server-client comms could be lost, while both still have connectivity to "something". This is the reason that, out of the box, DHCP4 servers in failover do NOT automatically go into partner-down state when they lose connectivity between them. > > > - An operator > > -- checks if there are unreachable devices and the reason codes > > An alternative: The site/organisation admins take care to co-ordinate changes, and test changes in configuration. They should employ monitoring to detect issues, and respond appropriately to helpdesk tickets. > Configuration management (and especially automation) will detect many of the issues you've raised. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=-9s7e0Ks0EQLldj5oI4E9zLJKH-0ehGNzPg6r665zKo&s=yZV16lh2Yih0GhvVieDz2J5SHShPy-iKWBYCkGKJkSo&e= > > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Mudric, Dusan (Dusan) > Sent: Monday, February 13, 2017 9:02 AM > To: dhcp-users; dhcwg > Subject: Re: [dhcwg] RFC3315 DECLINE definition > > Thanks to DHCWG group for their comments. I believe the proposals would benefit DHCv6 users. > > For the record: > > PROBLEM STATEMENTS: > - A network operator can set client IPv6 addresses on DHCPv6 server. An address can be invalid or make a client unreachable. > - A network operator can change an address prefix on a router. A client address can become unreachable > - A default router offering a prefix to a client can become unreachable. A client address can become unreachable on a local link > - A client does not release unused addresses > > PROPOSED FAILURE INDICATIONS > - A client validates the addresses and the address prefixes and notifies DHCPv6 server about the problems > - A client returns unused addresses > - DHCPv6 server: > -- logs error messages (invalid & unreachable addresses with device IDs) > -- does not assign the invalid addresses > -- periodically checks for the reachability of unreachable addresses and, when they become reachable, assigns them again > - An operator > -- checks if there are unreachable devices and the reason codes _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Qxk02ZIjaVguViwH6GFfRlZ1P5VOsYQOjA3jNkynsoA&s=2J3Xq9IQVsoMl7JTQP52olq6E_tc1b6kLGRuJ0RnkWE&e= From nobody Tue Feb 14 11:38:26 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945AD12978C for ; Tue, 14 Feb 2017 11:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 P-kdUcutQk4u for ; Tue, 14 Feb 2017 11:38:23 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EC0129781 for ; Tue, 14 Feb 2017 11:38:22 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id v23so120249452qtb.0 for ; Tue, 14 Feb 2017 11:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=HPvTnLGrRFPaknM04FDc+J/HxZMtUZ7dwWymoIxEQyE=; b=U4FTbX8oh7jcoEyDIr8RRQhuhoSZZyt1OXBLfW7nNiTe19qoLRXjmJcGDGLHxKgguK gSB85lVyeYzbSyHrrMlH1oh2xCssOGdKKa1SpCP9arhsjGAxjrrWNLdYGjUIkiH7Rfsk lobzgXQbDDk19+M29wc3hZC0YRxMt0KAngXxBujvpMSxzzVjbJOpxCP0wgg04wcZ9tPn tFwbgbSKKEiJ7JskCYzGlcJXMwfC+cyuoAyDCHCuySmssTkQ8z83dTolB35x/88DgjYg kZkJJIP1siVhRBskqGQVXdbA676jcl7E72FI05tAFM6mmCntVI+dqU4np9bnw1R96nx3 ivBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=HPvTnLGrRFPaknM04FDc+J/HxZMtUZ7dwWymoIxEQyE=; b=ClllycH4e7JzhcUB3v1CQqoTYbl0KIW7lVR4ghiPnOf8J+Uh21kANmId05bBZAAipK +MrhfXyJRAMDiWFucpTUB8SoqZAh2XA/QsYEEYQxb5ol2NeF344LlnwcPEaESliuADbF JV0mEUP92inbgtaPA+Us6x0vJ1W2JdUakbxBh7ArHadlsK3SBf/izlgocTQ4bQJthVUm GyxxM97/zl1hPOAUv8DtKZZ3vnpuRhwcrypyy5m8B7dU1mZzU4f3d5G7YzyPlf9011d+ 6zBIHU0PCqdx9O7QGIII5HkLBbO+RTxRWyLonxnL5NVgSP73D5kz29IDJ2LWsHt8ofZQ asvw== X-Gm-Message-State: AMke39lYSZaT228Sr8FYuP9+0snUcshiWjWxuqITWF743/UDotl8lsMfSg+7I3I8Mrhvzw== X-Received: by 10.200.36.41 with SMTP id c38mr30206572qtc.57.1487101102052; Tue, 14 Feb 2017 11:38:22 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:542:28e1:f0bb:93a5? ([2601:18f:801:600:542:28e1:f0bb:93a5]) by smtp.gmail.com with ESMTPSA id a1sm875494qkj.51.2017.02.14.11.38.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 11:38:21 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <67242207-4AE0-4E98-B345-FF0B10FD0EC5@gmail.com> Date: Tue, 14 Feb 2017 14:38:20 -0500 To: dhcwg X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [dhcwg] IETF-98 Coordinated Address Space Management (CASM) BoF X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 19:38:24 -0000 dhc WG participants may be interested in the Coordinated Address Space = Management (CASM) BoF: https://wiki.tools.ietf.org/bof/trac/ Topic mailing list: https://www.ietf.org/mailman/listinfo/casm - Ralph From nobody Tue Feb 14 13:20:28 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49591298A4 for ; Tue, 14 Feb 2017 13:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7SGWrp89ic2A for ; Tue, 14 Feb 2017 13:20:25 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDF212989C for ; Tue, 14 Feb 2017 13:20:25 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id u25so135276878qki.2 for ; Tue, 14 Feb 2017 13:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=P4ILWi8ybMldhupxwui5P0jWLaenbW1DZyzHud8vK3A=; b=btQyAKGPzDXUYjz0NfOiMY9Fdq90iBhlesz+8uX9vpTmhzOn54MuNndGVM4vqyL5qO 4nzjUsd4m0R7xMXOMbRlxc0fs4EZ+TZxE0l57J2DhqQcDKADdopDwNNWOdgnYFvRLHJT zNIqIiYwQyNNNbCoVRUWS2DKxb8ua8UmcrTRf1+76tToF5Mlftlzz9YeS5l5/gKsuo22 CO31/ngE42XP43SJkLwf9aYEBfrHPnd6ji01fsybFce6nsXiAXHO6jXYdsqgX6AO2HGN jLltkIPuKpivXNAD6lDLBaSuDhwYw/je3vt5HAvWHxpeoZw6DvHi9MgSYBmC71GZM6Qt 1/Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=P4ILWi8ybMldhupxwui5P0jWLaenbW1DZyzHud8vK3A=; b=s4cvTlPiP85WivRVWIJrHG7ltTprlfsTSvxx4TVWQUiLGrbZkiLQmX8MHggn0U97Wp 9svYxoIctMCZZosF3DwqbHZk3Qz6kmQ/oPEpc570j7l23DseiYICFpbeLoL+7tlgI7PN tb4wOjXl64m7FUKrOMojfFbB4FKsmbEn0RJy+L612I+NlXBdJrJPURUmtm1Y6ST7Qtce x8+D3w3MjQtz+w/kntDmmBcsCkpbWJTK23h4d4b3HcA0Y23jwNyEG7ypY31pBrC75OIH P/NjQcN/seQ9B8AzoSGO//4OTmJwu9wfIewB87NWFTPtnALxM1vJronHIz375ExkEyPK 2zUA== X-Gm-Message-State: AMke39l1HWZ6L95/vo/p6BpXVMrGaVh/BTeE8gjrcXNmCTNLa5sjQlRUEVxsR7r99frmqzzOrOqC9h90HLqs5A== X-Received: by 10.55.123.129 with SMTP id w123mr29070944qkc.20.1487107224029; Tue, 14 Feb 2017 13:20:24 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Tue, 14 Feb 2017 13:20:23 -0800 (PST) In-Reply-To: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 14 Feb 2017 13:20:23 -0800 X-Google-Sender-Auth: uNH2HIZBMegJ-5pgHv6veR-MVLo Message-ID: To: Lishan Li Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 21:20:27 -0000 At Mon, 13 Feb 2017 23:28:41 +0800, Lishan Li wrote: > > - general: it's still not clear to me how we use this mechanism for > > Reconfigure. > > > [LS]: According to my understanding: > 1. The server sends the encrypted Reconfigure message to the client; Encapsulated in an Encrypted-Response message? If so, with setting transaction-id to 0 (like Reconfigure itself)? And is the client supposed to try to decrypt it when transaction-id is 0 even if it doesn't match any outstanding Encrypted-Query it has sent? And in that case which private key should the client use? (For the last question, see also the comment on the assumption of the number of client certificate described in Section 6). I think these questions and issues can be addressed relatively easily, but I believe these should be clearly and explicitly described. > > The description of zero hash algorithm field seems to suggest the > > signature and hash algorithms are tightly related in practice. So > > it may be better to define the algorithm option so that > > signature/hash algorithms are listed as pairs. > > > [LS]: Yes. In some cases, the signature and hash algorithm are tightly > related and cannot be separate. Sorry that I don't understand that > "it may be better to define the algorithm option so that signature/hash > algorithms are listed as pairs", Could you please explain it more clearly? For example, instead of listing SA-id List and HA-id List separately, we might have unified SA-id List: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ALGORITHM | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . EA-id List . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . SA-id List . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (no "HA-id List" in this level) and each entry of SA-id List has two sub fields: signature algorithm ID and hash algorithm ID: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA-len | SA-id[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA-id[1] | SA-id[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA-id[2] | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA-id[n] | SA-id[n] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and each pair of (SA-id[i], HA-id[i]) will be considered to specify a specific signature method. > > - Section 6 > > > > The first DHCPv6 message sent from the client to the server, such as > > Solicit message, MUST contain the Certificate option, Signature > > option and Increasing-number option for client authentication.[...] > > [...] One and only one Increasing-number option SHOULD be > > contained, > > > > Isn't there a MUST vs SHOULD conflict here? > > > [LS]: The increasing-number option is optional, not must be contained. > In the before version of secure DHCPv6 without encryption, the timestamp > option is optional. But in fact, I don't know why it is optional. This doesn't address my question... > > - Section 6 > > > > [...] In this document, it is assumed > > that the client uses only one certificate for the encrypted DHCPv6 > > configuration. So, the corresponding private key is used for > > decryption. > > > > I'm not sure if this is okay. And, in fact, Section 11 talks about > > a case where multiple key pairs (so multiple certificates) are used: > > > > If the client tries more than one cert for client authentication, the > > server can easily get a client that implements this to enumerate its > > entire cert list and probably learn a lot about a client that way. > > > > Perhaps this is intended to handle encrypted Reconfigure? If that's > > the only reason for this limitation, I think we should address the > > reconfigure case in some other way and keep the general specification > > more flexible. > > > [LS]: So we deletes the description in section 11. I don't understand how this addresses the comment... > > - Section 9.1 > > > > [...] And the client can forget the increasing number > > information after the transaction is finished. The client's initial > > locally stored increasing number is set to zero. > > > > I'm not sure if I understand it and I'm not sure if it's okay > > whatever it means...does this mean the server can (or always does?) > > reset the increasing number to 0 for messages it sends to the server > > at the beginning of a new DHCPv6 session? Doesn't it lead to an > > easy replay attack? Or is the assumption that the server first > > sends an error and the client will resend the message with an > > adjusted increasing number? > > > [LS]: For the first received increasing-number option, the client cannot > check it and just need to change the local increasing number into the > received number. So for this purpose, i add the above statement. > Looking forward to your further guidance. I'd suggest consulting Ted here, as I guess the introduction of increasing-number option was originally his idea. > > - Section 10.1.1 > > > > The mandatory encryption > > algorithms MUST be included. > > > > Which algorithm is it? > > > [LS]: The mandatory encryption algorithm is RSA. How about the following > text: > The mandatory encryption algorithm, such as RSA, MUST be included. I don' know why "such as". I'd consider a particular algorithm(s) mandatory at the time of this document, and it/they should be explicitly defined here. > > - Section 10.1.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 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | EA-id | SA-id | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > . Certificate . > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > This seems to assume a single certificate (which I assume means a > > single public key) can be used for both encryption and signature. > > Is my understanding correct? If so, can we always assume that? > > > [LS]: Yes, it means a single certificate and a single public key. > If EA-id = 0 & SA-id !=0, then the public key is used for signature. > If EA-id != 0 & SA-id =0, then the public key is used for encryption. > If EA-id != 0 & SA-id !=0, then the public key is used for signature and > encryption. Ah, so if we want to use different algorithms and/or keys for signature and encryption, we have two certificate options, each setting EA-id or SA-id to 0? If so, I suggest explaining it explicitly. > > And, although it may be quite straightforward, I don't think this > > description is enough to actually calculate the tag value for a > > given public key. We should provide some more specific here. > > > [LS]: Add some more specific text about how to compute it? > In the before, I prepared some text about it. > Key Tag Calculation I've not read the entire text, but it looked like a bit too verbose. I'll see if I can offer some specific text. -- JINMEI, Tatuya From nobody Tue Feb 14 14:18:32 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB5C129454; Tue, 14 Feb 2017 14:18:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148711070864.9986.5446946904026153785.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 14:18:28 -0800 Archived-At: Cc: dhc-chairs@ietf.org, volz@cisco.com, dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue@ietf.org Subject: [dhcwg] Kathleen Moriarty's No Objection on draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 22:18:29 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm okay with the reasoning for the security considerations section, but think it might be good if a general reference for security of DHCP was listed as well. Since an older RFC is referenced, any references from that one might be out-of-date. From nobody Tue Feb 14 19:37:37 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BFF12949E; Tue, 14 Feb 2017 19:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ri6H_Q8f_Q9x; Tue, 14 Feb 2017 19:37:34 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A5112946C; Tue, 14 Feb 2017 19:37:34 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id 65so108616990otq.2; Tue, 14 Feb 2017 19:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FJzmW/Z1Jn6i46XqHa40w8iZw0QednhTY81kzKr4Ic8=; b=PzfPA+vixIgH1JchL6WlvLBByLhQgmzGQJETpn/scqep1a9DCi78mF+hfiiQ8uhetx WppMWpNbWBoQ25kDM+ccEIv2XBZqPfLnP/Vfg7XJ60KJAPKAiRzpNyUBQh1Kgyx97cpf dC7QOILJBKrwrpS/cxE/Qe5mgwbFGXRfN8oUH5X3eyVcKTe+hRRcHUB5ZUHOb4XtyolG +MXFkHjot8y9Wzi7ZKaW7OEvrie2SDMZ6hO/0eZ2wMkM+5mSjnRgbIURTDdVpjZmtQC+ 4SfReniRqa14P6tBEM/Ogr1b3uJRUdFqktNAy0HxTZfJBJA4sxBCg9961Y+EuBNQ8Zg8 iTEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FJzmW/Z1Jn6i46XqHa40w8iZw0QednhTY81kzKr4Ic8=; b=AgTkvrAdmLLMV0iRR6fwWtcJheyitgk1KEfg8OSo3xo6JHVg7XejSw7oW2S4YtUz/c FyqpYb1WALvaxbUdZ3XKrn2Odd1OiBY15sa9tDe6pZapIjMFHA1kKi2yVfYSghqrhM6e hg0Ws5RwKCOHdZSAcMjuTci/vDbBjPiIg/qfYdF9UYluezBzpAO+h5JeOT+yJANdImyp zbStewL7WfYGGAvlQKNjCuYCdNTGgY0KW0TqY4dGfoBidHSff1nlT20zStNJ6R55qiTx HqOeMLNgSybDdy4Q+97TUovmtD9SK3yQTCY7QUZPzMN+Po1r9OwRvqJsgKjmgbsdLER9 EK1w== X-Gm-Message-State: AMke39k6bxyexccHKW1OVfC8G5I5uT1x8Dv68oZs7ex5hge2vmcMJ1tOPnDfsoSGYQYafPrZgx92s/YQig/I2w== X-Received: by 10.157.7.53 with SMTP id 50mr16906765ote.91.1487129853420; Tue, 14 Feb 2017 19:37:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.1.202 with HTTP; Tue, 14 Feb 2017 19:36:53 -0800 (PST) In-Reply-To: <148711070864.9986.5446946904026153785.idtracker@ietfa.amsl.com> References: <148711070864.9986.5446946904026153785.idtracker@ietfa.amsl.com> From: tianxiang li Date: Wed, 15 Feb 2017 11:36:53 +0800 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a113f52d0a5ebfc05488966d5 Archived-At: Cc: dhc-chairs@ietf.org, Bernie Volz , The IESG , dhcwg , draft-ietf-dhc-dhcpv6-prefix-length-hint-issue@ietf.org Subject: Re: [dhcwg] Kathleen Moriarty's No Objection on draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 03:37:35 -0000 --001a113f52d0a5ebfc05488966d5 Content-Type: text/plain; charset=UTF-8 Hi Kathleen, Thank you for the review, please see inline. Cheers, Tianxiang 2017-02-15 6:18 GMT+08:00 Kathleen Moriarty < Kathleen.Moriarty.ietf@gmail.com>: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6- > prefix-length-hint-issue/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm okay with the reasoning for the security considerations section, but > think it might be good if a general reference for security of DHCP was > listed as well. Since an older RFC is referenced, any references from > that one might be out-of-date. > [Tianxiang] Thanks for pointing that out, we could add a sentence referencing RFC 3315 for security considerations in DHCP. However, as I understand both RFC 3633 and 3315 would be obsoleted by draft-ietf-dhc-rfc3315bis once it's approved, should we add reference to 3315bis instead? My current proposal is as follow: OLD: This document introduces no new security considerations over those already discussed in section 15 of RFC3633, as this document provides guidance on how the clients and servers interact with regard to the prefix-length hint mechanism introduced in RFC3633. NEW: This document provides guidance on how the clients and servers interact with regard to the DHCPv6 prefix-length hint mechanism. Security considerations in DHCP are described in section 23 of RFC 3315. Security considerations regarding DHCPv6 prefix delegation are described in section 15 of RFC 3633. --001a113f52d0a5ebfc05488966d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kathleen,

Thank you for the review, = please see inline.

Cheers,
Tianxiang

2017-02-15 6:18= GMT+08:00 Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.= com>:
Ka= thleen Moriarty has entered the following ballot position for
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.= ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/<= br>


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I'm okay with the reasoning for the security considerations section, bu= t
think it might be good if a general reference for security of DHCP was
listed as well.=C2=A0 Since an older RFC is referenced, any references from=
that one might be out-of-date.

[Tianxia= ng] Thanks for pointing that out, we could add a sentence referencing RFC 3= 315 for security considerations in DHCP. However, as I understand both RFC = 3633 and 3315 would be obsoleted by=C2=A0draft-ietf-dhc-rfc3315bis once it&= #39;s approved, should we add reference to 3315bis instead? My current prop= osal is as follow:

OLD:=C2=A0
This docum= ent introduces no new security considerations over those already discussed = in section 15 of RFC3633, as this document provides guidance on how the cli= ents and servers interact with regard to the prefix-length hint mechanism i= ntroduced in RFC3633.=C2=A0

NEW:=C2=A0
T= his document provides guidance on how the clients and servers interact with= regard to the DHCPv6 prefix-length hint mechanism. Security considerations= in DHCP are described in section 23 of RFC 3315. Security considerations r= egarding DHCPv6 prefix delegation are described in section 15 of RFC 3633.<= /div>

--001a113f52d0a5ebfc05488966d5-- From nobody Wed Feb 15 02:03:47 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 278AA129410; Wed, 15 Feb 2017 02:03:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148715302215.17389.14651452070558302618.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 02:03:42 -0800 Archived-At: Cc: dhc-chairs@ietf.org, volz@cisco.com, dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue@ietf.org Subject: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-dhcpv6-prefix-length-hint-issue-05=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 10:03:42 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think it would make sense if this doc updates RFC 3633 because someone who (newly) implements RFC 3633 should really also read this document and hance needs this pointer. Also, I would move section 3.6 to the beginning but that doesn't really matter. From nobody Wed Feb 15 03:46:32 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC98129470 for ; Wed, 15 Feb 2017 03:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 D3T0bBrwFLgS for ; Wed, 15 Feb 2017 03:46:28 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7620127735 for ; Wed, 15 Feb 2017 03:46:28 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id v23so134715674qtb.0 for ; Wed, 15 Feb 2017 03:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a1/8uqIbK8e2llL5KltnEUg3gHPISf0Yox3gwsRwBsg=; b=uZgriojSy7daHrrh3yjVm74uEkKPQXsipwKaxN36+xAMGgPtr7KdO2G1a4rEeUePJd cCbxQOCSdqNSRFjSPgAxyf6ZXdvFknHdvY/lbxRPcOBhdEfOIeE/qKExaJTz6BpEnrbL xz/n7AGxfu2pXcqSZShBPBOKqdLCzXZZS7xezRPzXMP6lIPZv64VlyFLZgq8E4Eca2hp 1sj/hrDaffhpmCVxQtQc9fXhrlApxQINrLV7Zm/VeB4MFMPlAcCSRd1RxAlNXI+LwWca TF+YuWYC6Xw/X1BvE18oQRsp9A21GLmtPm4LAr6hDGQpll6cCCkKi5lwW9pHDoFzBrbM n4iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a1/8uqIbK8e2llL5KltnEUg3gHPISf0Yox3gwsRwBsg=; b=IOb/uWZi0Df+rfcY+hTubzmCOoXR4BFj76Vr1EfYGRV0UTEq0rJi65CZbPSfTHJcyT VCyz4YU40oIBskYNGcu5EMuUdpy58ljK/GfRL/RdDgiwB1gQB9YTiVaI7t7Ndlg7VDwU 6QGzJ+vd0QFTeVPaYdgx24O0O5hMvT3A/uJZqY7nrAwFnkhuINJnQaqV+/gjvfW7Pf8x A03u28aMU8Pn5Nm7pW2Y9sMaSyyNd77C7lOiRf1vj+S1siySH40YZJgSxDgAXYk8CpRb 2fA1yZTGo725IhDqouYgHcupe97Z9oEJhraBrl9pRoalsA+3/MnAEkhpviF8pxuKHjYw hghw== X-Gm-Message-State: AMke39m+6Wsoy73NzHIdCAkS3BpwWHOThkosmfDn3psJLxeKCP+fSYQCZUv/SWMyEzPMZnBcFAyIeB3bVYjNuw== X-Received: by 10.237.61.8 with SMTP id g8mr32263683qtf.91.1487159187753; Wed, 15 Feb 2017 03:46:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.46.172 with HTTP; Wed, 15 Feb 2017 03:46:27 -0800 (PST) In-Reply-To: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> From: Lishan Li Date: Wed, 15 Feb 2017 19:46:27 +0800 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Ted Lemon Content-Type: multipart/alternative; boundary=001a11417c781c5a3c0548903b87 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 11:46:31 -0000 --001a11417c781c5a3c0548903b87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2017-02-15 5:20 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 : > At Mon, 13 Feb 2017 23:28:41 +0800, > Lishan Li wrote: > > > > - general: it's still not clear to me how we use this mechanism for > > > Reconfigure. > > > > > [LS]: According to my understanding: > > 1. The server sends the encrypted Reconfigure message to the client; > > Encapsulated in an Encrypted-Response message? If so, with setting > transaction-id to 0 (like Reconfigure itself)? And is the client > supposed to try to decrypt it when transaction-id is 0 even if it > doesn't match any outstanding Encrypted-Query it has sent? And in > that case which private key should the client use? (For the last > question, see also the comment on the assumption of the number of > client certificate described in Section 6). > > I think these questions and issues can be addressed relatively easily, > but I believe these should be clearly and explicitly described. > [LS]: How about the following method: The transaction-id of the Encrypted-Reponse message MUST be equal with the transaction-id of the received Encrypted-Query message and cannot be zero. In this way, the client will try to decrypt it. > > > > The description of zero hash algorithm field seems to suggest the > > > signature and hash algorithms are tightly related in practice. So > > > it may be better to define the algorithm option so that > > > signature/hash algorithms are listed as pairs. > > > > > [LS]: Yes. In some cases, the signature and hash algorithm are tightly > > related and cannot be separate. Sorry that I don't understand that > > "it may be better to define the algorithm option so that signature/hash > > algorithms are listed as pairs", Could you please explain it more > clearly? > > For example, instead of listing SA-id List and HA-id List separately, > we might have unified SA-id List: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_ALGORITHM | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . EA-id List . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . SA-id List . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > (no "HA-id List" in this level) > > and each entry of SA-id List has two sub fields: signature algorithm > ID and hash algorithm ID: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SA-len | SA-id[1] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | HA-id[1] | SA-id[2] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | HA-id[2] | ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SA-id[n] | SA-id[n] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > and each pair of (SA-id[i], HA-id[i]) will be considered to specify a > specific signature method. > [LS]: So, for every SA-id, there is a corresponding HA-id or multiple HA-id(s). SA-id and HA-id are set to a pair. Right? > > > - Section 6 > > > > > > The first DHCPv6 message sent from the client to the server, such = as > > > Solicit message, MUST contain the Certificate option, Signature > > > option and Increasing-number option for client authentication.[...= ] > > > [...] One and only one Increasing-number option SHOULD be > > > contained, > > > > > > Isn't there a MUST vs SHOULD conflict here? > > > > > [LS]: The increasing-number option is optional, not must be contained. > > In the before version of secure DHCPv6 without encryption, the timestam= p > > option is optional. But in fact, I don't know why it is optional. > > This doesn't address my question... > [LS]: Sorry. Will correct it. > > > > - Section 6 > > > > > > [...] In this document, it is assumed > > > that the client uses only one certificate for the encrypted DHCPv6 > > > configuration. So, the corresponding private key is used for > > > decryption. > > > > > > I'm not sure if this is okay. And, in fact, Section 11 talks about > > > a case where multiple key pairs (so multiple certificates) are used= : > [LS]: We have discussed this issues before. In most cases, a client will not uses multiple certificate(s) for the encrypted DHCPv6 configuration process in the same time. Please see the following reasons: After the client authentication, the client will use the public key in the certificate option for encryption. The server only knows one client's public key for encryption. And the client will also only uses one private key for decryption. So there is no cases that the client will use one key pair for the encryption of some DHCPv6 messages and use another key pair for the encryption of another DHCPv6 messages. > > > > > > If the client tries more than one cert for client authentication, > the > > > server can easily get a client that implements this to enumerate i= ts > > > entire cert list and probably learn a lot about a client that way. > > > > > > Perhaps this is intended to handle encrypted Reconfigure? [LS]: No, this is not designed for the encrypted Reconfigure. This is different from the above issue. We consider the scenario where the client has multiple certs. In the authentication process, if one cert of the client fails, the client may send another cert for authentication. But once the authentication successes, then the client and server will only uses the authenticated public key for encryption. > If that's > > > the only reason for this limitation, I think we should address the > > > reconfigure case in some other way and keep the general specificatio= n > > > more flexible. > > > > [LS]: So we deletes the description in section 11. > > I don't understand how this addresses the comment... > > > - Section 9.1 > > > > > > [...] And the client can forget the increasing number > > > information after the transaction is finished. The client's initi= al > > > locally stored increasing number is set to zero. > > > > > > I'm not sure if I understand it and I'm not sure if it's okay > > > whatever it means...does this mean the server can (or always does?) > > > reset the increasing number to 0 for messages it sends to the serve= r > > > at the beginning of a new DHCPv6 session? Doesn't it lead to an > > > easy replay attack? Or is the assumption that the server first > > > sends an error and the client will resend the message with an > > > adjusted increasing number? > > > > > [LS]: For the first received increasing-number option, the client canno= t > > check it and just need to change the local increasing number into the > > received number. So for this purpose, i add the above statement. > > Looking forward to your further guidance. > > I'd suggest consulting Ted here, as I guess the introduction of > increasing-number option was originally his idea. > [LS]: Will send another email to Ted for his comment. > > > > - Section 10.1.1 > > > > > > The mandatory encryption > > > algorithms MUST be included. > > > > > > Which algorithm is it? > > > > > [LS]: The mandatory encryption algorithm is RSA. How about the followin= g > > text: > > The mandatory encryption algorithm, such as RSA, MUST be included. > > I don' know why "such as". I'd consider a particular algorithm(s) > mandatory at the time of this document, and it/they should be > explicitly defined here. [LS]: Got it. > > > > - Section 10.1.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 | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | EA-id | SA-id | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | > > > . Certificate . > > > | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > This seems to assume a single certificate (which I assume means a > > > single public key) can be used for both encryption and signature. > > > Is my understanding correct? If so, can we always assume that? > > > > > [LS]: Yes, it means a single certificate and a single public key. > > If EA-id =3D 0 & SA-id !=3D0, then the public key is used for signature= . > > If EA-id !=3D 0 & SA-id =3D0, then the public key is used for encryptio= n. > > If EA-id !=3D 0 & SA-id !=3D0, then the public key is used for signatur= e and > > encryption. > > Ah, so if we want to use different algorithms and/or keys for > signature and encryption, we have two certificate options, each > setting EA-id or SA-id to 0? If so, I suggest explaining it > explicitly. > [LS]: Yes. Will explain it more clearly. > > > > And, although it may be quite straightforward, I don't think this > > > description is enough to actually calculate the tag value for a > > > given public key. We should provide some more specific here. > > > > > [LS]: Add some more specific text about how to compute it? > > In the before, I prepared some text about it. > > Key Tag Calculation > > I've not read the entire text, but it looked like a bit too verbose. > I'll see if I can offer some specific text. > [LS]: Agree. Looking forward to your contributed text. --001a11417c781c5a3c0548903b87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017-02-15 5:20 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 <jinmei@wide.ad.jp>:
At Mon, 13 Feb 2017= 23:28:41 +0800,
Lishan Li <lili= shan48@gmail.com> wrote:

> > - general: it's still not clear to me how we use this mechani= sm for
> >=C2=A0 =C2=A0Reconfigure.
> >
> [LS]: According to my understanding:
> 1. The server sends the encrypted Reconfigure message to the client;
Encapsulated in an Encrypted-Response message?=C2=A0 If so, with set= ting
transaction-id to 0 (like Reconfigure itself)?=C2=A0 And is the client
supposed to try to decrypt it when transaction-id is 0 even if it
doesn't match any outstanding Encrypted-Query it has sent?=C2=A0 And in=
that case which private key should the client use?=C2=A0 (For the last
question, see also the comment on the assumption of the number of
client certificate described in Section 6).

I think these questions and issues can be addressed relatively easily,
but I believe these should be clearly and explicitly described.
[LS]: How about the following method:
The transaction-i= d of the Encrypted-Reponse message MUST be equal with the transaction-id of= the received Encrypted-Query message and cannot be zero. In this way, the = client will try to decrypt it.

> >=C2=A0 =C2=A0The description of zero hash algorithm field seems to= suggest the
> >=C2=A0 =C2=A0signature and hash algorithms are tightly related in = practice.=C2=A0 So
> >=C2=A0 =C2=A0it may be better to define the algorithm option so th= at
> >=C2=A0 =C2=A0signature/hash algorithms are listed as pairs.
> >
> [LS]: Yes. In some cases, the signature and hash algorithm are tightly=
> related and cannot be separate. Sorry that I don't understand that=
> "it may be better to define the algorithm option so that signatur= e/hash
> algorithms are listed as pairs", Could you please explain it more= clearly?

For example, instead of listing SA-id List and HA-id List separately= ,
we might have unified SA-id List:

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 OPTION_ALGORITHM=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option-len=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EA-id List=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SA-id List=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
(no "HA-id List" in this level)

and each entry of SA-id List has two sub fields: signature algorithm
ID and hash algorithm ID:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SA-len=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SA-id[1]= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HA-id[1]=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SA-id[2]=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HA-id[2]=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SA-id[n]=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SA-id[n]=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

and each pair of (SA-id[i], HA-id[i]) will be considered to specify a
specific signature method.
[LS]: So, for every SA-id, = there is a corresponding HA-id or multiple HA-id(s).
SA-id and HA= -id are set to a pair. Right?


> > - Section 6
> >
> >=C2=A0 =C2=A0 The first DHCPv6 message sent from the client to the= server, such as
> >=C2=A0 =C2=A0 Solicit message, MUST contain the Certificate option= , Signature
> >=C2=A0 =C2=A0 option and Increasing-number option for client authe= ntication.[...]
> >=C2=A0 =C2=A0 [...]=C2=A0 One and only one Increasing-number optio= n SHOULD be
> >=C2=A0 =C2=A0 contained,
> >
> >=C2=A0 =C2=A0Isn't there a MUST vs SHOULD conflict here?
> >
> [LS]: The increasing-number option is optional, not must be contained.=
> In the before version of secure DHCPv6 without encryption, the timesta= mp
> option is optional. But in fact, I don't know why it is optional.<= br>
This doesn't address my question...
[LS]: S= orry. Will correct it.=C2=A0

> > - Section 6
> >
> >=C2=A0 =C2=A0 [...] In this document, it is assumed
> >=C2=A0 =C2=A0 that the client uses only one certificate for the en= crypted DHCPv6
> >=C2=A0 =C2=A0 configuration.=C2=A0 So, the corresponding private k= ey is used for
> >=C2=A0 =C2=A0 decryption.
> >
> >=C2=A0 =C2=A0I'm not sure if this is okay.=C2=A0 And, in fact,= Section 11 talks about
> >=C2=A0 =C2=A0a case where multiple key pairs (so multiple certific= ates) are used:
[LS]: We have discussed this is= sues before.=C2=A0
In most cases, a client will not uses multiple= certificate(s) for the encrypted DHCPv6 configuration process in the same = time. Please see the following reasons:
After the client authenti= cation, the client will use the public key in the certificate option for en= cryption. The server only knows one client's public key for encryption.= And the client will also only uses one private key for decryption. So ther= e is no cases that the client will use one key pair for the encryption of s= ome DHCPv6 messages and use another key pair for the encryption of another = DHCPv6 messages.=C2=A0
> >
> >=C2=A0 =C2=A0 If the client tries more than one cert for client au= thentication, the
> >=C2=A0 =C2=A0 server can easily get a client that implements this = to enumerate its
> >=C2=A0 =C2=A0 entire cert list and probably learn a lot about a cl= ient that way.
> >
> >=C2=A0 Perhaps this is intended to handle encrypted Reconfigure?= =C2=A0
[LS]: No, this is not designed for the encr= ypted Reconfigure. This is different from the above issue.
We con= sider the scenario where the client has multiple certs. In the authenticati= on process, if one cert of the client fails, the client may send another ce= rt for authentication. But once the authentication successes, then the clie= nt and server will only uses the authenticated public key for encryption.
If that's
> >=C2=A0 the only reason for this limitation, I think we should addr= ess the
> >=C2=A0 reconfigure case in some other way and keep the general spe= cification
> >=C2=A0 more flexible.=C2=A0
> >
> [LS]: So we deletes the description in section 11.

I don't understand how this addresses the comment...=C2=A0

> > - Section 9.1
> >
> >=C2=A0 =C2=A0 [...]=C2=A0 And the client can forget the increasing= number
> >=C2=A0 =C2=A0 information after the transaction is finished.=C2=A0= The client's initial
> >=C2=A0 =C2=A0 locally stored increasing number is set to zero.
> >
> >=C2=A0 =C2=A0I'm not sure if I understand it and I'm not s= ure if it's okay
> >=C2=A0 =C2=A0whatever it means...does this mean the server can (or= always does?)
> >=C2=A0 =C2=A0reset the increasing number to 0 for messages it send= s to the server
> >=C2=A0 =C2=A0at the beginning of a new DHCPv6 session?=C2=A0 Doesn= 't it lead to an
> >=C2=A0 =C2=A0easy replay attack?=C2=A0 Or is the assumption that t= he server first
> >=C2=A0 =C2=A0sends an error and the client will resend the message= with an
> >=C2=A0 =C2=A0adjusted increasing number?
> >
> [LS]: For the first received increasing-number option, the client cann= ot
> check it and just need to change the local increasing number into the<= br> > received number. So for this purpose, i add the above statement.
> Looking forward to your further guidance.

I'd suggest consulting Ted here, as I guess the introduction of<= br> increasing-number option was originally his idea.
[LS]= : Will send another email to Ted for his comment.=C2=A0

> > - Section 10.1.1
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The mandat= ory encryption
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 algorithms= MUST be included.
> >
> >=C2=A0 =C2=A0Which algorithm is it?
> >
> [LS]: The mandatory encryption algorithm is RSA. How about the followi= ng
> text:
> The mandatory encryption algorithm, such as RSA, MUST be included.

I don' know why "such as".=C2=A0 I'd consider a pa= rticular algorithm(s)
mandatory at the time of this document, and it/they should be
explicitly defined here.=C2=A0
[LS]: Got it.=C2=A0

> > - Section 10.1.2
> >
> >=C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
> >=C2=A0 =C2=A0 =C2=A00 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
> >=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
> >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 OPTION_CERTIFICATE=C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option-len=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
> >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EA= -id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 SA-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
> >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> >=C2=A0 =C2=A0 .=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Certificate=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0.
> >=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> >=C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
> >
> >=C2=A0 =C2=A0This seems to assume a single certificate (which I as= sume means a
> >=C2=A0 =C2=A0single public key) can be used for both encryption an= d signature.
> >=C2=A0 =C2=A0Is my understanding correct?=C2=A0 If so, can we alwa= ys assume that?
> >
> [LS]: Yes, it means a single certificate and a single public key.
> If EA-id =3D 0 & SA-id !=3D0, then the public key is used for sign= ature.
> If EA-id !=3D 0 & SA-id =3D0, then the public key is used for encr= yption.
> If EA-id !=3D 0 & SA-id !=3D0, then the public key is used for sig= nature and
> encryption.

Ah, so if we want to use different algorithms and/or keys for
signature and encryption, we have two certificate options, each
setting EA-id or SA-id to 0?=C2=A0 If so, I suggest explaining it
explicitly.
[LS]: Yes. Will explain it more clearly.= =C2=A0

> >=C2=A0 =C2=A0And, although it may be quite straightforward, I don&= #39;t think this
> >=C2=A0 =C2=A0description is enough to actually calculate the tag v= alue for a
> >=C2=A0 =C2=A0given public key.=C2=A0 We should provide some more s= pecific here.
> >
> [LS]: Add some more specific text about how to compute it?
> In the before, I prepared some text about it.
>=C2=A0 Key Tag Calculation

I've not read the entire text, but it looked like a bit too verb= ose.
I'll see if I can offer some specific text.
[LS]: = Agree. Looking forward to your contributed text.=C2=A0

--001a11417c781c5a3c0548903b87-- From nobody Wed Feb 15 09:51:40 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D637B1296B5 for ; Wed, 15 Feb 2017 09:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Hwe2q0ZBjvsx for ; Wed, 15 Feb 2017 09:51:38 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8043A1296C5 for ; Wed, 15 Feb 2017 09:51:38 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id x49so143558966qtc.2 for ; Wed, 15 Feb 2017 09:51:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3X+4yFT2AOhmv4Vq2vBgIk0YYq0fiD/fXWkDqTG/SbM=; b=O59Qsa78j5k6lK3SC3Mob7WU3QjdQmnxXOqiV3lMjYbfluAJPjG+Z1NBpCe9F9yOEz r+jSNv1FMDI6iAOIquM0cHWiW5N7jmEzNLprtdn4JKlN0niUa0mjAKwXqWw0lzqCW5WA Mj17402XWW7cx2Ep9s2CY4oaClmDxsztUwjaNj8y42tTyOkFU3/h7rOgrdcsb7euEute 7/vQBT3BN+zErzlYu5msUahgYUFuGaQVhhbmxSY7sIoV3NbHhEOscAgyGM3HCrQPTC7F bu58d86aXDxiTy0V0cJnid98kUT/pky3aqQWRvS3LRqmcJLNOz95szkVLGWD2yiwwKP9 EU6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3X+4yFT2AOhmv4Vq2vBgIk0YYq0fiD/fXWkDqTG/SbM=; b=dT5Xd+6JTuY/eSYGS5RWv2FQcz1TLTOJFWvB5vnNOQrv8zkUGpcyX5g27zhFP9y9jO OxAzAXe5VbbmGNppfT/t02UThVZyLF+h1Jt35zCSYQoaoTN2WhuBoyLFYnu/A/BsgmHn EH4jHGOHiVqpUre9B0nxZWo3gOjfs5K9rDN8juMV8j2XrGG48CPAIyZepyNHyCMhivDZ LcDlf9Cp4mPTgs3Y+6OtGxQE02AfDsFtUlCvRRvLHtVn24pHfIMXOJ2Q6lYBVCCHFQLc n8CF814uSzTgeGmU6BUoGNriwOuf0LzCZmPzjFUlcCZN7L18ua2EuUPq1LATacU6BkF+ rKgA== X-Gm-Message-State: AMke39nP09q8b+RN6YOV6v+byEBKu48mSA3h578UhwnuoQ4CAEEdh/jqR0WgVk8XvxQ4VX3uxpwXbO7bx0n+Wg== X-Received: by 10.200.34.12 with SMTP id o12mr33838060qto.93.1487181097544; Wed, 15 Feb 2017 09:51:37 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Wed, 15 Feb 2017 09:51:37 -0800 (PST) In-Reply-To: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 15 Feb 2017 09:51:37 -0800 X-Google-Sender-Auth: _BceCPzAoCdOmUrL1Y3KO9wZyq0 Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 17:51:40 -0000 At Fri, 10 Feb 2017 22:46:58 +0000, "Templin, Fred L" wrote: > Hi, I have not reviewed this latest version of the draft but in my understanding > from past discussions is that this mechanism always encrypts and there is no > longer an "authentication-only" mode. That being the case, if this work is to go > forward the WG must first resurrect the Relay Agent Assignment Notification > (RAAN) draft: > > https://www.ietf.org/mail-archive/web/dhcwg/current/msg17651.html > > Otherwise, sedhcpv6 would be incompatible with Relays that must glean route > information during DHCPv6 PD exchanges. I've realized I misunderstood the meaning of zero IA-id (it doesn't mean skipping encryption). So, yes, it's incompatible with such peeking relays. It's probably better to describe the issue in sedhcpv6 with a reference to the RAAN draft as a possible future solution to it if and when it's adopted and standardized. -- JINMEI, Tatuya From nobody Wed Feb 15 10:07:39 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF3F12950D for ; Wed, 15 Feb 2017 10:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 CbtBPK-pnIx0 for ; Wed, 15 Feb 2017 10:07:36 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D375B129541 for ; Wed, 15 Feb 2017 10:07:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1FI7aSi062043; Wed, 15 Feb 2017 11:07:36 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1FI7U0F061966 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 15 Feb 2017 11:07:30 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 15 Feb 2017 10:07:30 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 15 Feb 2017 10:07:30 -0800 From: "Templin, Fred L" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSglOjbTsgor1qYk63PeyrUa0poqFi1e9wgAgT1ID//3y08A== Date: Wed, 15 Feb 2017 18:07:29 +0000 Message-ID: <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:07:38 -0000 SGkgSmlubWVpLXNhbiwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBq aW5tZWkudGF0dXlhQGdtYWlsLmNvbSBbbWFpbHRvOmppbm1laS50YXR1eWFAZ21haWwuY29tXSBP biBCZWhhbGYgT2YgPz8/Pw0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDE3IDk6 NTIgQU0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4N Cj4gQ2M6IExpc2hhbiBMaSA8bGlsaXNoYW40OEBnbWFpbC5jb20+OyBkaGN3ZyA8ZGhjd2dAaWV0 Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQNCj4gDQo+IEF0IEZyaSwgMTAg RmViIDIwMTcgMjI6NDY6NTggKzAwMDAsDQo+ICJUZW1wbGluLCBGcmVkIEwiIDxGcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gDQo+ID4gSGksIEkgaGF2ZSBub3QgcmV2aWV3ZWQg dGhpcyBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQgYnV0IGluIG15IHVuZGVyc3RhbmRpbmcN Cj4gPiBmcm9tIHBhc3QgZGlzY3Vzc2lvbnMgaXMgdGhhdCB0aGlzIG1lY2hhbmlzbSBhbHdheXMg ZW5jcnlwdHMgYW5kIHRoZXJlIGlzIG5vDQo+ID4gbG9uZ2VyIGFuICJhdXRoZW50aWNhdGlvbi1v bmx5IiBtb2RlLiBUaGF0IGJlaW5nIHRoZSBjYXNlLCBpZiB0aGlzIHdvcmsgaXMgdG8gZ28NCj4g PiBmb3J3YXJkIHRoZSBXRyBtdXN0IGZpcnN0IHJlc3VycmVjdCB0aGUgUmVsYXkgQWdlbnQgQXNz aWdubWVudCBOb3RpZmljYXRpb24NCj4gPiAoUkFBTikgZHJhZnQ6DQo+ID4NCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RoY3dnL2N1cnJlbnQvbXNnMTc2NTEuaHRt bA0KPiA+DQo+ID4gT3RoZXJ3aXNlLCBzZWRoY3B2NiB3b3VsZCBiZSBpbmNvbXBhdGlibGUgd2l0 aCBSZWxheXMgdGhhdCBtdXN0IGdsZWFuIHJvdXRlDQo+ID4gaW5mb3JtYXRpb24gZHVyaW5nIERI Q1B2NiBQRCBleGNoYW5nZXMuDQo+IA0KPiBJJ3ZlIHJlYWxpemVkIEkgbWlzdW5kZXJzdG9vZCB0 aGUgbWVhbmluZyBvZiB6ZXJvIElBLWlkIChpdCBkb2Vzbid0DQo+IG1lYW4gc2tpcHBpbmcgZW5j cnlwdGlvbikuICBTbywgeWVzLCBpdCdzIGluY29tcGF0aWJsZSB3aXRoIHN1Y2gNCj4gcGVla2lu ZyByZWxheXMuDQoNClRoYW5rcyBmb3IgY29uZmlybWluZy4NCg0KPiBJdCdzIHByb2JhYmx5IGJl dHRlciB0byBkZXNjcmliZSB0aGUgaXNzdWUgaW4NCj4gc2VkaGNwdjYgd2l0aCBhIHJlZmVyZW5j ZSB0byB0aGUgUkFBTiBkcmFmdCBhcyBhIHBvc3NpYmxlIGZ1dHVyZQ0KPiBzb2x1dGlvbiB0byBp dCBpZiBhbmQgd2hlbiBpdCdzIGFkb3B0ZWQgYW5kIHN0YW5kYXJkaXplZC4NCg0KSWYgc2VkaGNw djYgd2lsbCBub3Qgc3VwcG9ydCBhbiBhdXRoZW50aWNhdGlvbi1vbmx5IG1vZGUsIHRoZW4gaXQN CmNhbicgdCBnbyBmb3J3YXJkIHVudGlsIFJBQU4gaXMgYWRvcHRlZCBhcyBhIHdnIGl0ZW0uIE90 aGVyd2lzZSwNCmFuIGVuY3J5cHRpb24tb25seSBzZWRoY3B2NiB3L28gUkFBTiB3b3VsZCBicmVh ayBESENQdjYgUEQuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20N Cg0KPiAtLQ0KPiBKSU5NRUksIFRhdHV5YQ0KDQo= From nobody Wed Feb 15 10:33:00 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25968129B1E for ; Wed, 15 Feb 2017 10:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 G1ZLuE9QMS4o for ; Wed, 15 Feb 2017 10:32:58 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE358129B13 for ; Wed, 15 Feb 2017 10:32:57 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id u25so159990554qki.2 for ; Wed, 15 Feb 2017 10:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=P85m8wxEPi5H/6quAS2ujAG1Z7e7wXx8/L6pDyf/9Xc=; b=t3eHX/HPxOw1K5kDlEMSaWTxyGQ1zuV9NLnwjdKzVy669ZPdf/5bKEIoUzwoyitpqt wiPHUiXJJw4cNik8PHK0HRc46rj/RCNsYtW6yqNGVmtuk1tNtqYT3cSFGBUQ7w/rvdTG eo1NP5AxmY9pzfRK+IGQ58I8JT80mKv3vzmiPKp1StPucCzC90bFSSKDCZSX7k9jW0k1 zh0yHCay6gchyS86e0GJtfnBIJd4WxSKYu+sZSctvX35Xef2f70LBbplXuU71KBsKd0O gFzv/HwWsSDNzGj++xQwnKm+sqs4/NE34dabbkKJNsSRfmJwfVH4BsqT97P3SdMCnWQ9 DtyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=P85m8wxEPi5H/6quAS2ujAG1Z7e7wXx8/L6pDyf/9Xc=; b=ETGkO/bm2zCPEzBkGFRMVCBrBlp6Pqmi1ZrAPpbCdjIPEzKPbBCPKMqAU0HO8VRxL+ RSI4lF4AUhOuj3zCC3lcD4vGwnzW0i4B7gySoDzUtv7omXcvOaL35G74kjwd4H7eGmpp G+8P7ozMYEBITVMmYfgQeMuRpWTifFQ1NEXwcMReMRM2w201KZ2RhzGAVbeh47qy312x o6oaNbF86R6swvsJJJrK4Ogl9p6wdgQYOYw0wVycOZj+nKjVxFubZqDYkQq3k5doVFTh CJ+8vbRkRD4icBpeSAqKqJNQJD9Et76H2whbNdnXVAHTbdRZGjACmYcU4dbwZX5TwQFZ GGqQ== X-Gm-Message-State: AMke39nCgeCt8rmjfDgdGnulwcz9FQbJjl3HPC1tmCfxpLDtPbd5zbIVigRcHyWXuQ+Q+jj3FJgZulbu86CyEg== X-Received: by 10.55.122.130 with SMTP id v124mr31827520qkc.19.1487183577038; Wed, 15 Feb 2017 10:32:57 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Wed, 15 Feb 2017 10:32:56 -0800 (PST) In-Reply-To: <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 15 Feb 2017 10:32:56 -0800 X-Google-Sender-Auth: iLYuhL8x59xs0SBLTgSh5IKhVfI Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:32:59 -0000 At Wed, 15 Feb 2017 18:07:29 +0000, "Templin, Fred L" wrote: > > It's probably better to describe the issue in > > sedhcpv6 with a reference to the RAAN draft as a possible future > > solution to it if and when it's adopted and standardized. > > If sedhcpv6 will not support an authentication-only mode, then it > can' t go forward until RAAN is adopted as a wg item. Otherwise, > an encryption-only sedhcpv6 w/o RAAN would break DHCPv6 PD. I personally don't think it a blocking issue for sedhcpv6, but, of course, the wg should decide it. -- JINMEI, Tatuya From nobody Wed Feb 15 10:49:34 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C69129B21 for ; Wed, 15 Feb 2017 10:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 vmcB7B4IDSBr for ; Wed, 15 Feb 2017 10:49:31 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8245129B22 for ; Wed, 15 Feb 2017 10:49:30 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id v23so145302749qtb.0 for ; Wed, 15 Feb 2017 10:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JHdtkd0isnlFZVszr8HC1JsOnUwQgksGgI/bIy6FHuk=; b=u+XNAMusE3PkIYNMeVFxJtK240CSZvydN8KWxPIPs+ZuM4UPXlmNhUajpmmtNpWXY0 k4tzNTvDwAsnYR2/GGNkEhfQt79yriKdaNQBmWSXs2oSmiavLESUWZsRCTgGFfFVaJTX SibuVJvbmCGj+WoBrBjJQerIbtkgSTijvANKK7HR+6qB63VLMCAF58wL9NoxUkqN7uL7 4XtJBCW+R2BmNqR6VOqcWfNQj+YY5bPI/ZXyCcdVHv2SBeqFbKXdbpM+8Dki4VkKHJai GJUsIchGeo85OCcE006OK4uJ6tx9UppT/ENXGNaeCdgw6Fzr1+21LzZXJ64HUeJX3Bg0 ntbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JHdtkd0isnlFZVszr8HC1JsOnUwQgksGgI/bIy6FHuk=; b=ipwN9kqRuXMqEzsGWyjegA5ugdeUi1qXDExznm6wGC1N9mCg8LRbuOR16ovmTrfiYu JM8f8NXdCWQwc6QRePFv74a47G/TlMkUL9uuh/uN3IfDwyXDJk/DhMhXxs3Mm4oNpGdg ihDiCE429XWTvnlMfoJ51KFdRzzJhawHlHr33EMk1GRRY7Z02SnMeSqAE0Fok980dUKv vLdlJgyX2xyain6f5rsGaCikxk8T9WZf4WNLY53qUyGP2C0q3YlUgdPaJqc561IQxy99 NVTCyeVfalyft1V01Af0V76XCYVs6ewR1nV8Zy7Aa8aVJsjbkbW1t1K9ekIB5eoB2793 a6aQ== X-Gm-Message-State: AMke39mFesvE/QcWKu3XgwvgvJpnja1JVEj/3stSnM5vvjwKQxRMoiQqTM4WIuqS2QClmg== X-Received: by 10.200.42.200 with SMTP id c8mr36852452qta.156.1487184569946; Wed, 15 Feb 2017 10:49:29 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id r10sm2840997qte.1.2017.02.15.10.49.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 10:49:28 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E9A401A8-6723-4722-8E72-180C6AD63DD6" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Feb 2017 13:49:25 -0500 In-Reply-To: To: =?utf-8?B?56We5piO6YGU5ZOJ?= References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:49:33 -0000 --Apple-Mail=_E9A401A8-6723-4722-8E72-180C6AD63DD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 15, 2017, at 1:32 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: > I personally don't think it a blocking issue for sedhcpv6, but, of > course, the wg should decide it. It definitely isn't a blocking issue, but Fred is right that if we are = going ahead with encryption-only, which I agree is the right move, we = need to do this work as well. --Apple-Mail=_E9A401A8-6723-4722-8E72-180C6AD63DD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Feb 15, 2017, at 1:32 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= <jinmei@wide.ad.jp> wrote:
I personally don't think = it a blocking issue for sedhcpv6, but, of
course, the wg should decide = it.

It = definitely isn't a blocking issue, but Fred is right that if we are = going ahead with encryption-only, which I agree is the right move, we = need to do this work as well.

= --Apple-Mail=_E9A401A8-6723-4722-8E72-180C6AD63DD6-- From nobody Wed Feb 15 10:51:35 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A9B1295EE for ; Wed, 15 Feb 2017 10:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 dTHj13RkTilQ for ; Wed, 15 Feb 2017 10:51:33 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB80512954A for ; Wed, 15 Feb 2017 10:51:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1FIpWoH051000; Wed, 15 Feb 2017 11:51:32 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1FIpQfm050861 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 15 Feb 2017 11:51:27 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 15 Feb 2017 10:51:26 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 15 Feb 2017 10:51:26 -0800 From: "Templin, Fred L" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSglOjbTsgor1qYk63PeyrUa0poqFi1e9wgAgT1ID//3y08IAAjtcA//98D6A= Date: Wed, 15 Feb 2017 18:51:26 +0000 Message-ID: <8549b0b78c2e47e1a1839133dbc5b73a@XCH15-06-08.nw.nos.boeing.com> References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:51:34 -0000 SGkgSmlubWVpLXNhbiwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBq aW5tZWkudGF0dXlhQGdtYWlsLmNvbSBbbWFpbHRvOmppbm1laS50YXR1eWFAZ21haWwuY29tXSBP biBCZWhhbGYgT2YgPz8/Pw0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDE3IDEw OjMzIEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ DQo+IENjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIEZ3 ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0y MC50eHQNCj4gDQo+IEF0IFdlZCwgMTUgRmViIDIwMTcgMTg6MDc6MjkgKzAwMDAsDQo+ICJUZW1w bGluLCBGcmVkIEwiIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gDQo+ID4g PiBJdCdzIHByb2JhYmx5IGJldHRlciB0byBkZXNjcmliZSB0aGUgaXNzdWUgaW4NCj4gPiA+IHNl ZGhjcHY2IHdpdGggYSByZWZlcmVuY2UgdG8gdGhlIFJBQU4gZHJhZnQgYXMgYSBwb3NzaWJsZSBm dXR1cmUNCj4gPiA+IHNvbHV0aW9uIHRvIGl0IGlmIGFuZCB3aGVuIGl0J3MgYWRvcHRlZCBhbmQg c3RhbmRhcmRpemVkLg0KPiA+DQo+ID4gSWYgc2VkaGNwdjYgd2lsbCBub3Qgc3VwcG9ydCBhbiBh dXRoZW50aWNhdGlvbi1vbmx5IG1vZGUsIHRoZW4gaXQNCj4gPiBjYW4nIHQgZ28gZm9yd2FyZCB1 bnRpbCBSQUFOIGlzIGFkb3B0ZWQgYXMgYSB3ZyBpdGVtLiBPdGhlcndpc2UsDQo+ID4gYW4gZW5j cnlwdGlvbi1vbmx5IHNlZGhjcHY2IHcvbyBSQUFOIHdvdWxkIGJyZWFrIERIQ1B2NiBQRC4NCj4g DQo+IEkgcGVyc29uYWxseSBkb24ndCB0aGluayBpdCBhIGJsb2NraW5nIGlzc3VlIGZvciBzZWRo Y3B2NiwgYnV0LCBvZg0KPiBjb3Vyc2UsIHRoZSB3ZyBzaG91bGQgZGVjaWRlIGl0Lg0KDQpTb21l IHVzZXMgb2YgREhDUHY2IFBEIHJlcXVpcmUgYSBzZWN1cmUgZXhjaGFuZ2UgYmV0d2VlbiB0aGUg Y2xpZW50IGFuZA0Kc2VydmVyIHN1cHBvcnRlZCBieSBhbiBMRFJBIFtSRkM2MjIxXSB0aGF0IGlz IGluIHRoZSBzYW1lIHBoeXNpY2FsIHN0YWNrIGFzDQp0aGUgc2VydmVyLiBUaGUgTERSQSBuZWVk cyB0byBwZWVrIGludG8gdGhlIHNlcnZlcidzIFJlcGx5IGluIG9yZGVyIHRvIGRpc2NvdmVyDQp0 aGUgZGVsZWdhdGVkIHByZWZpeGVzIGZvciB0aGUgcHVycG9zZSBvZiBjb25maWd1cmluZyByb3V0 ZXMuIFRoaXMgYWxsIG5lZWRzIHRvDQp3b3JrIHdpdGggYSBzdGFuZGFyZHMtY29tcGxpYW50IERI Q1B2NiBzZXJ2ZXIgdGhhdCBpbXBsZW1lbnRzIGJvdGgNCnNlZGhjcHY2IGFuZCBSQUFOLiBNZWFu aW5nIHRoYXQgc2VkaGNwdjYgYW5kIFJBQU4gd291bGQgbmVlZCB0byBiZQ0KYWR2YW5jZWQgdG9n ZXRoZXIgYXMgc3RhbmRhcmRzLg0KDQpNYXliZSBiZXR0ZXIgeWV0IHdvdWxkIGJlIHRvIGJyaW5n IHRoZSBSQUFOIG9wdGlvbiBpbnRvIHRoZSBzZWRoY3B2Ng0Kc3BlYyBpdHNlbGY/DQoNClRoYW5r cyAtIEZyZWQNCg0KPiBKSU5NRUksIFRhdHV5YQ0KDQo= From nobody Wed Feb 15 11:27:13 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF31129678 for ; Wed, 15 Feb 2017 11:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lmv3RLqOlQBB for ; Wed, 15 Feb 2017 11:27:09 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3381012998D for ; Wed, 15 Feb 2017 11:27:09 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id s186so162008269qkb.1 for ; Wed, 15 Feb 2017 11:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CMHKbQX0mwWqRlfm0IB/BPWvJt9k5PcauXd2cL9kQF4=; b=iGgRtsJfIuPjbWF0b4uxxHPX3xlLot2yaj56dnoMdxCuLwliD0b1s+gbyrC2Xrh0Tm FLvz5lyEppyahqXBIkMmfm2aBlT6peRor1vgNyL+jGvn63TA+ZyDprSg38/zWd/uxwBs 7mKng4V5gqLhi7g1xGkuHSCShX145ydhAmvBREhx2ig6wu2vfWLLwS6PkjUCxGevLVav RuW3UcIaBpD0Nh8W8ZbOK0M9/eH6zeZPJPin9rISqYH1I2V1WuRI09c2SnKfHcRtfWQT WwL79c4ne0fyy2zgczwBGfCRnmg8EH2Xsm6XttAaiD/tqph3NuyznlW7UnBBfBadIb+s JuJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CMHKbQX0mwWqRlfm0IB/BPWvJt9k5PcauXd2cL9kQF4=; b=KjQAWyT3Oxw4zzYVgOyWJDlW4X28oYlsR2LT2Ud3djBHlH/3jbl0qDpCHy1wktaIA+ 7qsVFMcc7fH3rxvrmSS1LUj0YpmLIa4flL3s7WkFMM7VsHXuHDdQdLV9OBgk+Oiyb9U9 VhL1SHYW3l3yj1OvfvdlMhkS7c0EwusBz3TgD6RjYPZjAGhMNdNv36HzyS63K/rG2LFN Wlsf28WZC/0XRTcSfAE/hvZ+eaxRpBaitKEh8S3weTYTCSEHCrKDjJKmQgUMuEpMd+lc Ki/CR0y7Hz5aSbL3t1SCru6Ru08xUVyj5Z+8xKEbUJlePdTLsGAy8KkliWuxg4juhqu4 Blrg== X-Gm-Message-State: AMke39lnVaGy9Akn0sh19XiJmvPlvyYpikxfb7FVGudRViIL9mRZxtftD+vDbi+9JE48BbGYjpxxM26+9xgNhQ== X-Received: by 10.55.124.7 with SMTP id x7mr34667140qkc.149.1487186828205; Wed, 15 Feb 2017 11:27:08 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Wed, 15 Feb 2017 11:27:07 -0800 (PST) In-Reply-To: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 15 Feb 2017 11:27:07 -0800 X-Google-Sender-Auth: 3qZO22l7J5kEE4MATRsQRHxO7Ms Message-ID: To: Lishan Li Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg , Ted Lemon Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:27:11 -0000 At Wed, 15 Feb 2017 19:46:27 +0800, Lishan Li wrote: > > Encapsulated in an Encrypted-Response message? If so, with setting > > transaction-id to 0 (like Reconfigure itself)? And is the client > > supposed to try to decrypt it when transaction-id is 0 even if it > > doesn't match any outstanding Encrypted-Query it has sent? And in > > that case which private key should the client use? (For the last > > question, see also the comment on the assumption of the number of > > client certificate described in Section 6). > > > > I think these questions and issues can be addressed relatively easily, > > but I believe these should be clearly and explicitly described. > > > [LS]: How about the following method: > The transaction-id of the Encrypted-Reponse message MUST be equal with the > transaction-id of the received Encrypted-Query message and cannot be zero. > In this way, the client will try to decrypt it. Assuming the Reconfigure is encapsulated in an Encrypted-Response message: it won't work since in case of Reconfigure there's no corresponding message from the client to the server that would be encapsulated in the Encrypted-Query message in the first place. > > > > The description of zero hash algorithm field seems to suggest the > > > > signature and hash algorithms are tightly related in practice. So > > > > it may be better to define the algorithm option so that > > > > signature/hash algorithms are listed as pairs. > > > > > > > [LS]: Yes. In some cases, the signature and hash algorithm are tightly > > > related and cannot be separate. Sorry that I don't understand that > > > "it may be better to define the algorithm option so that signature/hash > > > algorithms are listed as pairs", Could you please explain it more > > clearly? > > > > For example, instead of listing SA-id List and HA-id List separately, > > we might have unified SA-id List: [...] > > and each pair of (SA-id[i], HA-id[i]) will be considered to specify a > > specific signature method. > > > [LS]: So, for every SA-id, there is a corresponding HA-id or multiple > HA-id(s). > SA-id and HA-id are set to a pair. Right? In this example, yes. But I'm not necessarily insisting on this particular example itself. My concern with the currently described way is how to address cases like: - the client includes SA0, SA1, HA0, HA1 in the algorithm option. It supports the combinations of (SA0, HA0) and (SA1, HA1), but not (SA0, HA1) or (SA1, HA0) - the server returns a certificate with the combination of (SA0, HA1) or (SA1, HA0) So the higher level question is whether and how to address this concern. The above example approach could be one solution to it, but it can make the algorithm option unnecessarily larger. > > > > - Section 6 > > > > > > > > [...] In this document, it is assumed > > > > that the client uses only one certificate for the encrypted DHCPv6 > > > > configuration. So, the corresponding private key is used for > > > > decryption. > > > > > > > > I'm not sure if this is okay. And, in fact, Section 11 talks about > > > > a case where multiple key pairs (so multiple certificates) are used: > > > [LS]: We have discussed this issues before. > In most cases, a client will not uses multiple certificate(s) for the > encrypted DHCPv6 configuration process in the same time. Please see the > following reasons: > After the client authentication, the client will use the public key in the > certificate option for encryption. The server only knows one client's > public key for encryption. And the client will also only uses one private > key for decryption. So there is no cases that the client will use one key > pair for the encryption of some DHCPv6 messages and use another key pair > for the encryption of another DHCPv6 messages. This is fine, but I was wondering what if the client has multiple DHCPv6 sessions with different DHCPv6 servers using different key pairs. It's probably very rare in practice, so I can live with saying such an operation is outside the scope of this spec. But I'd like to see wg consensus on this, and if we reach it I'd like it to be explicitly documented. -- JINMEI, Tatuya From nobody Wed Feb 15 11:42:33 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067FD129A2F for ; Wed, 15 Feb 2017 11:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Bi7ks5KdcFVP for ; Wed, 15 Feb 2017 11:42:31 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356F8129A2A for ; Wed, 15 Feb 2017 11:42:31 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id u25so161896993qki.2 for ; Wed, 15 Feb 2017 11:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TkB7KpUpC9jzYHpfDLXA5iDVrnYfe32V5v7ZBJdYtZA=; b=s9dQFFUioizL4NZ0vpJRexCaOC3i8qAFtSDR6LQTLjY9yRZ2NGwNakdAwNT8bB/WlB ZMgZa8v943+uDmnmCr6ooKDuAU8jjEQFR3S45ezH726N5E+s/UtxCeWU5Fv9lx9Bdiud k9cnscpjAEiIga42OKhi8OnRmW/x5S+ts+1rHhYnWtdzOW4EowZPswWtUGGdCMG4wfUV Lj34SdbE2fW39EULF302wN/teoCABmOyjtoIaOJF2i0EP0MuP0gQrT+7Dkd1mT01G+dR +1HTdvkLTNzeprg6gMFmA15Pdz/R/0SoEKePnPIchm7v4MSo5Crc4bD7193r+afQ7ToJ D9yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TkB7KpUpC9jzYHpfDLXA5iDVrnYfe32V5v7ZBJdYtZA=; b=GLU+IclrJhh00VZFBhUjvxzkLl2DUk42NJFSBEkEkZ+/jJmVxayZzC1AzrcQXeoyo5 tpBJHnt719nkzOzJDyOSNlafPfnPTsirnJX5ZqbIQ6IGoa2KtAgJO1bPjJv7sCqgY+FO v3xD84lnTj+0dmd/dN6WJUT2w28TgRl0MQSbLd8lJy654gQ9mGBtlFVaLl6ChUUzIlU8 7OxmCzLu6HFzCq4p20EBwPpSk3vKTqKNSJ/ed9fSJ/bCBMx19WR/r7yzuf61yf8XZLpu 9BjqtXKi7ABCpg23HaOpXmOA1n8LAaZcdhKlisS3VM/olc/vYJO1cYKceL7Z5qjXhM3z W1Uw== X-Gm-Message-State: AMke39marasLf87glQUaIy2m1oALi6i1HS5H/26rKrxTdOZ5udUr1TB4qSyO9sLOYRSPcIA0eSJ0fPMJqAjUbQ== X-Received: by 10.55.123.129 with SMTP id w123mr33939201qkc.20.1487187750255; Wed, 15 Feb 2017 11:42:30 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Wed, 15 Feb 2017 11:42:29 -0800 (PST) In-Reply-To: <8549b0b78c2e47e1a1839133dbc5b73a@XCH15-06-08.nw.nos.boeing.com> References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <8549b0b78c2e47e1a1839133dbc5b73a@XCH15-06-08.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 15 Feb 2017 11:42:29 -0800 X-Google-Sender-Auth: OvAYaXS0gxwsED8b43_5LZ3Y6xM Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:42:33 -0000 At Wed, 15 Feb 2017 18:51:26 +0000, "Templin, Fred L" wrote: > > > > It's probably better to describe the issue in > > > > sedhcpv6 with a reference to the RAAN draft as a possible future > > > > solution to it if and when it's adopted and standardized. > > > > > > If sedhcpv6 will not support an authentication-only mode, then it > > > can' t go forward until RAAN is adopted as a wg item. Otherwise, > > > an encryption-only sedhcpv6 w/o RAAN would break DHCPv6 PD. > > > > I personally don't think it a blocking issue for sedhcpv6, but, of > > course, the wg should decide it. > > Some uses of DHCPv6 PD require a secure exchange between the client and > server supported by an LDRA [RFC6221] that is in the same physical stack as > the server. The LDRA needs to peek into the server's Reply in order to discover > the delegated prefixes for the purpose of configuring routes. This all needs to Where in RFC6221 is that need described? From a quick re-read of the RFC I can't find it. But in any case, > work with a standards-compliant DHCPv6 server that implements both > sedhcpv6 and RAAN. Meaning that sedhcpv6 and RAAN would need to be > advanced together as standards. I don't follow the logic of the final sentence. I see this means sedhcpv6 at least initially wouldn't work for a particular scenario without RAAN. But I don't think it automatically means sedhcpv6 can't be standardized with that limitation. It would depend on how this incompatibility is critical for the overall purpose of sedhcpv6, and it doesn't seem to be that substantial - we can eventually standardize RAAN, and then update sedhcpv6 to fill the incompatibility. I understand you have a different opinion, but to me it's a matter of opinion, not an only possible interpretation of this situation. I'm not insisting my opinion should win, of course, and that's why I said the wg should decide it. > Maybe better yet would be to bring the RAAN option into the sedhcpv6 > spec itself? For the same reason I don't think so, but, again, it should be up to the wg. -- JINMEI, Tatuya From nobody Wed Feb 15 11:46:20 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAA8129A6D for ; Wed, 15 Feb 2017 11:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EbEI8C6zO7OU for ; Wed, 15 Feb 2017 11:46:18 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAFE129A6B for ; Wed, 15 Feb 2017 11:46:18 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id s186so162532565qkb.1 for ; Wed, 15 Feb 2017 11:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hTZB8NDtOPy5Joz3ZulQAmULuPOEOeYiNLWTQ2DKVxs=; b=LqP8gwTx8ljt7Xhr850UEStuSi3GJmEHfpCika3O8Q78Qj9AGK0Ja1PEeBnuha4nfn iRDCleoz798c4EjfJ/67pO/4SRzjr9IcU94ZVEAcZLo3TP8RWm9c8vwYIAQqRWd4QuG+ HaUc6NDPz4bV2XpFVNlar+HUP+e5Y060WLCUukfArh8SvM8Qi5Qx6chpGG5zxdXm/dJm lj3jAiglxp44tA5fq0TjJeYBRVx6LskmDqZ7+I5BC7w90XOYKGR1EfNZbFJOfAN9KY6o J/Q/CotSNhFh4HL3O1hWVs554zpORADB/Vdjb89gUd2nh4sU+V/ChyxIaAryVVRqteua oh4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hTZB8NDtOPy5Joz3ZulQAmULuPOEOeYiNLWTQ2DKVxs=; b=UAhxdK+jJ+9bpUCL1/dAcOkcWxBKJQedvnryrLyxzH9RBgR4l8ka8s5kIvAKcLQDjK 5PHIxf/LNvvLAQS4UQuRWkaaimpVmOj730hcBJvrQ6sGOAAJ/0Gm80iKdfJr+2brgo0f 7fJDlPv0LaXlGvBntcgFWgWcSPpg9aibEniCXu52CWXgJkBLC+FiLanD+YrvdHEmnT0A jZmkE75j/8V8xj1/FfyZrNdWGMT308mF+rnSY90mE6FNfnsgG16r6GXutFfyb3iqh0FR yaoE9BDfqv/Tg+5JyC1r8stD5Wuizy9/Zqe2K4NdQOfUV3vEErO8PVf6YAwyvLPeAIUX MFBQ== X-Gm-Message-State: AMke39lCaV5407jsNjYDH1+8FD3qBj0YDRwEzpUn9ls8+RBw2ohzoKte/ASpwabxpzyAFZr4G5Vo5KkYtYZWfw== X-Received: by 10.233.222.197 with SMTP id s188mr32406753qkf.311.1487187977457; Wed, 15 Feb 2017 11:46:17 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Wed, 15 Feb 2017 11:46:16 -0800 (PST) In-Reply-To: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 15 Feb 2017 11:46:16 -0800 X-Google-Sender-Auth: sNbFELAme4qV0nr56P8k00ES3Pw Message-ID: To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:46:19 -0000 At Wed, 15 Feb 2017 13:49:25 -0500, Ted Lemon wrote: > > I personally don't think it a blocking issue for sedhcpv6, but, of > > course, the wg should decide it. > > [...], but Fred is right that if we > are going ahead with encryption-only, which I agree is the right > move, we need to do this work as well. Yes, I agree on that point. -- JINMEI, Tatuya From nobody Wed Feb 15 17:58:41 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3751293FE; Wed, 15 Feb 2017 17:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EOIohlDT9qwe; Wed, 15 Feb 2017 17:58:36 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19633129C43; Wed, 15 Feb 2017 17:58:36 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id 73so2726139otj.0; Wed, 15 Feb 2017 17:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n+oxyq8r6aDqqHujwBoSXql9OxksVsgde5Z0nLkWgF8=; b=vRUl/MwHG4zD3DbUZJLdGSV7rnEWWtgB3sno8NXT8rds6uheqfddvvFTEQZjTcu35K NPqsYcKFArCKPsO2/3ER6hV7YQ6yZG3XgpSlxLGDZEckhF7+iYVpJlsZmxhs/3KBQMYO G0Icvxt484RkyJGH/9/mN4gNMDnLOiW2zzypLWo8hFwBnmtu8Wm/oIueDwdVxVLQgWsz sMXO5TfCA78WN+d25wvHIphPGmGFCk1b9aGM0Xwr054VxBZiMiHIKfNjkiiJAdii7A4P sMLf8BBeMBaPV3XDL8rqyFYYsU1JPPgM6Y91zt6OSmXU3xjMNiOa/GcbEOM2mWRqbFem X2IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n+oxyq8r6aDqqHujwBoSXql9OxksVsgde5Z0nLkWgF8=; b=hWjNaU5k+9z8PdLBZXA+547ddsDy0xA3Cv5CeNObztgXJzgFJCNYtFz4ldYdiXxL8r 94rGzmNmq60xdAj+2y8w/BT9OAOY6IE57AXaBvvKD9fExMBM6f/nFvLP2jriMRIz64QR NHTccXRRvxU15q0AaqY+5wdJeHW02W/ozCEPWzJ/DA6PssJegRiXnMX0CMHjr5njmkDy KljHCABetor/ZZ7dHRS0mdZ94aA/v7RbQXQqQvyrdP+zDspMahPGJoZo3uvib3sRVMjp H0vz7Js5xxsPrOOj/7xjpHCdbOYwAZZr4KNJFfgxlUhwl0FTU/fT+OA8w4wIyP5sBhJo nCCg== X-Gm-Message-State: AMke39n5D6q/yFLNbtBVKa1sVX3DWp3PMVVmnBfbSzArQQ+hRsPL3vIGYzhvgqTAzWGNPW/RHRZmmcnPaUH9mg== X-Received: by 10.157.52.253 with SMTP id t58mr22726256otd.161.1487210315438; Wed, 15 Feb 2017 17:58:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.1.202 with HTTP; Wed, 15 Feb 2017 17:57:55 -0800 (PST) In-Reply-To: <148715302215.17389.14651452070558302618.idtracker@ietfa.amsl.com> References: <148715302215.17389.14651452070558302618.idtracker@ietfa.amsl.com> From: tianxiang li Date: Thu, 16 Feb 2017 09:57:55 +0800 Message-ID: To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary=001a1140a4628ee19c05489c2280 Archived-At: Cc: dhc-chairs@ietf.org, Bernie Volz , The IESG , dhcwg , draft-ietf-dhc-dhcpv6-prefix-length-hint-issue@ietf.org Subject: Re: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-dhcpv6-prefix-length-hint-issue-05=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:58:37 -0000 --001a1140a4628ee19c05489c2280 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, Thank you for the review and suggestion. I think we could make a pointer to say this document updates RFC 3633. We'll add this in the updated document. Cheers, Tianxiang 2017-02-15 18:03 GMT+08:00 Mirja Kuehlewind : > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefi > x-length-hint-issue/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I think it would make sense if this doc updates RFC 3633 because someone > who (newly) implements RFC 3633 should really also read this document and > hance needs this pointer. > > Also, I would move section 3.6 to the beginning but that doesn't really > matter. > > > --001a1140a4628ee19c05489c2280 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Thank you for the review and = suggestion. I think we could make a pointer to say this document updates RF= C 3633.
We'll add this in the updated document.
Cheers,
Tianxiang

<= div class=3D"gmail_quote">2017-02-15 18:03 GMT+08:00 Mirja Kuehlewind <i= etf@kuehlewind.net>:
Mirja = K=C3=BChlewind has entered the following ballot position for
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.= ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/<= br>


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I think it would make sense if this doc updates RFC 3633 because someone who (newly) implements RFC 3633 should really also read this document and hance needs this pointer.

Also, I would move section 3.6 to the beginning but that doesn't really=
matter.



--001a1140a4628ee19c05489c2280-- From nobody Wed Feb 15 22:49:04 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E02129991 for ; Wed, 15 Feb 2017 22:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2F_QxJhx0WJv for ; Wed, 15 Feb 2017 22:49:01 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B807B129431 for ; Wed, 15 Feb 2017 22:49:00 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id p22so7588138qka.0 for ; Wed, 15 Feb 2017 22:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XqBkuMZC31hbYIz5cpdJPtc9xG1Ilel5OXp8/4Z2IQQ=; b=pkL2gsZHiLw8+9UmHx9/Q/V5R9i6auq8DcdSz7OQyNruus68ln8bzvKRrm1fPTHX2M HksCucxHo3AWJf+q0l+ykSBCKU0/FuS60kvLss3Y5Kv+wIyKRjKlG2GPoZYPsU50WNqj +Flmo2j89R0GOwXhleAWq7YW4egcb+IZlqWmGi3k+ylE6iUBnzSaM0uCNhhY2omiJncf ESwRjb+lBSpA+Aa1RRBOJfKSnKucRTHD1wlZhxpixW2Q0SGDh9HGPthgvceqK/ZsDnsy IPO8mw1jlI0iVoj5eeXVl96H6AqY0FpGd36lo670Q7o8bMKkywDsb8csxdHtV8a6q+QN 0RgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XqBkuMZC31hbYIz5cpdJPtc9xG1Ilel5OXp8/4Z2IQQ=; b=KbpvhfTYzTIQIJxGnkKLTKtqBIQed50CEE6sgTNesAqET7KxSn/phdKZ+aJB7tMF6G P837xo0fAoa3syzPztNm3h6mfsq0MsiqVItQuoVWDGkvDPxSmfNgUpwqqYX/bYjO5LUq dFogX7heRykZ64qoOFc/DyN5gbG3b2V+86A5NebZU3nOj6140/1ZCgkswUGnPXzz+av7 WoAc6GJAawIofQBJn8GJQpFiRiG6f2oiHoOWzRh6ukvLVWh0ZlDK3fVZiwDiF+6uuRAc Dsl+wADWjPddvQhVymyPIYuWxkd2V523TYNugJErEmbmraBfJSw1DbDIj8wILCzKIQLr oteA== X-Gm-Message-State: AMke39mzxNYS6IqxS/E/Ig/N8ahqsoGDLxixjdaQEMQRCUe7tLdSPs8HPfyZAhvaqD8Q2CkRkPwXih/hjAJHNA== X-Received: by 10.55.170.17 with SMTP id t17mr588185qke.15.1487227739894; Wed, 15 Feb 2017 22:48:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.46.172 with HTTP; Wed, 15 Feb 2017 22:48:59 -0800 (PST) In-Reply-To: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> From: Lishan Li Date: Thu, 16 Feb 2017 14:48:59 +0800 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=001a114d519822fc3d0548a031f6 Archived-At: Cc: dhcwg , Ted Lemon Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 06:49:03 -0000 --001a114d519822fc3d0548a031f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2017-02-16 3:27 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 : > At Wed, 15 Feb 2017 19:46:27 +0800, > Lishan Li wrote: > > > > Encapsulated in an Encrypted-Response message? If so, with setting > > > transaction-id to 0 (like Reconfigure itself)? And is the client > > > supposed to try to decrypt it when transaction-id is 0 even if it > > > doesn't match any outstanding Encrypted-Query it has sent? And in > > > that case which private key should the client use? (For the last > > > question, see also the comment on the assumption of the number of > > > client certificate described in Section 6). > > > > > > I think these questions and issues can be addressed relatively easily= , > > > but I believe these should be clearly and explicitly described. > > > > > [LS]: How about the following method: > > The transaction-id of the Encrypted-Reponse message MUST be equal with > the > > transaction-id of the received Encrypted-Query message and cannot be > zero. > > In this way, the client will try to decrypt it. > > Assuming the Reconfigure is encapsulated in an Encrypted-Response > message: it won't work since in case of Reconfigure there's no > corresponding message from the client to the server that would be > encapsulated in the Encrypted-Query message in the first place. > [LS]: Yes. It is also the reason why the transaction-id of Reconfigure message is set to zero. Right? In this way, if the transaction-id of the Encrypted-Response is set to zero. Then in the client behavior part, we should states that: If the transaction-id is 0, the client also try to decrypt it. And in the server behavior part, we add the states that: If the DHCPv6 message is Reconfigure message, then the server set the transaction-id of the Encrypted-Response message to 0. > > > > > > The description of zero hash algorithm field seems to suggest t= he > > > > > signature and hash algorithms are tightly related in practice. > So > > > > > it may be better to define the algorithm option so that > > > > > signature/hash algorithms are listed as pairs. > > > > > > > > > [LS]: Yes. In some cases, the signature and hash algorithm are > tightly > > > > related and cannot be separate. Sorry that I don't understand that > > > > "it may be better to define the algorithm option so that > signature/hash > > > > algorithms are listed as pairs", Could you please explain it more > > > clearly? > > > > > > For example, instead of listing SA-id List and HA-id List separately, > > > we might have unified SA-id List: > [...] > > > and each pair of (SA-id[i], HA-id[i]) will be considered to specify a > > > specific signature method. > > > > > [LS]: So, for every SA-id, there is a corresponding HA-id or multiple > > HA-id(s). > > SA-id and HA-id are set to a pair. Right? > > In this example, yes. But I'm not necessarily insisting on this > particular example itself. My concern with the currently described > way is how to address cases like: > > - the client includes SA0, SA1, HA0, HA1 in the algorithm option. It > supports the combinations of (SA0, HA0) and (SA1, HA1), but not (SA0, > HA1) or (SA1, HA0) > - the server returns a certificate with the combination of (SA0, HA1) > or (SA1, HA0) > > So the higher level question is whether and how to address this > concern. The above example approach could be one solution to it, but > it can make the algorithm option unnecessarily larger. > [LS]: Agree. > > > > > > - Section 6 > > > > > > > > > > [...] In this document, it is assumed > > > > > that the client uses only one certificate for the encrypted > DHCPv6 > > > > > configuration. So, the corresponding private key is used for > > > > > decryption. > > > > > > > > > > I'm not sure if this is okay. And, in fact, Section 11 talks > about > > > > > a case where multiple key pairs (so multiple certificates) are > used: > > > > > [LS]: We have discussed this issues before. > > In most cases, a client will not uses multiple certificate(s) for the > > encrypted DHCPv6 configuration process in the same time. Please see the > > following reasons: > > After the client authentication, the client will use the public key in > the > > certificate option for encryption. The server only knows one client's > > public key for encryption. And the client will also only uses one priva= te > > key for decryption. So there is no cases that the client will use one k= ey > > pair for the encryption of some DHCPv6 messages and use another key pai= r > > for the encryption of another DHCPv6 messages. > > This is fine, but I was wondering what if the client has multiple > DHCPv6 sessions with different DHCPv6 servers using different key > pairs. It's probably very rare in practice, so I can live with saying > such an operation is outside the scope of this spec. But I'd like to > see wg consensus on this, and if we reach it I'd like it to be > explicitly documented. > [LS]: Agree. It is necessary to be explicitly documented. --001a114d519822fc3d0548a031f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017-02-16 3:27 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 <jinmei@wide.ad.jp>:
At Wed, 15 Feb 2017= 19:46:27 +0800,
Lishan Li <lili= shan48@gmail.com> wrote:

> > Encapsulated in an Encrypted-Response message?=C2=A0 If so, with = setting
> > transaction-id to 0 (like Reconfigure itself)?=C2=A0 And is the c= lient
> > supposed to try to decrypt it when transaction-id is 0 even if it=
> > doesn't match any outstanding Encrypted-Query it has sent?=C2= =A0 And in
> > that case which private key should the client use?=C2=A0 (For the= last
> > question, see also the comment on the assumption of the number of=
> > client certificate described in Section 6).
> >
> > I think these questions and issues can be addressed relatively ea= sily,
> > but I believe these should be clearly and explicitly described. > >
> [LS]: How about the following method:
> The transaction-id of the Encrypted-Reponse message MUST be equal with= the
> transaction-id of the received Encrypted-Query message and cannot be z= ero.
> In this way, the client will try to decrypt it.

Assuming the Reconfigure is encapsulated in an Encrypted-Response message: it won't work since in case of Reconfigure there's no
corresponding message from the client to the server that would be
encapsulated in the Encrypted-Query message in the first place.
[LS]: Yes. It is also the reason why the transaction-id of Reconf= igure message is set to zero. Right?
In this way, if the transact= ion-id of the Encrypted-Response is set to zero.=C2=A0
Then in th= e client behavior part, we should states that: If the transaction-id is 0, = the client also try to decrypt it.
And in the server behavior par= t, we add the states that: If the DHCPv6 message is Reconfigure message, th= en the server set the transaction-id of the Encrypted-Response message to 0= .

> > > >=C2=A0 =C2=A0The description of zero hash algorithm fiel= d seems to suggest the
> > > >=C2=A0 =C2=A0signature and hash algorithms are tightly r= elated in practice.=C2=A0 So
> > > >=C2=A0 =C2=A0it may be better to define the algorithm op= tion so that
> > > >=C2=A0 =C2=A0signature/hash algorithms are listed as pai= rs.
> > > >
> > > [LS]: Yes. In some cases, the signature and hash algorithm a= re tightly
> > > related and cannot be separate. Sorry that I don't under= stand that
> > > "it may be better to define the algorithm option so tha= t signature/hash
> > > algorithms are listed as pairs", Could you please expla= in it more
> > clearly?
> >
> > For example, instead of listing SA-id List and HA-id List separat= ely,
> > we might have unified SA-id List:
[...]
> > and each pair of (SA-id[i], HA-id[i]) will be co= nsidered to specify a
> > specific signature method.
> >
> [LS]: So, for every SA-id, there is a corresponding HA-id or multiple<= br> > HA-id(s).
> SA-id and HA-id are set to a pair. Right?

In this example, yes.=C2=A0 But I'm not necessarily insisting on= this
particular example itself.=C2=A0 My concern with the currently described way is how to address cases like:

- the client includes SA0, SA1, HA0, HA1 in the algorithm option.=C2=A0 It<= br> =C2=A0 supports the combinations of (SA0, HA0) and (SA1, HA1), but not (SA0= ,
=C2=A0 HA1) or (SA1, HA0)
- the server returns a certificate with the combination of (SA0, HA1)
=C2=A0 or (SA1, HA0)

So the higher level question is whether and how to address this
concern.=C2=A0 The above example approach could be one solution to it, but<= br> it can make the algorithm option unnecessarily larger.
[LS]: Agree.

> > > > - Section 6
> > > >
> > > >=C2=A0 =C2=A0 [...] In this document, it is assumed
> > > >=C2=A0 =C2=A0 that the client uses only one certificate = for the encrypted DHCPv6
> > > >=C2=A0 =C2=A0 configuration.=C2=A0 So, the corresponding= private key is used for
> > > >=C2=A0 =C2=A0 decryption.
> > > >
> > > >=C2=A0 =C2=A0I'm not sure if this is okay.=C2=A0 And= , in fact, Section 11 talks about
> > > >=C2=A0 =C2=A0a case where multiple key pairs (so multipl= e certificates) are used:
> >
> [LS]: We have discussed this issues before.
> In most cases, a client will not uses multiple certificate(s) for the<= br> > encrypted DHCPv6 configuration process in the same time. Please see th= e
> following reasons:
> After the client authentication, the client will use the public key in= the
> certificate option for encryption. The server only knows one client= 9;s
> public key for encryption. And the client will also only uses one priv= ate
> key for decryption. So there is no cases that the client will use one = key
> pair for the encryption of some DHCPv6 messages and use another key pa= ir
> for the encryption of another DHCPv6 messages.

This is fine, but I was wondering what if the client has multiple DHCPv6 sessions with different DHCPv6 servers using different key
pairs.=C2=A0 It's probably very rare in practice, so I can live with sa= ying
such an operation is outside the scope of this spec.=C2=A0 But I'd like= to
see wg consensus on this, and if we reach it I'd like it to be
explicitly documented.
[LS]: Agree. It is necessary to= be explicitly documented.=C2=A0

--001a114d519822fc3d0548a031f6-- From nobody Thu Feb 16 02:16:40 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E74C12940E; Thu, 16 Feb 2017 02:16:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148724019438.15925.5760161471481830737.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 02:16:34 -0800 Archived-At: Cc: dhc-chairs@ietf.org, volz@cisco.com, dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue@ietf.org Subject: [dhcwg] Benoit Claise's No Objection on draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 10:16:34 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From the draft: [RFC3633] is unclear about how the client and server should act in different situations involving the prefix-length hint. >From the shepherd write-up This document specifies information that is useful to DHCPv6 client and server implementers to support allowing clients to specify a prefix length hint when requested delegated prefixes. It clarifies this concept introduced in RFC 3633. => that implies an UPDATE, no? Obviously, this document publication should go forward (so not a DISCUSS), but I would like to understand why this is not an update. Editorial nit (by Sue Hares, part of her OPS DIR review): Page 3 section 3.1 section under problem. Second paragraph. Second sentence The best way to assure a completely new delegated prefix is to send a new IAID in the IA_PD. IAID – abbreviation has not been indicated prior to this use Old:/IAID/ New: /IAID (IA_PD unique identifier)/ From nobody Thu Feb 16 04:04:06 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA85F1294E6; Thu, 16 Feb 2017 04:04:04 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 khIB9vCfk830; Thu, 16 Feb 2017 04:04:02 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5939A129563; Thu, 16 Feb 2017 04:04:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AF6BA2CEB1; Thu, 16 Feb 2017 14:04:01 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz-uZ9gl_iij; Thu, 16 Feb 2017 14:04:01 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 2A3632CCBA; Thu, 16 Feb 2017 14:04:01 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_71DD5588-1791-45C9-BDF1-12F2B162C3EC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148568056700.24536.11691583944564362484.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 14:04:00 +0200 Message-Id: References: <148568056700.24536.11691583944564362484.idtracker@ietfa.amsl.com> To: Roni Even X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: dhcwg@ietf.org, gen-art@ietf.org, ietf@ietf.org, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@ietf.org Subject: Re: [dhcwg] [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 12:04:04 -0000 --Apple-Mail=_71DD5588-1791-45C9-BDF1-12F2B162C3EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Roni: thanks for your detailed review. I also appreciate the responses and changes by you Tianxiang. I have balloted no-objection for this document for today=92s IESG telechat, and expect that the discussed changes will find themselves into a new document version at some point. Jari --Apple-Mail=_71DD5588-1791-45C9-BDF1-12F2B162C3EC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYpZUwAAoJEM80gCTQU46qJrQP/2Q3KFZv7t9N/+MIRJoIej15 ZkQNNWzW/yp7Xw33FPLHet7cFA2Bz0Qijudj0UmplChFxLxzDLeAu8rKxN21yb6n Vb6gJs7kITlHyWsyElialCKmVsCIULZ5oAzP5VmKQzPSNUzBh9abp+6eEP4NsmMb k9FMxPt8iDWhCmfZGg4JHn8XPx5cMe0ccH5bs84tugEaQh4dQU34O/lhFH7I7uYd 8TZGV68W3hE6rZKSCp+Po7qlIDWZ0txT6UlmqFXLhvknm9uNLSev9RKvry+YFWSV NvO+uXMd1xEpQjm5PPgihYpcqnvjFZA+d+gZdOKTCaqUYQUrYufu71NKrFmU4hSr Wp4jEI6FaWPOXemapDIU/tsAHG0hEKpNDGH6Tky009oIQv4PS2R7BB6Otb6fU1zC dtCoTgYAufK/hyuZxmO7rRskasSKO1k/0SOxQy8A06LmJFMcmDuOGK1KIAO0NVzq 3FNhG9Ta+K86eJXx0my/vUfEezdKcdmoBVx+qSS15qkUC8J4O1aFyleyA8I+AAo2 toKrWWuaPnG+mFoGLevGtJdAUf7sHsv5SpPIVq4N4XwuxbfUEQlvU/xy0et5xzcH c6NqEMNPotWHfqlnJ9upn81ADghggwop9WlryRB7D4LA1Lw9t2uZ6Onng6myELPp tRzqX6N/uNBaGjrQYX3/ =gTNY -----END PGP SIGNATURE----- --Apple-Mail=_71DD5588-1791-45C9-BDF1-12F2B162C3EC-- From nobody Thu Feb 16 11:01:19 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1899B129668 for ; Thu, 16 Feb 2017 11:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 f__ll9HS1PtF for ; Thu, 16 Feb 2017 11:01:17 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EC112955E for ; Thu, 16 Feb 2017 11:01:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1GJ1GJj031837; Thu, 16 Feb 2017 12:01:16 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1GJ16XN031750 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 16 Feb 2017 12:01:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Feb 2017 11:01:05 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Thu, 16 Feb 2017 11:01:05 -0800 From: "Templin, Fred L" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSglOjbTsgor1qYk63PeyrUa0poqFi1e9wgAgT1ID//3y08IAAjtcA//98D6CAAJdggIAA+dIg Date: Thu, 16 Feb 2017 19:01:05 +0000 Message-ID: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <8549b0b78c2e47e1a1839133dbc5b73a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:01:19 -0000 SGkgSmlubWVpLXNhbiwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBq aW5tZWkudGF0dXlhQGdtYWlsLmNvbSBbbWFpbHRvOmppbm1laS50YXR1eWFAZ21haWwuY29tXSBP biBCZWhhbGYgT2YgPz8/Pw0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDE3IDEx OjQyIEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ DQo+IENjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIEZ3 ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0y MC50eHQNCj4gDQo+IEF0IFdlZCwgMTUgRmViIDIwMTcgMTg6NTE6MjYgKzAwMDAsDQo+ICJUZW1w bGluLCBGcmVkIEwiIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gDQo+ID4g PiA+ID4gSXQncyBwcm9iYWJseSBiZXR0ZXIgdG8gZGVzY3JpYmUgdGhlIGlzc3VlIGluDQo+ID4g PiA+ID4gc2VkaGNwdjYgd2l0aCBhIHJlZmVyZW5jZSB0byB0aGUgUkFBTiBkcmFmdCBhcyBhIHBv c3NpYmxlIGZ1dHVyZQ0KPiA+ID4gPiA+IHNvbHV0aW9uIHRvIGl0IGlmIGFuZCB3aGVuIGl0J3Mg YWRvcHRlZCBhbmQgc3RhbmRhcmRpemVkLg0KPiA+ID4gPg0KPiA+ID4gPiBJZiBzZWRoY3B2NiB3 aWxsIG5vdCBzdXBwb3J0IGFuIGF1dGhlbnRpY2F0aW9uLW9ubHkgbW9kZSwgdGhlbiBpdA0KPiA+ ID4gPiBjYW4nIHQgZ28gZm9yd2FyZCB1bnRpbCBSQUFOIGlzIGFkb3B0ZWQgYXMgYSB3ZyBpdGVt LiBPdGhlcndpc2UsDQo+ID4gPiA+IGFuIGVuY3J5cHRpb24tb25seSBzZWRoY3B2NiB3L28gUkFB TiB3b3VsZCBicmVhayBESENQdjYgUEQuDQo+ID4gPg0KPiA+ID4gSSBwZXJzb25hbGx5IGRvbid0 IHRoaW5rIGl0IGEgYmxvY2tpbmcgaXNzdWUgZm9yIHNlZGhjcHY2LCBidXQsIG9mDQo+ID4gPiBj b3Vyc2UsIHRoZSB3ZyBzaG91bGQgZGVjaWRlIGl0Lg0KPiA+DQo+ID4gU29tZSB1c2VzIG9mIERI Q1B2NiBQRCByZXF1aXJlIGEgc2VjdXJlIGV4Y2hhbmdlIGJldHdlZW4gdGhlIGNsaWVudCBhbmQN Cj4gPiBzZXJ2ZXIgc3VwcG9ydGVkIGJ5IGFuIExEUkEgW1JGQzYyMjFdIHRoYXQgaXMgaW4gdGhl IHNhbWUgcGh5c2ljYWwgc3RhY2sgYXMNCj4gPiB0aGUgc2VydmVyLiBUaGUgTERSQSBuZWVkcyB0 byBwZWVrIGludG8gdGhlIHNlcnZlcidzIFJlcGx5IGluIG9yZGVyIHRvIGRpc2NvdmVyDQo+ID4g dGhlIGRlbGVnYXRlZCBwcmVmaXhlcyBmb3IgdGhlIHB1cnBvc2Ugb2YgY29uZmlndXJpbmcgcm91 dGVzLiBUaGlzIGFsbCBuZWVkcyB0bw0KPiANCj4gV2hlcmUgaW4gUkZDNjIyMSBpcyB0aGF0IG5l ZWQgZGVzY3JpYmVkPyAgRnJvbSBhIHF1aWNrIHJlLXJlYWQgb2YgdGhlDQo+IFJGQyBJIGNhbid0 IGZpbmQgaXQuICBCdXQgaW4gYW55IGNhc2UsDQoNClRoZXJlIGlzIGF0IGxlYXN0IG9uZSB1c2Ug Y2FzZSB3aGVyZSBhbiBSRkM2MjIxIExEUkEgcmVzaWRlcyBpbiBsb3dlciBsZXZlbHMgb2YNCnRo ZSBzdGFjayB0aGF0IHN1cHBvcnRzIHRoZSBESENQdjYgc2VydmVyIGFuZCBtYW5hZ2VzIHJvdXRp bmcgaW5mb3JtYXRpb24NCmJhc2VkIG9uIERIQ1B2NiBQRHMgaXNzdWVkIGJ5IHRoZSBzZXJ2ZXIu IEJlY2F1c2UgYW4gdW5tb2RpZmllZCBESENQdjYNCnNlcnZlciBjYW5ub3QgcmVhY2ggYWNyb3Nz IHRoZSBsYXllcnMgdG8gbWFuaXB1bGF0ZSB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiwNCml0IHJl bGllcyBvbiB0aGUgTERSQSB0byBkbyBzby4gU28sIHdoZW4gc2VkaGNwdjYgaXMgYXBwbGllZCwg dGhlcmUgaXMgYQ0KcmVxdWlyZW1lbnQgZm9yIFJBQU4gb3B0aW9ucyB0byBhbGxvdyB0aGUgc2Vy dmVyIHRvIHBhc3MgaW5mb3JtYXRpb24gdG8NCiB0aGUgTERSQS4NCg0KPiA+IHdvcmsgd2l0aCBh IHN0YW5kYXJkcy1jb21wbGlhbnQgREhDUHY2IHNlcnZlciB0aGF0IGltcGxlbWVudHMgYm90aA0K PiA+IHNlZGhjcHY2IGFuZCBSQUFOLiBNZWFuaW5nIHRoYXQgc2VkaGNwdjYgYW5kIFJBQU4gd291 bGQgbmVlZCB0byBiZQ0KPiA+IGFkdmFuY2VkIHRvZ2V0aGVyIGFzIHN0YW5kYXJkcy4NCj4gDQo+ IEkgZG9uJ3QgZm9sbG93IHRoZSBsb2dpYyBvZiB0aGUgZmluYWwgc2VudGVuY2UuICBJIHNlZSB0 aGlzIG1lYW5zDQo+IHNlZGhjcHY2IGF0IGxlYXN0IGluaXRpYWxseSB3b3VsZG4ndCB3b3JrIGZv ciBhIHBhcnRpY3VsYXIgc2NlbmFyaW8NCj4gd2l0aG91dCBSQUFOLiAgQnV0IEkgZG9uJ3QgdGhp bmsgaXQgYXV0b21hdGljYWxseSBtZWFucyBzZWRoY3B2NiBjYW4ndA0KPiBiZSBzdGFuZGFyZGl6 ZWQgd2l0aCB0aGF0IGxpbWl0YXRpb24uICBJdCB3b3VsZCBkZXBlbmQgb24gaG93IHRoaXMNCj4g aW5jb21wYXRpYmlsaXR5IGlzIGNyaXRpY2FsIGZvciB0aGUgb3ZlcmFsbCBwdXJwb3NlIG9mIHNl ZGhjcHY2LCBhbmQNCj4gaXQgZG9lc24ndCBzZWVtIHRvIGJlIHRoYXQgc3Vic3RhbnRpYWwgLSB3 ZSBjYW4gZXZlbnR1YWxseSBzdGFuZGFyZGl6ZQ0KPiBSQUFOLCBhbmQgdGhlbiB1cGRhdGUgc2Vk aGNwdjYgdG8gZmlsbCB0aGUgaW5jb21wYXRpYmlsaXR5LiAgSQ0KPiB1bmRlcnN0YW5kIHlvdSBo YXZlIGEgZGlmZmVyZW50IG9waW5pb24sIGJ1dCB0byBtZSBpdCdzIGEgbWF0dGVyIG9mDQo+IG9w aW5pb24sIG5vdCBhbiBvbmx5IHBvc3NpYmxlIGludGVycHJldGF0aW9uIG9mIHRoaXMgc2l0dWF0 aW9uLiAgSSdtDQo+IG5vdCBpbnNpc3RpbmcgbXkgb3BpbmlvbiBzaG91bGQgd2luLCBvZiBjb3Vy c2UsIGFuZCB0aGF0J3Mgd2h5IEkgc2FpZA0KPiB0aGUgd2cgc2hvdWxkIGRlY2lkZSBpdC4NCj4g DQo+ID4gTWF5YmUgYmV0dGVyIHlldCB3b3VsZCBiZSB0byBicmluZyB0aGUgUkFBTiBvcHRpb24g aW50byB0aGUgc2VkaGNwdjYNCj4gPiBzcGVjIGl0c2VsZj8NCj4gDQo+IEZvciB0aGUgc2FtZSBy ZWFzb24gSSBkb24ndCB0aGluayBzbywgYnV0LCBhZ2FpbiwgaXQgc2hvdWxkIGJlIHVwIHRvDQo+ IHRoZSB3Zy4NCg0KVGhlcmUgaXMgYW5vdGhlciBleGFtcGxlIHdoZXJlIGEgc2VjdXJpdHktc3Bl Y2lmaWMgc29sdXRpb24gcHVibGlzaGVkDQpnZW5lcmFsLXB1cnBvc2Ugb3B0aW9ucyBwb3RlbnRp YWxseSB1c2VmdWwgZm9yIG90aGVyIHB1cnBvc2VzLiBJbiBSRkMzOTcxDQoodGhlIFNFTkQgc3Bl YykgdGhlIFRpbWVzdGFtcCBhbmQgTm9uY2Ugb3B0aW9ucyBhcmUgZGVmaW5lZC4gVGhlIGFzc2ln bmVkDQpudW1iZXJzIGZvciB0aGVzZSBvcHRpb25zIG9jY3VweSBJUHY2IE5EIE9wdGlvbiBUeXBl IHZhbHVlcywgYW5kIHRoZXkgYXJlDQp0aGVyZWZvcmUgcHJlc3VtYWJseSBhcHBsaWNhYmxlIGZv ciBJUHY2IE5EIG1lc3NhZ2luZyBldmVuIHdoZW4gU0VORCBpcw0Kbm90IGluIGVmZmVjdC4NCg0K SW4gdGhlIHNhbWUgZmFzaGlvbiwgaWYgdGhlIFJBQU4gb3B0aW9uIHdlcmUgaW5jb3Jwb3JhdGVk IGludG8gdGhlDQpzZWRoY3B2NiBzcGVjLCBpdCBjb3VsZCBiZSBhcHBsaWVkIGZvciBvdGhlciBw dXJwb3NlcyBldmVuIHdoZW4NCnNlZGhjcHY2IGlzIG5vdCBpbiBlZmZlY3QuIEFuZCwgdGhlcmUg d291bGQgbm8gbG9uZ2VyIGJlIGNvbmNlcm5zIGZvcg0KYSBzeW5jaHJvbml6ZWQgcHVibGljYXRp b24gb2YgbXVsdGlwbGUgZG9jdW1lbnRzIHNpbmNlIGJvdGggc2VkaGNwdjYNCmFuZCBSQUFOIHdv dWxkIGdvIGZvcndhcmQgdG9nZXRoZXIgaW4gYSBzaW5nbGUgcGFja2FnZS4NCg0KVGhhbmtzIC0g RnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+IC0tDQo+IEpJTk1FSSwgVGF0dXlh DQoNCg== From nobody Thu Feb 16 14:39:00 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461B0129577 for ; Thu, 16 Feb 2017 14:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 KS1zBz5-9xLC for ; Thu, 16 Feb 2017 14:38:57 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F47124281 for ; Thu, 16 Feb 2017 14:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13346; q=dns/txt; s=iport; t=1487284737; x=1488494337; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=60MbhKrmQc9HaCGrE+xr2SKWgEcs+Bp0FWiKqXcBKVc=; b=O/STn6isvuNvD8KchZ0ZWYfufTQUrMnvDKe9NYcYhqBxeqNm8f1uBPhO 9N0Qn9Sek09U+1X+hcVhCJcYTDMJ7atMn7JdFlZYTqDgH2C6TEYDjmaiW vSSgdkD90wXjvl7BU+vcx8kjKCYNER1xUQ/0KWKCsK6YWyrBs7uMGNVDO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQBiKaZY/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB4NSigiSD5AHhSyCDC6FdAIagXY/GAECAQEBAQEBAWI?= =?us-ascii?q?ohHABAQECAiMKSgIQAgEGAg4DBAEBKAMCAgIwFAkIAgQBDQUIiWQOknudWIIli?= =?us-ascii?q?1UBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYs7hQqCUIJfBZt/AZINkQ+TFwEfOIE?= =?us-ascii?q?AURWHAXUBiSmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="386609029" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 22:38:56 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1GMcuOS002197 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 22:38:56 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 16:38:55 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 16:38:55 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSb9dh9mAfGPV9aE2109Imxv8IT6FqmOCwgAHRRkA= Date: Thu, 16 Feb 2017 22:38:55 +0000 Message-ID: <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.204] Content-Type: multipart/alternative; boundary="_000_9d9d50b20005459aafffcd8f64bfb281XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:38:59 -0000 --_000_9d9d50b20005459aafffcd8f64bfb281XCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBwcmVzZW50ZWQgYWJvdXQgcmVzdXJyZWN0aW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1hZ2Vu dG9wdC1kZWxlZ2F0ZSBhdCBJRVRGLTk3IChzZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny1kaGMtcmVzdXJyZWN0LWRyYWZ0LWlldGYtZGhjLWRo Y3B2Ni1hZ2VudG9wdC1kZWxlZ2F0ZS0wMC5wZGYpLg0KDQpBbmQgdGhlIGNvbmNsdXNpb24gdGhl biB3YXMgKHNlZSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9taW51dGVzL21p bnV0ZXMtOTctZGhjLTAwLnR4dCk6DQoNClRoZSBkaXNjdXNzaW9uIGdyYXZpdGF0ZWQgdG93YXJk cyBub3QgcmVzdXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2Ng0KSS1EIHByb2dyZXNzZXMgZnVy dGhlci4gV2Ugd2lsbCByZWV2YWx1YXRlIHRoaXMgb25jZSBzZWRoY3B2NiBpcyBkb25lLg0KDQoN Ci0gICAgICAgICAgQmVybmllDQoNCkZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy eSAxNSwgMjAxNyAxOjQ5IFBNDQpUbzog56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD4N CkNjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2RoY3dnXSBGd2Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0 DQoNCk9uIEZlYiAxNSwgMjAxNywgYXQgMTozMiBQTSwg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lk ZS5hZC5qcDxtYWlsdG86amlubWVpQHdpZGUuYWQuanA+PiB3cm90ZToNCkkgcGVyc29uYWxseSBk b24ndCB0aGluayBpdCBhIGJsb2NraW5nIGlzc3VlIGZvciBzZWRoY3B2NiwgYnV0LCBvZg0KY291 cnNlLCB0aGUgd2cgc2hvdWxkIGRlY2lkZSBpdC4NCg0KSXQgZGVmaW5pdGVseSBpc24ndCBhIGJs b2NraW5nIGlzc3VlLCBidXQgRnJlZCBpcyByaWdodCB0aGF0IGlmIHdlIGFyZSBnb2luZyBhaGVh ZCB3aXRoIGVuY3J5cHRpb24tb25seSwgd2hpY2ggSSBhZ3JlZSBpcyB0aGUgcmlnaHQgbW92ZSwg d2UgbmVlZCB0byBkbyB0aGlzIHdvcmsgYXMgd2VsbC4NCg0K --_000_9d9d50b20005459aafffcd8f64bfb281XCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXI7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJ cGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBo LCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2lu LXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJn aW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1NTExNTkyNDA7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjk3NzIwMjc2MiAtMzk2NDMyMTY0 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2UiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHByZXNlbnRlZCBh Ym91dCByZXN1cnJlY3RpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LWFnZW50b3B0LWRlbGVnYXRl IGF0IElFVEYtOTcgKHNlZSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlk ZXMvc2xpZGVzLTk3LWRoYy1yZXN1cnJlY3QtZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LWFnZW50b3B0 LWRlbGVnYXRlLTAwLnBkZikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5BbmQgdGhlIGNvbmNsdXNpb24gdGhlbiB3YXMgKHNlZSBodHRwczovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy85Ny9taW51dGVzL21pbnV0ZXMtOTctZGhjLTAwLnR4dCk6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgZGlzY3Vzc2lvbiBncmF2aXRhdGVkIHRvd2Fy ZHMgbm90IHJlc3VycmVjdGluZyB1bnRpbCB0aGUgc2VkaGNwdjY8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SS1EIHByb2dy ZXNzZXMgZnVydGhlci4gV2Ugd2lsbCByZWV2YWx1YXRlIHRoaXMgb25jZSBzZWRoY3B2NiBpcyBk b25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXJuaWU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGRoY3dnIFttYWlsdG86ZGhjd2ct Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGVkIExlbW9uPGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTUsIDIwMTcgMTo0OSBQTTxicj4NCjxiPlRv OjwvYj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O01TIEdvdGhpYyZxdW90OyI+56We5piO6YGU5ZOJPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ ICZsdDtqaW5tZWlAd2lkZS5hZC5qcCZndDs8YnI+DQo8Yj5DYzo8L2I+IGRoY3dnICZsdDtkaGN3 Z0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkaGN3Z10gRndkOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAxNSwg MjAxNywgYXQgMTozMiBQTSwgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNo byZxdW90OyI+DQrnpZ7mmI7pgZTlk4k8L3NwYW4+ICZsdDs8YSBocmVmPSJtYWlsdG86amlubWVp QHdpZGUuYWQuanAiPmppbm1laUB3aWRlLmFkLmpwPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJp ZiI+SSBwZXJzb25hbGx5IGRvbid0IHRoaW5rIGl0IGEgYmxvY2tpbmcgaXNzdWUgZm9yIHNlZGhj cHY2LCBidXQsIG9mPGJyPg0KY291cnNlLCB0aGUgd2cgc2hvdWxkIGRlY2lkZSBpdC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXQgZGVmaW5pdGVseSBpc24ndCBhIGJsb2NraW5nIGlzc3VlLCBidXQgRnJlZCBpcyBy aWdodCB0aGF0IGlmIHdlIGFyZSBnb2luZyBhaGVhZCB3aXRoIGVuY3J5cHRpb24tb25seSwgd2hp Y2ggSSBhZ3JlZSBpcyB0aGUgcmlnaHQgbW92ZSwgd2UgbmVlZCB0byBkbyB0aGlzIHdvcmsgYXMg d2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_9d9d50b20005459aafffcd8f64bfb281XCHALN003ciscocom_-- From nobody Thu Feb 16 18:26:24 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550C5129463; Thu, 16 Feb 2017 18:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ss_vv3ANi1XQ; Thu, 16 Feb 2017 18:26:21 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB540129400; Thu, 16 Feb 2017 18:26:20 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id t47so23819709ota.1; Thu, 16 Feb 2017 18:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=95IXckRYJaRQ1Iprrl21oTpi/RwjVUD+jQtfEcd4YWA=; b=IoneRJy8pajY1fTlz638zAM+Z7sJ4ky7wMGtlvWWH+Du5+i6lCQ6T6vmKDq+9XiRIv 3pbEViShWQl1jE5AAsV7wKAuELVHYrXKFRrowkdFVpUPNU1mUnGjjzVlMcpu1CeKxH90 sbNynIDrRj8fmBaKwQQeM8Z4ATNukIepzLomzExhqu4SF6dyNveWZi7xui4pwNK8MQgX UgNt7EZB2/EtLqdKnH5pHP0i5VOn+7iGGy9QB9zX4xGFKw4E7TtcfqDyky1nt1pppryR 4Nxl+/nKaIEI/yn7+hP7VHLvMzHWuH3qKLLUmLllBZx+c1n1sXoRiH6uy2QRZCWVtmxP hVeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=95IXckRYJaRQ1Iprrl21oTpi/RwjVUD+jQtfEcd4YWA=; b=SpqKachl//IvwU9bynUy9u3+jCS1dPqqmo4pNOStoVZ3rWTrRNAYW50JZoBrZkKXsZ Fn9I0l0aRzo3PdO3qOsZrl1GSBZ/5AxpGunjnAuyo2XOySls1vDgicsr8/IyLhGfa2oP RKfJSF72U7cecThkLv4/JJ8oopQOsXcjEyhFWNbJYRmtZqdrnOR55vyNYILMqieI9jZu CfjCbQe2RjLe4Nbvf2RN/1DNv+2Yt2FP9FRlj80AQ+KGGHIdn5+tVZN1q1xWkRkQQKar kPuOTkjnaC1txSVk0xAfybnLEJWu+X2gYRbNdNDpH2h01+7KqrJI5o3+oE2B8+DDzXIN 3ZZg== X-Gm-Message-State: AMke39lQD7u/LW+ZjnpdbpUMR+pKSPz9q1a50c39rc/Tfx9EmEmpreoNQrTMYi6Sk1x3LaTjNQCXUei8kLYvaQ== X-Received: by 10.157.15.154 with SMTP id d26mr395010otd.186.1487298380290; Thu, 16 Feb 2017 18:26:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.1.202 with HTTP; Thu, 16 Feb 2017 18:25:40 -0800 (PST) In-Reply-To: <148724019438.15925.5760161471481830737.idtracker@ietfa.amsl.com> References: <148724019438.15925.5760161471481830737.idtracker@ietfa.amsl.com> From: tianxiang li Date: Fri, 17 Feb 2017 10:25:40 +0800 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=001a113cf206a1e0ba0548b0a3ca Archived-At: Cc: dhc-chairs@ietf.org, Bernie Volz , The IESG , dhcwg , draft-ietf-dhc-dhcpv6-prefix-length-hint-issue@ietf.org Subject: Re: [dhcwg] Benoit Claise's No Objection on draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: (with COMMENT) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 02:26:22 -0000 --001a113cf206a1e0ba0548b0a3ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Benoit, Thanks for the review and comments. Please see inline. Cheers, Tianxiang 2017-02-16 18:16 GMT+08:00 Benoit Claise : > Benoit Claise has entered the following ballot position for > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefi > x-length-hint-issue/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > >From the draft: > [RFC3633] is unclear about how the client and server should act in > different situations involving the prefix-length hint. > >From the shepherd write-up > This document specifies information that is useful to DHCPv6 client > and server implementers to support allowing clients to specify a > prefix length hint when requested delegated prefixes. It clarifies > this concept introduced in RFC 3633. > > =3D> that implies an UPDATE, no? > Obviously, this document publication should go forward (so not a > DISCUSS), but I would like to understand why this is not an update. > [Tianxiang] This point was raised during several of the reviews, I think the general consensus is that this document should update RFC 3633, and also point people looking at RFC3633 to this document. We would make this edit in the update. > > Editorial nit (by Sue Hares, part of her OPS DIR review): > > Page 3 section 3.1 section under problem. Second paragraph. Second > sentence > > The best way to assure a completely new delegated prefix is to send a new > IAID in the IA_PD. > IAID =E2=80=93 abbreviation has not been indicated prior to this use > Old:/IAID/ > New: /IAID (IA_PD unique identifier)/ > > [Tianxiang] Thanks you for the reminder, we would make the edit as Bernie mentioned in the email. Old: IAID New: IAID (Identity Association IDentifier) --001a113cf206a1e0ba0548b0a3ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit,

Thanks for the review and co= mments.
Please see inline.

Cheers,
=
Tianxiang

2017-02-16 18:16 GMT+08:00 Benoit Claise <bclaise@cisco.com>:
Benoit Claise h= as entered the following ballot position for
draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.= ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/<= br>


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

>From the draft:
=C2=A0 =C2=A0[RFC3633] is unclear about how the client and server should ac= t in
=C2=A0 =C2=A0different situations involving the prefix-length hint.
>From the shepherd write-up
=C2=A0 =C2=A0This document specifies information that is useful to DHCPv6 c= lient
=C2=A0 =C2=A0and server implementers to support allowing clients to specify= a
=C2=A0 =C2=A0prefix length hint when requested delegated prefixes. It clari= fies
=C2=A0 =C2=A0this concept introduced in RFC 3633.

=3D> that implies an UPDATE, no?
Obviously, this document publication should go forward (so not a
DISCUSS), but I would like to understand why this is not an update.

[Tianxiang] This point was raised during sever= al of the reviews, I think the general consensus is that this document shou= ld update RFC 3633, and also point people looking at RFC3633 to this docume= nt. We would make this edit in the update.=C2=A0

Editorial nit (by Sue Hares, part of her OPS DIR review):

Page 3 section 3.1 section under problem.=C2=A0 Second paragraph.=C2=A0 Sec= ond
sentence

The best way to assure a completely new delegated prefix is to send a new IAID in the IA_PD.
IAID =E2=80=93 abbreviation has not been indicated prior to this use
Old:/IAID/
New: /IAID (IA_PD unique identifier)/

[Tianxiang] Thanks you for the reminder, we would mak= e the edit as Bernie mentioned in the email.
=C2=A0
Old= : IAID
New:=C2=A0IAID (Identity As= sociation IDentifier)

--001a113cf206a1e0ba0548b0a3ca-- From nobody Thu Feb 16 18:31:20 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2C91297AA; Thu, 16 Feb 2017 18:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tzeFO1MENlrK; Thu, 16 Feb 2017 18:31:11 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD65128B44; Thu, 16 Feb 2017 18:31:11 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id k4so3649026otc.0; Thu, 16 Feb 2017 18:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=el0TV7Fss4KtkJo20COfFrqTMTOg84hSyPjho2dru5U=; b=c3zFCRvjpRt5Tzx3XaGYQzlC4njOiC/2ccjbc5cGKLm0RydVod9Kr1fYqx4V1+hPXT dwwvEN7B6QLELCiFpIKJR+Xpi1pV3D7n3fJKFpRKek4cIJXi7IogRJgeN1+rs3S4C8Sh hkPwEo8IMom52W7wrkvfH6a0Pe3+IwKwZoF8paNryASY1moZKgK/svPYYtf5pFThwrDR KinFOL4W3Q+140fsD6pnDYTzht+bEvj4BRL3ZCpI1o+LaUKaKu2C0gGPgXZZja7UHv60 FjRJwt7V+8sr9slj40C91y4/8E4tduitWZsbR4jDE4+Wnpiw3VeSs9+qbZ/vym/ib6B/ LMzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=el0TV7Fss4KtkJo20COfFrqTMTOg84hSyPjho2dru5U=; b=uLf1M2aU2CJbjb99o9y1blSKLjBF1W4JRhez/0tRm2S2SXdFpTMelX2jkMIq6zZg4f Q6KT2DXIt5WHH9kAqX7x9zk3jwaIN1wVyRkDfld2l3HPTJCynTdWieUYzgO0MtjerREX 7bgoDGUhmrruKEx+6qXnol6oQVKz55cz2tbtMYEBqaXGKUe+Qd3xwLJ/k/Ra2EKNGmmD P6dAXLhEiNljVeWsm62jTtN18y7vV3/rMMS6Kb/UjS+z/0n5NyXwOLwU8TJVE8UL6PQ9 x/XMtueLSs9vh7CVfwphTOFbFVYmrE01T6RIn9drCpQbUv2yjKyxkSb8j5d53HHiyYzP /uEg== X-Gm-Message-State: AMke39lOGkpWMLAIiyqHj/qWB3fTLLB6Pbby5uDuPDCd0Bcqsjo+8yy3AgaKvYjrAfYZsLr4nBa3i3//nQlHDA== X-Received: by 10.157.15.154 with SMTP id d26mr402068otd.186.1487298670854; Thu, 16 Feb 2017 18:31:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.1.202 with HTTP; Thu, 16 Feb 2017 18:30:30 -0800 (PST) In-Reply-To: References: <148568056700.24536.11691583944564362484.idtracker@ietfa.amsl.com> From: tianxiang li Date: Fri, 17 Feb 2017 10:30:30 +0800 Message-ID: To: Jari Arkko Content-Type: multipart/alternative; boundary=001a113cf206f386ab0548b0b439 Archived-At: Cc: dhcwg , gen-art@ietf.org, Roni Even , ietf@ietf.org, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@ietf.org Subject: Re: [dhcwg] [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 02:31:12 -0000 --001a113cf206f386ab0548b0b439 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jari, Thank you for the support, and thanks to Roni as well as all the other kind reviewers of this document. We would update a new version of the document soon and cover the points raised during last call. Thanks and best regards, Tianxiang 2017-02-16 20:04 GMT+08:00 Jari Arkko : > Roni: thanks for your detailed review. I also appreciate > the responses and changes by you Tianxiang. I have > balloted no-objection for this document for today=E2=80=99s > IESG telechat, and expect that the discussed changes > will find themselves into a new document version at > some point. > > Jari > > --001a113cf206f386ab0548b0b439 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jari,

Thank you for the support, and= thanks to Roni as well as all the other kind reviewers of this document.
We would update a new version of the document soon and cover the p= oints raised during last call.=C2=A0

Thanks and be= st regards,
Tianxiang

<= div class=3D"gmail_quote">2017-02-16 20:04 GMT+08:00 Jari Arkko <jari= .arkko@piuha.net>:
Roni: th= anks for your detailed review. I also appreciate
the responses and changes by you Tianxiang. I have
balloted no-objection for this document for today=E2=80=99s
IESG telechat, and expect that the discussed changes
will find themselves into a new document version at
some point.

Jari


--001a113cf206f386ab0548b0b439-- From nobody Thu Feb 16 21:32:46 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1A11294EE for ; Thu, 16 Feb 2017 21:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wfLuYiCj3klH for ; Thu, 16 Feb 2017 21:32:44 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2899612946D for ; Thu, 16 Feb 2017 21:32:44 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id 45so25528848otd.2 for ; Thu, 16 Feb 2017 21:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=UJ8sjrkEJq2fS2s3dXT4aiTMe+eyn54+3oZk0iFrQBk=; b=rPtPZILutHR+/hIKVB9tbiMfNYto/5zrBkEeiv7BYhdXcGyc0EUjz5IvmQHOcVPV+J nErWb9uc81XZS5E2+PSNntv91wsoOap0YnPMh8bIbFYKMT8fOqliPaWL2AJ9nrcyKpR0 EPv7oFj5hMyZ1v47JUXYGs3eMC0Z9XjoHBfSbzNcXWz2ASM9yiMKjOORV1hTLGXLm1fW OGFcg/J/ZJ4kLlBMsCcTSMIg2740Pg9r3ao5VR6+Hmm8SZhvEFqbNW67pGThTe9iZXQH 6aX4E2Ix8yq7L5vnOcFszsk1YlPXUhEJshYfMDiXs5/7RfX8KNLednqq6UaAaLt7uBeZ ZqQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=UJ8sjrkEJq2fS2s3dXT4aiTMe+eyn54+3oZk0iFrQBk=; b=l2ixbpxwyulG4Etl5Qooih4T+Jc4sWPp0oG6MJC9eRWcvovZ4CCnTb16PgJ7sHAe0I LaNxzMOQZkQ2HNX9eDr4VtOXFru/2c9ZV/XZXyva178y3yyZWFrNfv+dotGKS5ReEc1C T+FMp8quxev7oZ1lOUm0hJAGxMKC1Y7FcJlZ8+34O/jL4Bj+sX3zT5+91Pf3+i4aS+tx S75TRln/R3+d+BsKIIbM0rkJxV1C62GwnzWt32eB3y8PFnstSYjI8wZ4aObD39fRkdR8 VrlG5JBGRpcUpjUSPUFr33n91LMvJaDkwItAWPTlztIpyLjaXlDnuSbQZ1ZfovfFh7zW vMDg== X-Gm-Message-State: AMke39kLGpiMFskWrJSktGUsDiGBlAQZSlyPrXdwatUFos2uhJ/duXYX95VQDOluXE6O9r0Hb4P72LtIcyWjeg== X-Received: by 10.157.27.169 with SMTP id z38mr3193344otd.262.1487309563591; Thu, 16 Feb 2017 21:32:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.1.202 with HTTP; Thu, 16 Feb 2017 21:32:03 -0800 (PST) From: tianxiang li Date: Fri, 17 Feb 2017 13:32:03 +0800 Message-ID: To: dhcwg Content-Type: multipart/alternative; boundary=001a113cc7fa3583250548b33e9c Archived-At: Cc: "Bernie Volz \(volz\)" Subject: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 05:32:45 -0000 --001a113cc7fa3583250548b33e9c Content-Type: text/plain; charset=UTF-8 Hi all, The IESG review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue has ended, several reviewers suggested this document should update RFC 3633, as someone reading RFC3633 would need a pointer to this document. Hope to receive the comments from the WG regarding this issue. And if so, do we need to add a specific tag in the xml file stating that it updates RFC 3633 and change the title of the document? Hope to receive your advice. Thank you, Tianxiang --001a113cc7fa3583250548b33e9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

The IESG review of draft-= ietf-dhc-dhcpv6-prefix-length-hint-issue has ended, several reviewers sugge= sted this document should update RFC 3633, as someone reading RFC3633 would= need a pointer to this document. Hope to receive the comments from the WG = regarding this issue.=C2=A0

And if so, do we need to add= a specific tag in the xml file stating that it updates RFC 3633 and change= the title of the document?

Hope to receive y= our advice.

Thank you,
Tianxiang
--001a113cc7fa3583250548b33e9c-- From nobody Fri Feb 17 14:35:03 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4D51296CC for ; Fri, 17 Feb 2017 14:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 MmaXBuhdws6I for ; Fri, 17 Feb 2017 14:35:00 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034D71294A5 for ; Fri, 17 Feb 2017 14:34:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1HMYxU1039486; Fri, 17 Feb 2017 15:34:59 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1HMYovP039042 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 17 Feb 2017 15:34:50 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 17 Feb 2017 14:34:49 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 17 Feb 2017 14:34:49 -0800 From: "Templin, Fred L" To: "Bernie Volz (volz)" , Ted Lemon , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSglOjbTsgor1qYk63PeyrUa0poqFqmOCwgAHRRkCAAWtvcA== Date: Fri, 17 Feb 2017 22:34:49 +0000 Message-ID: <21bd317edc764fc89dc4a13aa541b1c1@XCH15-06-08.nw.nos.boeing.com> References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> In-Reply-To: <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_21bd317edc764fc89dc4a13aa541b1c1XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 22:35:02 -0000 --_000_21bd317edc764fc89dc4a13aa541b1c1XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVybmllLA0KDQpUaGUgZGlzY3Vzc2lvbiBncmF2aXRhdGVkIHRvd2FyZHMgbm90IHJlc3VycmVj dGluZyB1bnRpbCB0aGUgc2VkaGNwdjYNCkktRCBwcm9ncmVzc2VzIGZ1cnRoZXIuIFdlIHdpbGwg cmVldmFsdWF0ZSB0aGlzIG9uY2Ugc2VkaGNwdjYgaXMgZG9uZS4NCg0KVGhpcyBkb2VzIG5vdCBt YWtlIHNlbnNlIHRvIG1lOyBzZWRoY3B2NiBpcyB0aGUgdmVyeSByZWFzb24gdGhhdCBSQUFOIGlz IGltcG9ydGFudC4NCkp1c3QgbGlrZSBSRkMzOTcxIGRpZCB3aXRoIElQdjYgTkQgVGltZXN0YW1w IGFuZCBOb25jZSBvcHRpb25zLCBzZWRoY3B2NiBjb3VsZA0KZGVmaW5lIHRoZSBSQUFOIG9wZXJh dGlvbiBhbmQgaGF2ZSBldmVyeXRoaW5nIG92ZXIgYW5kIGRvbmUgd2l0aCBpbiBvbmUgcGFzcy4N CkFuZCwgSSBoYXZlIGFscmVhZHkgaWRlbnRpZmllZCBhIHVzZSBjYXNlIHdoZXJlIFJBQU4gaXMg YWJzb2x1dGVseSBuZWNlc3NhcnkuDQpBbHNvLCBJIHdhcyB1bmFibGUgdG8gYXR0ZW5kICBJRVRG OTcsIHdoZXJlIEkgY2VydGFpbmx5IHdvdWxkIGhhdmUgc3Rvb2QgdXAgYW5kDQp2b2ljZWQgbXkg cG9zaXRpb24uDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogZGhjd2cgW21haWx0bzpkaGN3Zy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVybmllIFZvbHogKHZvbHopDQpTZW50OiBU aHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTcgMjozOSBQTQ0KVG86IFRlZCBMZW1vbiA8bWVsbG9u QGZ1Z3VlLmNvbT47IOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUuYWQuanA+DQpDYzogZGhjd2cg PGRoY3dnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dA0KDQpJIHByZXNl bnRlZCBhYm91dCByZXN1cnJlY3RpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LWFnZW50b3B0LWRl bGVnYXRlIGF0IElFVEYtOTcgKHNlZSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 Ny9zbGlkZXMvc2xpZGVzLTk3LWRoYy1yZXN1cnJlY3QtZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LWFn ZW50b3B0LWRlbGVnYXRlLTAwLnBkZikuDQoNCkFuZCB0aGUgY29uY2x1c2lvbiB0aGVuIHdhcyAo c2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L21pbnV0ZXMvbWludXRlcy05 Ny1kaGMtMDAudHh0KToNCg0KVGhlIGRpc2N1c3Npb24gZ3Jhdml0YXRlZCB0b3dhcmRzIG5vdCBy ZXN1cnJlY3RpbmcgdW50aWwgdGhlIHNlZGhjcHY2DQpJLUQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBX ZSB3aWxsIHJlZXZhbHVhdGUgdGhpcyBvbmNlIHNlZGhjcHY2IGlzIGRvbmUuDQoNCg0KLSAgICAg ICAgICBCZXJuaWUNCg0KRnJvbTogZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgVGVkIExlbW9uDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAy MDE3IDE6NDkgUE0NClRvOiDnpZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPG1haWx0bzpq aW5tZWlAd2lkZS5hZC5qcD4+DQpDYzogZGhjd2cgPGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3 Z0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0DQoNCk9uIEZlYiAxNSwg MjAxNywgYXQgMTozMiBQTSwg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcDxtYWlsdG86 amlubWVpQHdpZGUuYWQuanA+PiB3cm90ZToNCkkgcGVyc29uYWxseSBkb24ndCB0aGluayBpdCBh IGJsb2NraW5nIGlzc3VlIGZvciBzZWRoY3B2NiwgYnV0LCBvZg0KY291cnNlLCB0aGUgd2cgc2hv dWxkIGRlY2lkZSBpdC4NCg0KSXQgZGVmaW5pdGVseSBpc24ndCBhIGJsb2NraW5nIGlzc3VlLCBi dXQgRnJlZCBpcyByaWdodCB0aGF0IGlmIHdlIGFyZSBnb2luZyBhaGVhZCB3aXRoIGVuY3J5cHRp b24tb25seSwgd2hpY2ggSSBhZ3JlZSBpcyB0aGUgcmlnaHQgbW92ZSwgd2UgbmVlZCB0byBkbyB0 aGlzIHdvcmsgYXMgd2VsbC4NCg0K --_000_21bd317edc764fc89dc4a13aa541b1c1XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXI7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIg NiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1NTExNTkyNDA7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjk3NzIwMjc2 MiAtMzk2NDMyMTY0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5CZXJuaWUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5UaGUgZGlzY3Vzc2lvbiBncmF2aXRhdGVkIHRvd2FyZHMgbm90IHJlc3VycmVjdGluZyB1 bnRpbCB0aGUgc2VkaGNwdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SS1EIHByb2dyZXNzZXMgZnVydGhlci4gV2Ugd2ls bCByZWV2YWx1YXRlIHRoaXMgb25jZSBzZWRoY3B2NiBpcyBkb25lLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIG1l OyBzZWRoY3B2NiBpcyB0aGUgdmVyeSByZWFzb24gdGhhdCBSQUFOIGlzIGltcG9ydGFudC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SnVzdCBsaWtlIFJGQzM5NzEgZGlkIHdpdGggSVB2NiBORCBUaW1lc3Rh bXAgYW5kIE5vbmNlIG9wdGlvbnMsIHNlZGhjcHY2IGNvdWxkPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmRl ZmluZSB0aGUgUkFBTiBvcGVyYXRpb24gYW5kIGhhdmUgZXZlcnl0aGluZyBvdmVyIGFuZCBkb25l IHdpdGggaW4gb25lIHBhc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCwgSSBoYXZlIGFscmVhZHkg aWRlbnRpZmllZCBhIHVzZSBjYXNlIHdoZXJlIFJBQU4gaXMgYWJzb2x1dGVseSBuZWNlc3Nhcnku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkFsc28sIEkgd2FzIHVuYWJsZSB0byBhdHRlbmQgJm5ic3A7SUVU Rjk3LCB3aGVyZSBJIGNlcnRhaW5seSB3b3VsZCBoYXZlIHN0b29kIHVwIGFuZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj52b2ljZWQgbXkgcG9zaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gZGhjd2cgW21haWx0bzpkaGN3 Zy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZXJuaWUgVm9seiAodm9s eik8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE3IDI6MzkgUE08 YnI+DQo8Yj5Ubzo8L2I+IFRlZCBMZW1vbiAmbHQ7bWVsbG9uQGZ1Z3VlLmNvbSZndDs7IDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3Ro aWMmcXVvdDsiPuelnuaYjumBlOWTiTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiAmbHQ7amlubWVp QHdpZGUuYWQuanAmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkaGN3ZyAmbHQ7ZGhjd2dAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SSBwcmVzZW50ZWQgYWJvdXQgcmVzdXJyZWN0aW5nIGRyYWZ0LWlldGYtZGhjLWRo Y3B2Ni1hZ2VudG9wdC1kZWxlZ2F0ZSBhdCBJRVRGLTk3IChzZWUNCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L3NsaWRlcy9zbGlkZXMtOTctZGhjLXJlc3VycmVj dC1kcmFmdC1pZXRmLWRoYy1kaGNwdjYtYWdlbnRvcHQtZGVsZWdhdGUtMDAucGRmIj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L3NsaWRlcy9zbGlkZXMtOTctZGhjLXJlc3Vy cmVjdC1kcmFmdC1pZXRmLWRoYy1kaGNwdjYtYWdlbnRvcHQtZGVsZWdhdGUtMDAucGRmPC9hPiku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmQgdGhlIGNvbmNs dXNpb24gdGhlbiB3YXMgKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTcvbWludXRlcy9taW51dGVzLTk3LWRoYy0wMC50eHQiPmh0dHBzOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzk3L21pbnV0ZXMvbWludXRlcy05Ny1kaGMtMDAudHh0PC9hPik6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgZGlzY3Vzc2lvbiBncmF2aXRhdGVk IHRvd2FyZHMgbm90IHJlc3VycmVjdGluZyB1bnRpbCB0aGUgc2VkaGNwdjY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SS1E IHByb2dyZXNzZXMgZnVydGhlci4gV2Ugd2lsbCByZWV2YWx1YXRlIHRoaXMgb25jZSBzZWRoY3B2 NiBpcyBkb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXJuaWU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGRoY3dnIFs8YSBocmVm PSJtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UZWQgTGVtb248YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxNyAxOjQ5IFBNPGJyPg0KPGI+VG86PC9iPiA8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMg R290aGljJnF1b3Q7Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gJmx0Ozxh IGhyZWY9Im1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcCI+amlubWVpQHdpZGUuYWQuanA8L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gZGhjd2cgJmx0OzxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9y ZyI+ZGhjd2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RoY3dn XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNw djYtMjAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRmViIDE1LCAyMDE3LCBhdCAxOjMyIFBNLCA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgTWluY2hvJnF1b3Q7Ij4NCuelnuaYjumBlOWTiTwvc3Bhbj4gJmx0OzxhIGhyZWY9Im1h aWx0bzpqaW5tZWlAd2lkZS5hZC5qcCI+amlubWVpQHdpZGUuYWQuanA8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyIj5JIHBl cnNvbmFsbHkgZG9uJ3QgdGhpbmsgaXQgYSBibG9ja2luZyBpc3N1ZSBmb3Igc2VkaGNwdjYsIGJ1 dCwgb2Y8YnI+DQpjb3Vyc2UsIHRoZSB3ZyBzaG91bGQgZGVjaWRlIGl0Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J dCBkZWZpbml0ZWx5IGlzbid0IGEgYmxvY2tpbmcgaXNzdWUsIGJ1dCBGcmVkIGlzIHJpZ2h0IHRo YXQgaWYgd2UgYXJlIGdvaW5nIGFoZWFkIHdpdGggZW5jcnlwdGlvbi1vbmx5LCB3aGljaCBJIGFn cmVlIGlzIHRoZSByaWdodCBtb3ZlLCB3ZSBuZWVkIHRvIGRvIHRoaXMgd29yayBhcyB3ZWxsLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_21bd317edc764fc89dc4a13aa541b1c1XCH150608nwnosboeingcom_-- From nobody Fri Feb 17 15:00:27 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B761296F6 for ; Fri, 17 Feb 2017 15:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 zN0aODxEYMcg for ; Fri, 17 Feb 2017 15:00:24 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217A41296D2 for ; Fri, 17 Feb 2017 15:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28568; q=dns/txt; s=iport; t=1487372424; x=1488582024; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w7tuDCKttBzx16ccrTIjR3aykTg6+BQjk30Z52/BvqQ=; b=KidlIMBALqkvrAbA98ZTBmIah4K5P/7N2XC3oKjbGa5DyLCWEtJEC2u0 ogL746Ko8kDdJsR4/mmLiBnNGXUSn7fLdAsM+yFd4r3nW1sjHW7un5POi xvq9r01MWpfi/tGxTNGEBH+liAF3m2HxM4NOOdJeNwKFsrRRcWg13cyoV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAQDaf6dY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB4NTigiSFpU0ggwuhXQCGoILPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBAgIjCkoCEAIBBgIRBAEBIQcDAgICMBQJCAIEAQ0FCBOJUQ6SeJ1YgiWLW?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBARgFizuEPkyCUIJfBZVdhiQBkg+REZMdAR8?= =?us-ascii?q?4gQBRFYUDHYFhdQGKA4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,173,1484006400"; d="scan'208,217";a="387006673" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2017 23:00:23 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v1HN0MW7005342 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Feb 2017 23:00:22 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Feb 2017 17:00:22 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Fri, 17 Feb 2017 17:00:22 -0600 From: "Bernie Volz (volz)" To: "Templin, Fred L" , Ted Lemon , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSb9dh9mAfGPV9aE2109Imxv8IT6FqmOCwgAHRRkCAAfbYgP//oAvA Date: Fri, 17 Feb 2017 23:00:21 +0000 Message-ID: <3e5776023c0d447aaccb81dc8ec8724a@XCH-ALN-003.cisco.com> References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> <21bd317edc764fc89dc4a13aa541b1c1@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <21bd317edc764fc89dc4a13aa541b1c1@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.204] Content-Type: multipart/alternative; boundary="_000_3e5776023c0d447aaccb81dc8ec8724aXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 23:00:26 -0000 --_000_3e5776023c0d447aaccb81dc8ec8724aXCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgcGxhbiBoZXJlIG1ha2VzIHNvbWUgc2Vuc2Ug4oCmIHNlREhDUHY2IGhhcyBo YWQgc2V2ZXJhbCBhdHRlbXB0cyBhbmQgYmVlbiBraWNrZWQgYmFjayB0byB0aGUgV0cuIFNvLCBJ IHRoaW5rIHRoZSBXRyB3YW50cyB0byBnbyBzbG93bHkgYW5kIG5vdCBkZXZlbG9wIGEgc29sdXRp b24gdW50aWwgc2VESENQdjYgaXMgbGlrZWx5IHRvIGFkdmFuY2UgaW4gdGhlIElFU0cgKGVuY3J5 cHRpb24gd2FzIG9ubHkgYWRkZWQgZmFpcmx5IOKAnHJlY2VudGx54oCdKS4NCg0KQW5kLCBpdCBp c27igJl0IGxpa2UgdGhlIGRheSBhZnRlciBzZURIQ1B2NiBpcyDigJxhcHByb3ZlZOKAnSB0aGF0 IGV2ZXJ5IGNsaWVudCAoYW5kIHNlcnZlcikgd2lsbCBzdXBwb3J0IHRoaXMuIEl0IHdpbGwgdGFr ZSB0aW1lIHRvIHJvbGwgb3V0LiBBbmQsIGhvcGVmdWxseSB3ZSBjYW4gZ2V0IHRoZSBSQUFOIHdv cmsgb3V0IGluIGEgZmFpcmx5IHNob3J0IHRpbWUuDQoNCkluIHlvdXIgbmV0d29ya3MsIGlmIHlv dSBjYW7igJl0IHN1cHBvcnQgc2VESENQdjYgdW50aWwgeW91IGhhdmUgc29tZXRoaW5nIHRvIHNv IHNvbHZlIHRoZSBSQUFOIGlzc3VlcywgeW91IG9idmlvdXNseSBjYW7igJl0IGRlcGxveSBzZURI Q1B2Ni4gQnV0IHRoZXJlIG1heSBiZSBwbGVudHkgb2Ygb3RoZXIgbmV0d29ya3Mgd2hlcmUgdGhp cyBpc27igJl0IGFuIGlzc3VlIGFuZCBpdCBjb3VsZCBzdGFydCB0byBiZSBkZXBsb3llZCAoY29m ZmVlIHNob3BzIGFuZCBlbnRlcnByaXNlcykuDQoNCg0KLSAgICAgICAgICBCZXJuaWUNCg0KRnJv bTogVGVtcGxpbiwgRnJlZCBMIFttYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbV0NClNl bnQ6IEZyaWRheSwgRmVicnVhcnkgMTcsIDIwMTcgNTozNSBQTQ0KVG86IEJlcm5pZSBWb2x6ICh2 b2x6KSA8dm9sekBjaXNjby5jb20+OyBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+OyDnpZ7m mI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPg0KQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQNCg0KQmVybmllLA0KDQpUaGUgZGlzY3Vzc2lv biBncmF2aXRhdGVkIHRvd2FyZHMgbm90IHJlc3VycmVjdGluZyB1bnRpbCB0aGUgc2VkaGNwdjYN CkktRCBwcm9ncmVzc2VzIGZ1cnRoZXIuIFdlIHdpbGwgcmVldmFsdWF0ZSB0aGlzIG9uY2Ugc2Vk aGNwdjYgaXMgZG9uZS4NCg0KVGhpcyBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIG1lOyBzZWRoY3B2 NiBpcyB0aGUgdmVyeSByZWFzb24gdGhhdCBSQUFOIGlzIGltcG9ydGFudC4NCkp1c3QgbGlrZSBS RkMzOTcxIGRpZCB3aXRoIElQdjYgTkQgVGltZXN0YW1wIGFuZCBOb25jZSBvcHRpb25zLCBzZWRo Y3B2NiBjb3VsZA0KZGVmaW5lIHRoZSBSQUFOIG9wZXJhdGlvbiBhbmQgaGF2ZSBldmVyeXRoaW5n IG92ZXIgYW5kIGRvbmUgd2l0aCBpbiBvbmUgcGFzcy4NCkFuZCwgSSBoYXZlIGFscmVhZHkgaWRl bnRpZmllZCBhIHVzZSBjYXNlIHdoZXJlIFJBQU4gaXMgYWJzb2x1dGVseSBuZWNlc3NhcnkuDQpB bHNvLCBJIHdhcyB1bmFibGUgdG8gYXR0ZW5kICBJRVRGOTcsIHdoZXJlIEkgY2VydGFpbmx5IHdv dWxkIGhhdmUgc3Rvb2QgdXAgYW5kDQp2b2ljZWQgbXkgcG9zaXRpb24uDQoNClRoYW5rcyAtIEZy ZWQNCg0KRnJvbTogZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQmVybmllIFZvbHogKHZvbHopDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTYsIDIw MTcgMjozOSBQTQ0KVG86IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86bWVsbG9u QGZ1Z3VlLmNvbT4+OyDnpZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPG1haWx0bzpqaW5t ZWlAd2lkZS5hZC5qcD4+DQpDYzogZGhjd2cgPGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0Bp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0DQoNCkkgcHJlc2VudGVkIGFi b3V0IHJlc3VycmVjdGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtYWdlbnRvcHQtZGVsZWdhdGUg YXQgSUVURi05NyAoc2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L3NsaWRl cy9zbGlkZXMtOTctZGhjLXJlc3VycmVjdC1kcmFmdC1pZXRmLWRoYy1kaGNwdjYtYWdlbnRvcHQt ZGVsZWdhdGUtMDAucGRmKS4NCg0KQW5kIHRoZSBjb25jbHVzaW9uIHRoZW4gd2FzIChzZWUgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvbWludXRlcy9taW51dGVzLTk3LWRoYy0w MC50eHQpOg0KDQpUaGUgZGlzY3Vzc2lvbiBncmF2aXRhdGVkIHRvd2FyZHMgbm90IHJlc3VycmVj dGluZyB1bnRpbCB0aGUgc2VkaGNwdjYNCkktRCBwcm9ncmVzc2VzIGZ1cnRoZXIuIFdlIHdpbGwg cmVldmFsdWF0ZSB0aGlzIG9uY2Ugc2VkaGNwdjYgaXMgZG9uZS4NCg0KDQotICAgICAgICAgIEJl cm5pZQ0KDQpGcm9tOiBkaGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBUZWQgTGVtb24NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTUsIDIwMTcgMTo0 OSBQTQ0KVG86IOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUuYWQuanA8bWFpbHRvOmppbm1laUB3 aWRlLmFkLmpwPj4NCkNjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQNCg0KT24gRmViIDE1LCAyMDE3LCBh dCAxOjMyIFBNLCDnpZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPG1haWx0bzpqaW5tZWlA d2lkZS5hZC5qcD4+IHdyb3RlOg0KSSBwZXJzb25hbGx5IGRvbid0IHRoaW5rIGl0IGEgYmxvY2tp bmcgaXNzdWUgZm9yIHNlZGhjcHY2LCBidXQsIG9mDQpjb3Vyc2UsIHRoZSB3ZyBzaG91bGQgZGVj aWRlIGl0Lg0KDQpJdCBkZWZpbml0ZWx5IGlzbid0IGEgYmxvY2tpbmcgaXNzdWUsIGJ1dCBGcmVk IGlzIHJpZ2h0IHRoYXQgaWYgd2UgYXJlIGdvaW5nIGFoZWFkIHdpdGggZW5jcnlwdGlvbi1vbmx5 LCB3aGljaCBJIGFncmVlIGlzIHRoZSByaWdodCBtb3ZlLCB3ZSBuZWVkIHRvIGRvIHRoaXMgd29y ayBhcyB3ZWxsLg0KDQo= --_000_3e5776023c0d447aaccb81dc8ec8724aXCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkg NyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0K CXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpNZW5sby1SZWd1bGFyO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU1MTE1OTI0MDsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6OTc3MjAyNzYyIC0zOTY0MzIxNjQg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28t bGlzdC1pZDoxNTk3NzgzMjQwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotMTk1NzkzNjA5NiAxNjk4NzQ2ODMwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZSBwbGFu IGhlcmUgbWFrZXMgc29tZSBzZW5zZSDigKYgc2VESENQdjYgaGFzIGhhZCBzZXZlcmFsIGF0dGVt cHRzIGFuZCBiZWVuIGtpY2tlZCBiYWNrIHRvIHRoZSBXRy4gU28sIEkgdGhpbmsgdGhlIFdHIHdh bnRzIHRvIGdvIHNsb3dseSBhbmQgbm90IGRldmVsb3ANCiBhIHNvbHV0aW9uIHVudGlsIHNlREhD UHY2IGlzIGxpa2VseSB0byBhZHZhbmNlIGluIHRoZSBJRVNHIChlbmNyeXB0aW9uIHdhcyBvbmx5 IGFkZGVkIGZhaXJseSDigJxyZWNlbnRseeKAnSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5BbmQsIGl0IGlzbuKAmXQgbGlrZSB0aGUgZGF5IGFmdGVyIHNlREhD UHY2IGlzIOKAnGFwcHJvdmVk4oCdIHRoYXQgZXZlcnkgY2xpZW50IChhbmQgc2VydmVyKSB3aWxs IHN1cHBvcnQgdGhpcy4gSXQgd2lsbCB0YWtlIHRpbWUgdG8gcm9sbCBvdXQuIEFuZCwgaG9wZWZ1 bGx5IHdlIGNhbg0KIGdldCB0aGUgUkFBTiB3b3JrIG91dCBpbiBhIGZhaXJseSBzaG9ydCB0aW1l LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4geW91ciBuZXR3 b3JrcywgaWYgeW91IGNhbuKAmXQgc3VwcG9ydCBzZURIQ1B2NiB1bnRpbCB5b3UgaGF2ZSBzb21l dGhpbmcgdG8gc28gc29sdmUgdGhlIFJBQU4gaXNzdWVzLCB5b3Ugb2J2aW91c2x5IGNhbuKAmXQg ZGVwbG95IHNlREhDUHY2LiBCdXQgdGhlcmUgbWF5IGJlIHBsZW50eQ0KIG9mIG90aGVyIG5ldHdv cmtzIHdoZXJlIHRoaXMgaXNu4oCZdCBhbiBpc3N1ZSBhbmQgaXQgY291bGQgc3RhcnQgdG8gYmUg ZGVwbG95ZWQgKGNvZmZlZSBzaG9wcyBhbmQgZW50ZXJwcmlzZXMpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXJuaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IFRlbXBsaW4sIEZyZWQgTCBbbWFpbHRvOkZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAxNywgMjAxNyA1 OjM1IFBNPGJyPg0KPGI+VG86PC9iPiBCZXJuaWUgVm9seiAodm9seikgJmx0O3ZvbHpAY2lzY28u Y29tJmd0OzsgVGVkIExlbW9uICZsdDttZWxsb25AZnVndWUuY29tJmd0OzsgPC9zcGFuPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1 b3Q7Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gJmx0O2ppbm1laUB3aWRl LmFkLmpwJmd0Ozxicj4NCjxiPkNjOjwvYj4gZGhjd2cgJmx0O2RoY3dnQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkJlcm5pZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBkaXNjdXNz aW9uIGdyYXZpdGF0ZWQgdG93YXJkcyBub3QgcmVzdXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2 NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5JLUQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVhdGUgdGhp cyBvbmNlIHNlZGhjcHY2IGlzIGRvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGlzIGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8gbWU7IHNlZGhjcHY2IGlzIHRo ZSB2ZXJ5IHJlYXNvbiB0aGF0IFJBQU4gaXMgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5K dXN0IGxpa2UgUkZDMzk3MSBkaWQgd2l0aCBJUHY2IE5EIFRpbWVzdGFtcCBhbmQgTm9uY2Ugb3B0 aW9ucywgc2VkaGNwdjYgY291bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZGVmaW5lIHRoZSBSQUFOIG9w ZXJhdGlvbiBhbmQgaGF2ZSBldmVyeXRoaW5nIG92ZXIgYW5kIGRvbmUgd2l0aCBpbiBvbmUgcGFz cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kLCBJIGhhdmUgYWxyZWFkeSBpZGVudGlmaWVkIGEgdXNl IGNhc2Ugd2hlcmUgUkFBTiBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+QWxzbywgSSB3YXMgdW5hYmxlIHRvIGF0dGVuZCAmbmJzcDtJRVRGOTcsIHdoZXJlIEkgY2Vy dGFpbmx5IHdvdWxkIGhhdmUgc3Rvb2QgdXAgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnZvaWNlZCBt eSBwb3NpdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo YW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBkaGN3ZyBbPGEgaHJlZj0ibWFpbHRvOmRoY3dnLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+QmVybmllIFZvbHogKHZvbHopPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBGZWJydWFyeSAxNiwgMjAxNyAyOjM5IFBNPGJyPg0KPGI+VG86PC9iPiBUZWQgTGVtb24gJmx0 OzxhIGhyZWY9Im1haWx0bzptZWxsb25AZnVndWUuY29tIj5tZWxsb25AZnVndWUuY29tPC9hPiZn dDs7IDwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O01TIEdvdGhpYyZxdW90OyI+56We5piO6YGU5ZOJPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ ICZsdDs8YSBocmVmPSJtYWlsdG86amlubWVpQHdpZGUuYWQuanAiPmppbm1laUB3aWRlLmFkLmpw PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IGRoY3dnICZsdDs8YSBocmVmPSJtYWlsdG86ZGhjd2dA aWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhj LXNlZGhjcHY2LTIwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHByZXNlbnRlZCBhYm91dCBy ZXN1cnJlY3RpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LWFnZW50b3B0LWRlbGVnYXRlIGF0IElF VEYtOTcgKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcv c2xpZGVzL3NsaWRlcy05Ny1kaGMtcmVzdXJyZWN0LWRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1hZ2Vu dG9wdC1kZWxlZ2F0ZS0wMC5wZGYiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTcvc2xpZGVzL3NsaWRlcy05Ny1kaGMtcmVzdXJyZWN0LWRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1h Z2VudG9wdC1kZWxlZ2F0ZS0wMC5wZGY8L2E+KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkFuZCB0aGUgY29uY2x1c2lvbiB0aGVuIHdhcyAoc2VlDQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9taW51dGVzL21pbnV0ZXMtOTct ZGhjLTAwLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvbWludXRlcy9t aW51dGVzLTk3LWRoYy0wMC50eHQ8L2E+KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPlRoZSBkaXNjdXNzaW9uIGdyYXZpdGF0ZWQgdG93YXJkcyBub3QgcmVzdXJyZWN0aW5nIHVu dGlsIHRoZSBzZWRoY3B2NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JLUQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBXZSB3aWxs IHJlZXZhbHVhdGUgdGhpcyBvbmNlIHNlZGhjcHY2IGlzIGRvbmUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5pZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gZGhjd2cgWzxhIGhyZWY9Im1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlRlZCBMZW1vbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAy MDE3IDE6NDkgUE08YnI+DQo8Yj5Ubzo8L2I+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuelnuaYjumBlOWTiTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1laUB3aWRlLmFk LmpwIj5qaW5tZWlAd2lkZS5hZC5qcDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkaGN3ZyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5kaGN3Z0BpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMTUsIDIwMTcsIGF0IDE6MzIgUE0s IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPg0K56We5piO 6YGU5ZOJPC9zcGFuPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1laUB3aWRlLmFkLmpwIj5qaW5t ZWlAd2lkZS5hZC5qcDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXIiPkkgcGVyc29uYWxseSBkb24ndCB0aGluayBpdCBhIGJs b2NraW5nIGlzc3VlIGZvciBzZWRoY3B2NiwgYnV0LCBvZjxicj4NCmNvdXJzZSwgdGhlIHdnIHNo b3VsZCBkZWNpZGUgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGRlZmluaXRlbHkgaXNuJ3QgYSBibG9ja2lu ZyBpc3N1ZSwgYnV0IEZyZWQgaXMgcmlnaHQgdGhhdCBpZiB3ZSBhcmUgZ29pbmcgYWhlYWQgd2l0 aCBlbmNyeXB0aW9uLW9ubHksIHdoaWNoIEkgYWdyZWUgaXMgdGhlIHJpZ2h0IG1vdmUsIHdlIG5l ZWQgdG8gZG8gdGhpcyB3b3JrIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3e5776023c0d447aaccb81dc8ec8724aXCHALN003ciscocom_-- From nobody Sat Feb 18 08:28:13 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95ED12952F for ; Sat, 18 Feb 2017 08:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8kcVdUze574l for ; Sat, 18 Feb 2017 08:28:09 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0B612949D for ; Sat, 18 Feb 2017 08:28:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1IGS9u6015816; Sat, 18 Feb 2017 09:28:09 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1IGS4C9015706 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Sat, 18 Feb 2017 09:28:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 18 Feb 2017 08:28:04 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Sat, 18 Feb 2017 08:28:03 -0800 From: "Templin, Fred L" To: "Bernie Volz (volz)" , Ted Lemon , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSglOjbTsgor1qYk63PeyrUa0poqFqmOCwgAHRRkCAAWtvcIAAjxqAgACXmWA= Date: Sat, 18 Feb 2017 16:28:03 +0000 Message-ID: <49129cb6c19c4be3bd483ceb3312bd72@XCH15-06-08.nw.nos.boeing.com> References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> <21bd317edc764fc89dc4a13aa541b1c1@XCH15-06-08.nw.nos.boeing.com> <3e5776023c0d447aaccb81dc8ec8724a@XCH-ALN-003.cisco.com> In-Reply-To: <3e5776023c0d447aaccb81dc8ec8724a@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_49129cb6c19c4be3bd483ceb3312bd72XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 16:28:12 -0000 --_000_49129cb6c19c4be3bd483ceb3312bd72XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVybmllLA0KDQpNeSB1bmRlcnN0YW5kaW5nICBpcyB0aGF0IHNlZGhjcHY2IGlzIGludGVu ZGVkIHRvIGJlIGEgcHJvZHVjdCBvZiB0aGUgSUVURiwNCnNvIEkgdGhlcmVmb3JlIGFzc3VtZSB0 aGF0IGl0IGlzIGludGVuZGVkIHRvIGJlIGEgcHJvZHVjdCBvZiBlbmdpbmVlcmluZy4gSXQNCmhh cyBiZWVuIHNob3duIHRoYXQgc2VkaGNwdjYgaGFzIGFuIG9taXNzaW9uIHRoYXQgd2lsbCBsaW1p dCBpdHMgYXBwbGljYWJpbGl0eSwNCmFuZCB0aGF0IHRoYXQgb21pc3Npb24gY2FuIGJlIHJhdGhl ciBlYXNpbHkgcmVtZWRpZWQgcHJpb3IgdG8gcHVibGljYXRpb24uIEl0DQp0aGVyZWZvcmUgbWFr ZXMgZ29vZCBlbmdpbmVlcmluZyBzZW5zZSB0byBmaXggdGhlIG9taXNzaW9uIG5vdy4NCg0KVGhl IHByb3Bvc2FsIGFnYWluIGlzIHRvIGhhdmUgc2VkaGNwdjYgc3BlY2lmeSB0aGUgUkFBTiBvcHRp b24gYXMgcGFydCBvZg0KdGhlIGJhc2UgZG9jdW1lbnQuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJv bTogQmVybmllIFZvbHogKHZvbHopIFttYWlsdG86dm9sekBjaXNjby5jb21dDQpTZW50OiBGcmlk YXksIEZlYnJ1YXJ5IDE3LCAyMDE3IDM6MDAgUE0NClRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQu TC5UZW1wbGluQGJvZWluZy5jb20+OyBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+OyDnpZ7m mI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPg0KQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQNCg0KSSB0aGluayB0aGUgcGxhbiBoZXJlIG1h a2VzIHNvbWUgc2Vuc2Ug4oCmIHNlREhDUHY2IGhhcyBoYWQgc2V2ZXJhbCBhdHRlbXB0cyBhbmQg YmVlbiBraWNrZWQgYmFjayB0byB0aGUgV0cuIFNvLCBJIHRoaW5rIHRoZSBXRyB3YW50cyB0byBn byBzbG93bHkgYW5kIG5vdCBkZXZlbG9wIGEgc29sdXRpb24gdW50aWwgc2VESENQdjYgaXMgbGlr ZWx5IHRvIGFkdmFuY2UgaW4gdGhlIElFU0cgKGVuY3J5cHRpb24gd2FzIG9ubHkgYWRkZWQgZmFp cmx5IOKAnHJlY2VudGx54oCdKS4NCg0KQW5kLCBpdCBpc27igJl0IGxpa2UgdGhlIGRheSBhZnRl ciBzZURIQ1B2NiBpcyDigJxhcHByb3ZlZOKAnSB0aGF0IGV2ZXJ5IGNsaWVudCAoYW5kIHNlcnZl cikgd2lsbCBzdXBwb3J0IHRoaXMuIEl0IHdpbGwgdGFrZSB0aW1lIHRvIHJvbGwgb3V0LiBBbmQs IGhvcGVmdWxseSB3ZSBjYW4gZ2V0IHRoZSBSQUFOIHdvcmsgb3V0IGluIGEgZmFpcmx5IHNob3J0 IHRpbWUuDQoNCkluIHlvdXIgbmV0d29ya3MsIGlmIHlvdSBjYW7igJl0IHN1cHBvcnQgc2VESENQ djYgdW50aWwgeW91IGhhdmUgc29tZXRoaW5nIHRvIHNvIHNvbHZlIHRoZSBSQUFOIGlzc3Vlcywg eW91IG9idmlvdXNseSBjYW7igJl0IGRlcGxveSBzZURIQ1B2Ni4gQnV0IHRoZXJlIG1heSBiZSBw bGVudHkgb2Ygb3RoZXIgbmV0d29ya3Mgd2hlcmUgdGhpcyBpc27igJl0IGFuIGlzc3VlIGFuZCBp dCBjb3VsZCBzdGFydCB0byBiZSBkZXBsb3llZCAoY29mZmVlIHNob3BzIGFuZCBlbnRlcnByaXNl cykuDQoNCg0KLSAgICAgICAgICBCZXJuaWUNCg0KRnJvbTogVGVtcGxpbiwgRnJlZCBMIFttYWls dG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbV0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTcs IDIwMTcgNTozNSBQTQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb208bWFp bHRvOnZvbHpAY2lzY28uY29tPj47IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86 bWVsbG9uQGZ1Z3VlLmNvbT4+OyDnpZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPG1haWx0 bzpqaW5tZWlAd2lkZS5hZC5qcD4+DQpDYzogZGhjd2cgPGRoY3dnQGlldGYub3JnPG1haWx0bzpk aGN3Z0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0DQoNCkJlcm5pZSwN Cg0KVGhlIGRpc2N1c3Npb24gZ3Jhdml0YXRlZCB0b3dhcmRzIG5vdCByZXN1cnJlY3RpbmcgdW50 aWwgdGhlIHNlZGhjcHY2DQpJLUQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVh dGUgdGhpcyBvbmNlIHNlZGhjcHY2IGlzIGRvbmUuDQoNClRoaXMgZG9lcyBub3QgbWFrZSBzZW5z ZSB0byBtZTsgc2VkaGNwdjYgaXMgdGhlIHZlcnkgcmVhc29uIHRoYXQgUkFBTiBpcyBpbXBvcnRh bnQuDQpKdXN0IGxpa2UgUkZDMzk3MSBkaWQgd2l0aCBJUHY2IE5EIFRpbWVzdGFtcCBhbmQgTm9u Y2Ugb3B0aW9ucywgc2VkaGNwdjYgY291bGQNCmRlZmluZSB0aGUgUkFBTiBvcGVyYXRpb24gYW5k IGhhdmUgZXZlcnl0aGluZyBvdmVyIGFuZCBkb25lIHdpdGggaW4gb25lIHBhc3MuDQpBbmQsIEkg aGF2ZSBhbHJlYWR5IGlkZW50aWZpZWQgYSB1c2UgY2FzZSB3aGVyZSBSQUFOIGlzIGFic29sdXRl bHkgbmVjZXNzYXJ5Lg0KQWxzbywgSSB3YXMgdW5hYmxlIHRvIGF0dGVuZCAgSUVURjk3LCB3aGVy ZSBJIGNlcnRhaW5seSB3b3VsZCBoYXZlIHN0b29kIHVwIGFuZA0Kdm9pY2VkIG15IHBvc2l0aW9u Lg0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlcm5pZSBWb2x6ICh2b2x6KQ0KU2VudDogVGh1cnNkYXks IEZlYnJ1YXJ5IDE2LCAyMDE3IDI6MzkgUE0NClRvOiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5j b208bWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20+Pjsg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5h ZC5qcDxtYWlsdG86amlubWVpQHdpZGUuYWQuanA+Pg0KQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9y ZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtkaGN3Z10gRndkOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dA0K DQpJIHByZXNlbnRlZCBhYm91dCByZXN1cnJlY3RpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LWFn ZW50b3B0LWRlbGVnYXRlIGF0IElFVEYtOTcgKHNlZSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LWRoYy1yZXN1cnJlY3QtZHJhZnQtaWV0Zi1kaGMt ZGhjcHY2LWFnZW50b3B0LWRlbGVnYXRlLTAwLnBkZikuDQoNCkFuZCB0aGUgY29uY2x1c2lvbiB0 aGVuIHdhcyAoc2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L21pbnV0ZXMv bWludXRlcy05Ny1kaGMtMDAudHh0KToNCg0KVGhlIGRpc2N1c3Npb24gZ3Jhdml0YXRlZCB0b3dh cmRzIG5vdCByZXN1cnJlY3RpbmcgdW50aWwgdGhlIHNlZGhjcHY2DQpJLUQgcHJvZ3Jlc3NlcyBm dXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVhdGUgdGhpcyBvbmNlIHNlZGhjcHY2IGlzIGRvbmUuDQoN Cg0KLSAgICAgICAgICBCZXJuaWUNCg0KRnJvbTogZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIExlbW9uDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1 YXJ5IDE1LCAyMDE3IDE6NDkgUE0NClRvOiDnpZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpw PG1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcD4+DQpDYzogZGhjd2cgPGRoY3dnQGlldGYub3JnPG1h aWx0bzpkaGN3Z0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0DQoNCk9u IEZlYiAxNSwgMjAxNywgYXQgMTozMiBQTSwg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5q cDxtYWlsdG86amlubWVpQHdpZGUuYWQuanA+PiB3cm90ZToNCkkgcGVyc29uYWxseSBkb24ndCB0 aGluayBpdCBhIGJsb2NraW5nIGlzc3VlIGZvciBzZWRoY3B2NiwgYnV0LCBvZg0KY291cnNlLCB0 aGUgd2cgc2hvdWxkIGRlY2lkZSBpdC4NCg0KSXQgZGVmaW5pdGVseSBpc24ndCBhIGJsb2NraW5n IGlzc3VlLCBidXQgRnJlZCBpcyByaWdodCB0aGF0IGlmIHdlIGFyZSBnb2luZyBhaGVhZCB3aXRo IGVuY3J5cHRpb24tb25seSwgd2hpY2ggSSBhZ3JlZSBpcyB0aGUgcmlnaHQgbW92ZSwgd2UgbmVl ZCB0byBkbyB0aGlzIHdvcmsgYXMgd2VsbC4NCg0K --_000_49129cb6c19c4be3bd483ceb3312bd72XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkg NyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0K CXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpNZW5sby1SZWd1bGFyO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6NTUxMTU5MjQwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczo5NzcyMDI3NjIgLTM5NjQzMjE2NCA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE1OTc3 ODMyNDA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x OTU3OTM2MDk2IDE2OTg3NDY4MzAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEJlcm5pZSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk15IHVuZGVyc3RhbmRpbmcgJm5ic3A7aXMgdGhhdCBz ZWRoY3B2NiBpcyBpbnRlbmRlZCB0byBiZSBhIHByb2R1Y3Qgb2YgdGhlIElFVEYsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPnNvIEkgdGhlcmVmb3JlIGFzc3VtZSB0aGF0IGl0IGlzIGludGVuZGVkIHRvIGJl IGEgcHJvZHVjdCBvZiBlbmdpbmVlcmluZy4gSXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aGFzIGJlZW4g c2hvd24gdGhhdCBzZWRoY3B2NiBoYXMgYW4gb21pc3Npb24gdGhhdCB3aWxsIGxpbWl0IGl0cyBh cHBsaWNhYmlsaXR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hbmQgdGhhdCB0aGF0IG9taXNzaW9uIGNh biBiZSByYXRoZXIgZWFzaWx5IHJlbWVkaWVkIHByaW9yIHRvIHB1YmxpY2F0aW9uLiBJdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj50aGVyZWZvcmUgbWFrZXMgZ29vZCBlbmdpbmVlcmluZyBzZW5zZSB0byBm aXggdGhlIG9taXNzaW9uIG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRoZSBwcm9wb3NhbCBhZ2FpbiBpcyB0byBoYXZlIHNlZGhjcHY2IHNwZWNpZnkgdGhl IFJBQU4gb3B0aW9uIGFzIHBhcnQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlIGJhc2UgZG9jdW1l bnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBG cmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gQmVybmllIFZvbHogKHZvbHopIFttYWlsdG86dm9sekBjaXNjby5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAxNywgMjAxNyAzOjAwIFBNPGJy Pg0KPGI+VG86PC9iPiBUZW1wbGluLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20mZ3Q7OyBUZWQgTGVtb24gJmx0O21lbGxvbkBmdWd1ZS5jb20mZ3Q7Ow0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90 OyI+56We5piO6YGU5ZOJPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ICZsdDtqaW5tZWlAd2lkZS5h ZC5qcCZndDs8YnI+DQo8Yj5DYzo8L2I+IGRoY3dnICZsdDtkaGN3Z0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JIHRoaW5rIHRoZSBwbGFuIGhlcmUgbWFrZXMgc29tZSBzZW5zZSDigKYgc2VESENQdjYgaGFz IGhhZCBzZXZlcmFsIGF0dGVtcHRzIGFuZCBiZWVuIGtpY2tlZCBiYWNrIHRvIHRoZSBXRy4gU28s IEkgdGhpbmsgdGhlIFdHIHdhbnRzIHRvIGdvIHNsb3dseSBhbmQgbm90IGRldmVsb3ANCiBhIHNv bHV0aW9uIHVudGlsIHNlREhDUHY2IGlzIGxpa2VseSB0byBhZHZhbmNlIGluIHRoZSBJRVNHIChl bmNyeXB0aW9uIHdhcyBvbmx5IGFkZGVkIGZhaXJseSDigJxyZWNlbnRseeKAnSkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmQsIGl0IGlzbuKAmXQgbGlrZSB0 aGUgZGF5IGFmdGVyIHNlREhDUHY2IGlzIOKAnGFwcHJvdmVk4oCdIHRoYXQgZXZlcnkgY2xpZW50 IChhbmQgc2VydmVyKSB3aWxsIHN1cHBvcnQgdGhpcy4gSXQgd2lsbCB0YWtlIHRpbWUgdG8gcm9s bCBvdXQuIEFuZCwgaG9wZWZ1bGx5IHdlIGNhbg0KIGdldCB0aGUgUkFBTiB3b3JrIG91dCBpbiBh IGZhaXJseSBzaG9ydCB0aW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SW4geW91ciBuZXR3b3JrcywgaWYgeW91IGNhbuKAmXQgc3VwcG9ydCBzZURIQ1B2NiB1 bnRpbCB5b3UgaGF2ZSBzb21ldGhpbmcgdG8gc28gc29sdmUgdGhlIFJBQU4gaXNzdWVzLCB5b3Ug b2J2aW91c2x5IGNhbuKAmXQgZGVwbG95IHNlREhDUHY2LiBCdXQgdGhlcmUgbWF5IGJlIHBsZW50 eQ0KIG9mIG90aGVyIG5ldHdvcmtzIHdoZXJlIHRoaXMgaXNu4oCZdCBhbiBpc3N1ZSBhbmQgaXQg Y291bGQgc3RhcnQgdG8gYmUgZGVwbG95ZWQgKGNvZmZlZSBzaG9wcyBhbmQgZW50ZXJwcmlzZXMp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXJuaWU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRlbXBsaW4sIEZyZWQgTCBbPGEgaHJl Zj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iPm1haWx0bzpGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDE3 LCAyMDE3IDU6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IEJlcm5pZSBWb2x6ICh2b2x6KSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnZvbHpAY2lzY28uY29tIj52b2x6QGNpc2NvLmNvbTwvYT4mZ3Q7OyBUZWQg TGVtb24gJmx0OzxhIGhyZWY9Im1haWx0bzptZWxsb25AZnVndWUuY29tIj5tZWxsb25AZnVndWUu Y29tPC9hPiZndDs7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gJmx0OzxhIGhyZWY9Im1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcCI+amlubWVpQHdp ZGUuYWQuanA8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gZGhjd2cgJmx0OzxhIGhyZWY9Im1haWx0 bzpkaGN3Z0BpZXRmLm9yZyI+ZGhjd2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5pZSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBkaXNjdXNzaW9uIGdyYXZpdGF0ZWQg dG93YXJkcyBub3QgcmVzdXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2NjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JLUQg cHJvZ3Jlc3NlcyBmdXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVhdGUgdGhpcyBvbmNlIHNlZGhjcHY2 IGlzIGRvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlz IGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8gbWU7IHNlZGhjcHY2IGlzIHRoZSB2ZXJ5IHJlYXNvbiB0 aGF0IFJBQU4gaXMgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KdXN0IGxpa2UgUkZDMzk3 MSBkaWQgd2l0aCBJUHY2IE5EIFRpbWVzdGFtcCBhbmQgTm9uY2Ugb3B0aW9ucywgc2VkaGNwdjYg Y291bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZGVmaW5lIHRoZSBSQUFOIG9wZXJhdGlvbiBhbmQgaGF2 ZSBldmVyeXRoaW5nIG92ZXIgYW5kIGRvbmUgd2l0aCBpbiBvbmUgcGFzcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+QW5kLCBJIGhhdmUgYWxyZWFkeSBpZGVudGlmaWVkIGEgdXNlIGNhc2Ugd2hlcmUgUkFB TiBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWxzbywgSSB3YXMg dW5hYmxlIHRvIGF0dGVuZCAmbmJzcDtJRVRGOTcsIHdoZXJlIEkgY2VydGFpbmx5IHdvdWxkIGhh dmUgc3Rvb2QgdXAgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnZvaWNlZCBteSBwb3NpdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBkaGN3ZyBbPGEgaHJlZj0ibWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVy bmllIFZvbHogKHZvbHopPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxNiwg MjAxNyAyOjM5IFBNPGJyPg0KPGI+VG86PC9iPiBUZWQgTGVtb24gJmx0OzxhIGhyZWY9Im1haWx0 bzptZWxsb25AZnVndWUuY29tIj5tZWxsb25AZnVndWUuY29tPC9hPiZndDs7IDwvc3Bhbj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx dW90OyI+56We5piO6YGU5ZOJPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ICZsdDs8YSBocmVmPSJt YWlsdG86amlubWVpQHdpZGUuYWQuanAiPmppbm1laUB3aWRlLmFkLmpwPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IGRoY3dnICZsdDs8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRoY3dn QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkaGN3Z10gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4 dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHByZXNlbnRlZCBhYm91dCByZXN1cnJlY3RpbmcgZHJh ZnQtaWV0Zi1kaGMtZGhjcHY2LWFnZW50b3B0LWRlbGVnYXRlIGF0IElFVEYtOTcgKHNlZQ0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05 Ny1kaGMtcmVzdXJyZWN0LWRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1hZ2VudG9wdC1kZWxlZ2F0ZS0w MC5wZGYiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRl cy05Ny1kaGMtcmVzdXJyZWN0LWRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1hZ2VudG9wdC1kZWxlZ2F0 ZS0wMC5wZGY8L2E+KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkFuZCB0aGUgY29uY2x1c2lvbiB0aGVuIHdhcyAoc2VlDQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9taW51dGVzL21pbnV0ZXMtOTctZGhjLTAwLnR4dCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvbWludXRlcy9taW51dGVzLTk3LWRoYy0w MC50eHQ8L2E+KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBkaXNjdXNz aW9uIGdyYXZpdGF0ZWQgdG93YXJkcyBub3QgcmVzdXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2 NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5JLUQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVhdGUgdGhp cyBvbmNlIHNlZGhjcHY2IGlzIGRvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkJlcm5pZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g ZGhjd2cgWzxhIGhyZWY9Im1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGhj d2ctYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBMZW1vbjxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDE3IDE6NDkgUE08YnI+ DQo8Yj5Ubzo8L2I+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuelnuaYjumBlOWTiTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1laUB3aWRlLmFkLmpwIj5qaW5tZWlAd2lk ZS5hZC5qcDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkaGN3ZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRoY3dnQGlldGYub3JnIj5kaGN3Z0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1p ZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBGZWIgMTUsIDIwMTcsIGF0IDE6MzIgUE0sIDxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPg0K56We5piO6YGU5ZOJPC9zcGFuPiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1laUB3aWRlLmFkLmpwIj5qaW5tZWlAd2lkZS5hZC5qcDwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok1lbmxv LVJlZ3VsYXIiPkkgcGVyc29uYWxseSBkb24ndCB0aGluayBpdCBhIGJsb2NraW5nIGlzc3VlIGZv ciBzZWRoY3B2NiwgYnV0LCBvZjxicj4NCmNvdXJzZSwgdGhlIHdnIHNob3VsZCBkZWNpZGUgaXQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkl0IGRlZmluaXRlbHkgaXNuJ3QgYSBibG9ja2luZyBpc3N1ZSwgYnV0IEZy ZWQgaXMgcmlnaHQgdGhhdCBpZiB3ZSBhcmUgZ29pbmcgYWhlYWQgd2l0aCBlbmNyeXB0aW9uLW9u bHksIHdoaWNoIEkgYWdyZWUgaXMgdGhlIHJpZ2h0IG1vdmUsIHdlIG5lZWQgdG8gZG8gdGhpcyB3 b3JrIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_49129cb6c19c4be3bd483ceb3312bd72XCH150608nwnosboeingcom_-- From nobody Sat Feb 18 09:17:18 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9499512954C for ; Sat, 18 Feb 2017 09:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 L1xbJn8GwgZA for ; Sat, 18 Feb 2017 09:17:14 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0B5129549 for ; Sat, 18 Feb 2017 09:17:13 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id o140so20105563lff.1 for ; Sat, 18 Feb 2017 09:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ECXKWLWB51Ll0heYSub514HNUZ7rk44ayCBU7A7IugE=; b=CGBP8DPWYvqhnGM78rRxLxd3G8fnnhH+zfB/hwKJc81omSKC2TT67bRlxA6ypE0sR0 p7wEmTJ58hCiC8Ws4HbyfMfslQLMlJAQ5eN0SdPcea6et9YNaO45BrWMhyjJmMLcnvGu 5QxzP/9O1wM9FEukD6TYOuDv58OiR/N1JONVIXfLGZvXRJ6/828fYiUdP6lp/NQp+5hl wc4pFbmEJOzGXnBbMwRlqgGWJV7ypamsGOH5pes9BnkOgVFrQQ9exVJMxF8bTOYJuYoq uBUDJ4IKZhlSRVIw7tDXTLn7my9XgDBAzQUIi3MmnGIVbchYnHPEmmUgMjYf7lMba6hw 8suw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ECXKWLWB51Ll0heYSub514HNUZ7rk44ayCBU7A7IugE=; b=VfZCB1DuWIi63NJLwsOvDqNFa7jrywZMQdvXIvLKK2TBUplg6WKl0hXETvbwGf4ZNk hvMdjFZZ+3dMbVfnflty+bW9xeSp41r74a0oSQClt2Pp9A0lEFb2IMqKj+wW/F0RqRQv 6CmLecvoOwOU+1EOe5UjYXhVArqWHTsRRXrZ/0RL6bis4p0dn+u+RMWtQBb/0pgPHNov rF1AjewSvnRtd7bxb7tsnHCDOzSjbOVZDaEfBbvgxgEig6HAslLoAIE81vwKznW9Avvk HrPH3vAIJiJhPX8/Pze6NybyUMMMjmerVFqiSc7nTjuypk0wqQrNmhLHGUyF5J7l5n9W M7HA== X-Gm-Message-State: AMke39lMDA6OH4NlH06bHX79sol8GwC9bQkujSog7J1Gqolrqc2/IS7/nyKNVHQ7rB09aaTdb6II70yUx3taKQ== X-Received: by 10.25.76.85 with SMTP id z82mr3195967lfa.181.1487438231711; Sat, 18 Feb 2017 09:17:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.20.153 with HTTP; Sat, 18 Feb 2017 09:17:10 -0800 (PST) Received: by 10.25.20.153 with HTTP; Sat, 18 Feb 2017 09:17:10 -0800 (PST) In-Reply-To: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> <21bd317edc764fc89dc4a13aa541b1c1@XCH15-06-08.nw.nos.boeing.com> <3e5776023c0d447aaccb81dc8ec8724a@XCH-ALN-003.cisco.com> <49129cb6c19c4be3bd483ceb3312bd72@XCH15-06-08.nw.nos.boeing.com> From: Ted Lemon Date: Sat, 18 Feb 2017 12:17:10 -0500 Message-ID: To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=001a114b19586d4d4d0548d13368 Archived-At: Cc: dhcwg , =?UTF-8?B?56We5piO6YGU5ZOJ?= , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 17:17:16 -0000 --001a114b19586d4d4d0548d13368 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fred, I think we all agree that this problem needs to be solved. We don't agree that work on the security draft must stop until the raan draft is done. It's just not that hard. On Feb 18, 2017 11:28 AM, "Templin, Fred L" wrote: Hi Bernie, My understanding is that sedhcpv6 is intended to be a product of the IETF, so I therefore assume that it is intended to be a product of engineering. I= t has been shown that sedhcpv6 has an omission that will limit its applicability, and that that omission can be rather easily remedied prior to publication. It therefore makes good engineering sense to fix the omission now. The proposal again is to have sedhcpv6 specify the RAAN option as part of the base document. Thanks - Fred *From:* Bernie Volz (volz) [mailto:volz@cisco.com] *Sent:* Friday, February 17, 2017 3:00 PM *To:* Templin, Fred L ; Ted Lemon < mellon@fugue.com>; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 *Cc:* dhcwg *Subject:* RE: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt I think the plan here makes some sense =E2=80=A6 seDHCPv6 has had several a= ttempts and been kicked back to the WG. So, I think the WG wants to go slowly and not develop a solution until seDHCPv6 is likely to advance in the IESG (encryption was only added fairly =E2=80=9Crecently=E2=80=9D). And, it isn=E2=80=99t like the day after seDHCPv6 is =E2=80=9Capproved=E2= =80=9D that every client (and server) will support this. It will take time to roll out. And, hopefully we can get the RAAN work out in a fairly short time. In your networks, if you can=E2=80=99t support seDHCPv6 until you have some= thing to so solve the RAAN issues, you obviously can=E2=80=99t deploy seDHCPv6. But = there may be plenty of other networks where this isn=E2=80=99t an issue and it co= uld start to be deployed (coffee shops and enterprises). - Bernie *From:* Templin, Fred L [mailto:Fred.L.Templin@boeing.com ] *Sent:* Friday, February 17, 2017 5:35 PM *To:* Bernie Volz (volz) ; Ted Lemon ; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 *Cc:* dhcwg *Subject:* RE: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Bernie, The discussion gravitated towards not resurrecting until the sedhcpv6 I-D progresses further. We will reevaluate this once sedhcpv6 is done. This does not make sense to me; sedhcpv6 is the very reason that RAAN is important. Just like RFC3971 did with IPv6 ND Timestamp and Nonce options, sedhcpv6 could define the RAAN operation and have everything over and done with in one pass. And, I have already identified a use case where RAAN is absolutely necessary. Also, I was unable to attend IETF97, where I certainly would have stood up and voiced my position. Thanks - Fred *From:* dhcwg [mailto:dhcwg-bounces@ietf.org ] *On Behalf Of *Bernie Volz (volz) *Sent:* Thursday, February 16, 2017 2:39 PM *To:* Ted Lemon ; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 *Cc:* dhcwg *Subject:* Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt I presented about resurrecting draft-ietf-dhc-dhcpv6-agentopt-delegate at IETF-97 (see https://www.ietf.org/proceedings/97/slides/slides- 97-dhc-resurrect-draft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf). And the conclusion then was (see https://www.ietf.org/ proceedings/97/minutes/minutes-97-dhc-00.txt): The discussion gravitated towards not resurrecting until the sedhcpv6 I-D progresses further. We will reevaluate this once sedhcpv6 is done. - Bernie *From:* dhcwg [mailto:dhcwg-bounces@ietf.org ] *On Behalf Of *Ted Lemon *Sent:* Wednesday, February 15, 2017 1:49 PM *To:* =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 *Cc:* dhcwg *Subject:* Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt On Feb 15, 2017, at 1:32 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: I personally don't think it a blocking issue for sedhcpv6, but, of course, the wg should decide it. It definitely isn't a blocking issue, but Fred is right that if we are going ahead with encryption-only, which I agree is the right move, we need to do this work as well. --001a114b19586d4d4d0548d13368 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fred, I think we all agree that this problem needs to be = solved. We don't agree that work on the security draft must stop until = the raan draft is done. It's just not that hard.=C2=A0

On Feb 18, 2017 11:28 AM, &= quot;Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:

Hi Bernie,

=C2=A0

My understanding =C2=A0is that sedhcp= v6 is intended to be a product of the IETF,

so I therefore assume that it is inte= nded to be a product of engineering. It

has been shown that sedhcpv6 has an o= mission that will limit its applicability,

and that that omission can be rather = easily remedied prior to publication. It

therefore makes good engineering sens= e to fix the omission now.

=C2=A0

The proposal again is to have sedhcpv= 6 specify the RAAN option as part of

the base document.

=C2=A0

Thanks - Fred

=C2=A0

From: Bernie Volz (volz) [mailto:volz@cisco.com]
Sent: Friday, February 17, 2017 3:00 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; Ted Lemon <mellon@fugue.com>; = =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>


Cc: dhcwg <dh= cwg@ietf.org>
Subject: RE: [dhcwg] Fwd: New Version Notification for draft-ietf-dh= c-sedhcpv6-20.txt

=C2=A0

I think the plan here makes some sens= e =E2=80=A6 seDHCPv6 has had several attempts and been kicked back to the W= G. So, I think the WG wants to go slowly and not develop a solution until seDHCPv6 is likely to advance in the IESG (encryption was= only added fairly =E2=80=9Crecently=E2=80=9D).

=C2=A0

And, it isn=E2=80=99t like the day af= ter seDHCPv6 is =E2=80=9Capproved=E2=80=9D that every client (and server) w= ill support this. It will take time to roll out. And, hopefully we can get the RAAN work out in a fairly short time.

=C2=A0

In your networks, if you can=E2=80=99= t support seDHCPv6 until you have something to so solve the RAAN issues, yo= u obviously can=E2=80=99t deploy seDHCPv6. But there may be plenty of other networks where this isn=E2=80=99t an issue and it could start to = be deployed (coffee shops and enterprises).

=C2=A0

-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bernie

=C2=A0

From: Templin, Fred L [mailto:Fred.L.Templin@boe= ing.com]
Sent: Friday, February 17, 2017 5:35 PM
To: Bernie Volz (volz) <volz@cisco.com>; Ted Lemon <mellon@fugue.com>; = =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>
Cc: dhcwg <dh= cwg@ietf.org>
Subject: RE: [dhcwg] Fwd: New Version Notification for draft-ietf-dh= c-sedhcpv6-20.txt

=C2=A0

Bernie,

=C2=A0

The discussion gravitated towards not resurrec= ting until the sedhcpv6

I-D progresses further. We will reevaluate thi= s once sedhcpv6 is done.

=C2=A0

This does not make sense to me; sedhc= pv6 is the very reason that RAAN is important.

Just like RFC3971 did with IPv6 ND Ti= mestamp and Nonce options, sedhcpv6 could

define the RAAN operation and have ev= erything over and done with in one pass.

And, I have already identified a use = case where RAAN is absolutely necessary.

Also, I was unable to attend =C2=A0IE= TF97, where I certainly would have stood up and

voiced my position.

=C2=A0

Thanks - Fred

=C2=A0

From: dhcwg [mailto:dhcwg-bounces@ietf.org= ] On Behalf Of Bernie Volz (volz)
Sent: Thursday, February 16, 2017 2:39 PM
To: Ted Lemon <mellon@fugue.com>; =E7=A5= =9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>
Cc: dhcwg <dh= cwg@ietf.org>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dh= c-sedhcpv6-20.txt

=C2=A0

I presented about resurrecting draft-= ietf-dhc-dhcpv6-agentopt-delegate at IETF-97 (see https://www.ietf.org/proceedings/97/slides/slides-97-dhc-resurrec= t-draft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf).<= /u>

=C2=A0

And the conclusion then was (see https://www.ietf.org/proceedings/97/minutes/= minutes-97-dhc-00.txt):

=C2=A0

The discussion gravitated towards not resurrec= ting until the sedhcpv6

I-D progresses further. We will reevaluate thi= s once sedhcpv6 is done.

=C2=A0

-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Bernie

=C2=A0

From: dhcwg [mailto:dhcwg-bounces@ietf.org= ] On Behalf Of Ted Lemon
Sent: Wednesday, February 15, 2017 1:49 PM
To: =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>
Cc: dhcwg <dh= cwg@ietf.org>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dh= c-sedhcpv6-20.txt

=C2=A0

On Feb 15, 2017, at 1:32 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp> wrote:<= /p>

I personally don't think it a blocking issue for sedhcpv6, but, = of
course, the wg should decide it.

=C2=A0

It definitely isn't a blocking issue, but Fred i= s right that if we are going ahead with encryption-only, which I agree is t= he right move, we need to do this work as well.

=C2=A0


--001a114b19586d4d4d0548d13368-- From nobody Mon Feb 20 20:06:15 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8B91299F9 for ; Mon, 20 Feb 2017 20:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 z6OgL_Ef8wAF for ; Mon, 20 Feb 2017 20:06:12 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A291299E0 for ; Mon, 20 Feb 2017 20:06:12 -0800 (PST) X-AuditID: c618062d-d73ff700000009d8-bd-58abcce9b169 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id 20.74.02520.9ECCBA85; Tue, 21 Feb 2017 06:15:24 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0319.002; Mon, 20 Feb 2017 23:06:08 -0500 From: Suresh Krishnan To: tianxiang li Thread-Topic: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Thread-Index: AQHSi/fUFVa5drHcE06Ut9OZIGKGgQ== Date: Tue, 21 Feb 2017 04:06:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_A7BFFAEF-A3A7-4DC9-8191-98497AF831C6"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyuXRPlO6bM6sjDFq/K1jc7WhhtNi3sJXR YvkMTQdmjym/N7J67Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZcxa8YS9Ya1Kxa/NNtgbG k4ZdjJwcEgImEi9XbWDvYuTiEBJYzyix9s5aNghnOaPE/9ZNzCBVbEBVG3Z+ZgKxRQQ0JLa2 Hgcq4uBgFrCQuPXcEiQsLBAjcfXPGXaIkliJljtrGCFsPYmuRV3sIOUsAqoSszf6goR5Bewl 3n3aBFYiJBAgsX5PI1grp0CgxM7HU8E2MQqISXw/tQbMZhYQl7j1ZD4TxM0iEg8vnmaDsEUl Xj7+xwphK0l8/D0f7BdmgSmMErPaXzBCLBOUODnzCcsERpFZSGbNQlY3C0kdRJG2xLKFr5ln gb2pIzF5ISNE2FTi9dGPULa1xIxfB9kgbEWJKd0P2Rcwcqxi5CgtLsjJTTcy2MQIjLNjEmy6 OxjvT/c8xCjAwajEw7vBZnWEEGtiWXFl7iFGFaDWRxtWX2CUYsnLz0tVEuHdvwMozZuSWFmV WpQfX1Sak1p8iFGag0VJnDdu9f1wIYH0xJLU7NTUgtQimCwTB6dUA2MLi3Vj98yYvquvr037 13fhdPT2qNBYR+7DNS19vtk7ZD+5/17E+VokdhNzWk7H5f6e9Wv9Rbs/bf897zbTYuulugsW TT+44uPiaU9dVGsz3oXOV2mSDau7Ku7g9+f1ul8f5hZvte37Etz4epnZnppa7sNinYurtfcv uqNQO/Fw9s0Wo7aDPG+VWIozEg21mIuKEwEGBtWzuwIAAA== Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 04:06:14 -0000 --Apple-Mail=_A7BFFAEF-A3A7-4DC9-8191-98497AF831C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 17, 2017, at 12:32 AM, tianxiang li = wrote: >=20 > Hi all, >=20 > The IESG review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue has = ended, several reviewers suggested this document should update RFC 3633, = as someone reading RFC3633 would need a pointer to this document. Hope = to receive the comments from the WG regarding this issue.=20 I personally have no objections to adding the Updates: RFC3633 tag to = the document. It would be great if other WG participants can chime in = one way or another. >=20 > And if so, do we need to add a specific tag in the xml file stating = that it updates RFC 3633 and change the title of the document? If the WG has no objection to doing this, I can add this (Updates tag) = as an RFC Editor note. No need for a new rev. Thanks Suresh --Apple-Mail=_A7BFFAEF-A3A7-4DC9-8191-98497AF831C6 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjIxMDQwNjA4WjAjBgkqhkiG9w0B CQQxFgQU5iY/NTA6SL1xR0nhpV2lfRvrXHMwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQCv61uHtHCY4A6MdHDNMNeEkrss9CVK0VBt+gjvLH72LKSiUI8rEO/zNX5hpO2H JhDuH+PJxUwAcOiMO52DvP0CSrGLMFu5kUIj5Lv60CuoKWumrtccARgT6dVtlqaAoXk3bJQFh0Jg 9Z8KNBQZ5SPnR/yCp7Ie75CuK3ndY9/X7osXz/H2/RF/VHpV3sZVKZFS7qSoE3AMGN8FKcFtc0M4 Iw+3b3nXghc5N+RpRPhi5sSd+XssJcE2rjsN9FHWTrT7+jgZMYAjWfU4NV3JqMvzlgoCwY9kLeeV 8emYr6QGI5xpFiQTXQTcBe2ZnS0sXtbyJ9hV8TVOpgUwSnPvy5I8AAAAAAAA --Apple-Mail=_A7BFFAEF-A3A7-4DC9-8191-98497AF831C6-- From nobody Mon Feb 20 21:57:42 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2CD129AE7 for ; Mon, 20 Feb 2017 21:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 mNTaMQ57_W2l for ; Mon, 20 Feb 2017 21:57:39 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63464129AE4 for ; Mon, 20 Feb 2017 21:57:39 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id l19so59495867ywc.2 for ; Mon, 20 Feb 2017 21:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YHKz7FwC7K+E2twPpKlShOEvsrZJ09wSz7jUKvkwIfI=; b=oSH+4rt/tfCJBd6wxISrdyyhI8t9Dker9/RIcDxqFV8/sRH3nc7uxzZYw9MH1dOt/U w6tn0MoeJ+rhySqTcMgFW+WrkC9Zdtb3t8r4iBXpJ0dsmZsUaUzCiNLmy7cy78ztMe5z 4qrwIg2Jh4PoSBcNAufBIf9F0Cl4+aAKSFPeLeaUbD5jmNn2DYx6mG4whJEdgSSz/PnT VVx3ZGdh4rcQQy4H0ZlxAsR/2cMMLcgXvZl0O22LfGy/F/7w8/O240GqCeQ+Q39myyp+ Qb44VXLYOS3LEOXVNdJ4GirK+DzSOk9gWFfdAj/C6P3kwq24zE258A9Hf0czzNAPLXlO fPew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YHKz7FwC7K+E2twPpKlShOEvsrZJ09wSz7jUKvkwIfI=; b=HrIo0ZhusITGNb2mcyt0tryBQss4lWwncxI29rHnFsqelBvnM1eNtCEafXr3uoARNT OSq7g95cpXJLSMQzqq5lSLTnNuDSi0apxAhO2vmR7L3UOsV9dY8829HvkKX32e0PTCBv KbRaYIlsBDB4lWK2A6HA/6QiNUGYsxVRpRzKaW8QuH2QYhrlOoQcgIJyaCtYSbsfuuxE IFBOvyuinGjayw1w6Gg1SGUvMS1e9CXo2hrHCPKr1JvQn3v+09K/blFkrlsXPP+eVRcH Jz+QjOtRuYLOzzsw+h2d5Vud0OePtJ+hb1RwtWbtbb+nX3bEt+vaRLMf+/E9ZD0JAo2P oOSw== X-Gm-Message-State: AMke39mhBVs3xTIWkzhUbEnCF65B7UBYrxkmBJ3YMhzMe5m+fn+wKvI9r/BPCFsbfR26exY5yp76ZGlcVTX0TNpu X-Received: by 10.129.41.69 with SMTP id p66mr15583139ywp.223.1487656658154; Mon, 20 Feb 2017 21:57:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.4 with HTTP; Mon, 20 Feb 2017 21:57:17 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Tue, 21 Feb 2017 14:57:17 +0900 Message-ID: To: Suresh Krishnan Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114160bab1b7ca0549040e6e" Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 05:57:41 -0000 --001a114160bab1b7ca0549040e6e Content-Type: multipart/alternative; boundary=001a114160baa8986c0549040e65 --001a114160baa8986c0549040e65 Content-Type: text/plain; charset=UTF-8 What about folding in to 3315bis (where other 3633 info is going)? I have no strong preference one way or the other, just asking. On 21 February 2017 at 13:06, Suresh Krishnan wrote: > > > On Feb 17, 2017, at 12:32 AM, tianxiang li > wrote: > > > > Hi all, > > > > The IESG review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue has > ended, several reviewers suggested this document should update RFC 3633, as > someone reading RFC3633 would need a pointer to this document. Hope to > receive the comments from the WG regarding this issue. > > I personally have no objections to adding the Updates: RFC3633 tag to the > document. It would be great if other WG participants can chime in one way > or another. > > > > > And if so, do we need to add a specific tag in the xml file stating that > it updates RFC 3633 and change the title of the document? > > If the WG has no objection to doing this, I can add this (Updates tag) as > an RFC Editor note. No need for a new rev. > > Thanks > Suresh > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --001a114160baa8986c0549040e65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What about folding in to 3315bis (where other 3633 info is= going)?=C2=A0 I have no strong preference one way or the other, just askin= g.

On 21 Feb= ruary 2017 at 13:06, Suresh Krishnan <suresh.krishnan@ericsson.= com> wrote:

> On Feb 17, 2017, at 12:32 AM, tianxiang li <peter416733@gmail.com> wrote:
>
> Hi all,
>
> The IESG review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue= has ended, several reviewers suggested this document should update RFC 363= 3, as someone reading RFC3633 would need a pointer to this document. Hope t= o receive the comments from the WG regarding this issue.

I personally have no objections to adding the Updates: RFC3633 tag t= o the document. It would be great if other WG participants can chime in one= way or another.

>
> And if so, do we need to add a specific tag in the xml file stating th= at it updates RFC 3633 and change the title of the document?

If the WG has no objection to doing this, I can add this (Updates ta= g) as an RFC Editor note. No need for a new rev.

Thanks
Suresh


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


--001a114160baa8986c0549040e65-- --001a114160bab1b7ca0549040e6e Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg1tEMWhlA3DcaZ2Xx90Sq84Ec9Kv/4xez WIrmU+mXCSkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjIx MDU1NzM4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBACFW/3kEzwdVzCvXpMCOhPAk7OuhpBEVSJBRg5GRRZrdO/ZGJZZl 52nxF2NeGvIF8uu0eaY1KTp5wL2J0VARbIYjYtu7EIIgraZKPRRPQCoTR7lMbxmTusLVvflWI1wh 4JwlHPY6V7dS049Sexps5cQCo0QWQLNet/fYIPkG7Q7sctvc5Zy/YNqN0isr4gUyTRctexE+cv6g APwKGpNlcdsJF0QOjVz2WTzDtglhIZVsAjfV+inNVaeMzHEI8z6xXXU41WucGxLxb2ktqacNiOUA Gq3VZ5XupWy2C5x3fGSq9nPJ6ioV3T6RXRjKPr9Eo43Mdexwwm+Mmg0wgxc4Ous= --001a114160bab1b7ca0549040e6e-- From nobody Tue Feb 21 07:55:24 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BFE1293FB; Tue, 21 Feb 2017 07:55:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148769252274.19094.13307554434720814789.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2017 07:55:22 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-21.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 15:55:22 -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 of the IETF. Title : Secure DHCPv6 Authors : Lishan Li Sheng Jiang Yong Cui Tatuya Jinmei Ted Lemon Dacheng Zhang Filename : draft-ietf-dhc-sedhcpv6-21.txt Pages : 31 Date : 2017-02-21 Abstract: DHCPv6 includes no deployable security mechanism that can protect end-to-end communication between DHCP clients and servers. This document describes a mechanism for using public key cryptography to provide such security. The mechanism provides encryption in all cases, and can be used for authentication based on pre-sharing of authorized certificates. 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: https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-sedhcpv6-21 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 Feb 21 14:55:43 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227EA120724 for ; Tue, 21 Feb 2017 14:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3uAtrT2HGnZt for ; Tue, 21 Feb 2017 14:55:41 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A631204D9 for ; Tue, 21 Feb 2017 14:55:40 -0800 (PST) X-AuditID: c6180641-c3fff70000000a06-30-58ac7f15e4bc Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by (Symantec Mail Security) with SMTP id 28.AD.02566.51F7CA85; Tue, 21 Feb 2017 18:55:36 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 17:55:36 -0500 From: Suresh Krishnan To: Erik Kline Thread-Topic: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Thread-Index: AQHSjAdpZrZhqiHmrU2X2q8zezC2gKF0ZvoA Date: Tue, 21 Feb 2017 22:55:35 +0000 Message-ID: <7D7BC30A-FABA-43D1-BF60-4687476CE652@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/signed; boundary="Apple-Mail=_3FA521F1-3171-425E-A5FF-A277635C3185"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyuXRPuK5E/ZoIg+kv+CzudrQwWny+PY/d Yt/CVkaL5TM0HVg8pvzeyOqxc9Zddo8Fm0o9liz5yRTAEsVlk5Kak1mWWqRvl8CVceLIVcaC C4YVy89NYmpg3K7fxcjJISFgIrF/6mtWEFtIYD2jxN4vgl2MXED2ckaJZTOOMoIk2ICKNuz8 zARiiwjISZy/dZcNxGYWSJA4+v0DM4gtLBAjcfXPGXaImliJljtrGCFsI4mT/xaB1bMIqEo0 tEwCi/MK2Es0Lr/NArHsLKPE2wdfwRZwCgRK/PjdC3YRo4CYxPdTa5gglolL3HoynwniahGJ hxdPs0HYohIvH/9jhbCVJOa8vsYMMpRZYAqjRPuE66wQ2wQlTs58wjKBUWQWklmzkNXNQlIH UaQtsWzha+ZZjBxAto7E5IWMEGFTiddHP0LZ1hIzfh1kg7AVJaZ0P2RfwMixipGjtLggJzfd yHATIzD6jkmwOe5g3NvreYhRgINRiYd3g+yaCCHWxLLiytxDjCpArY82rL7AKMWSl5+XqiTC O2knUJo3JbGyKrUoP76oNCe1+BCjNAeLkjjv9ZD74UIC6YklqdmpqQWpRTBZJg5OqQZG6cxb pQHFXA8iFzT/2Ku14GB97nap3dnmV6/+OpR//ZaHxuuwdUKrzogen+BcK+DmJPr4y8as5auS Wrv/yaowT3waX2fYXuPluivGY2Pb7f7T6/5P733eJBqnKF9+MVzjRMJL00/BW5W2GbboNk00 5m2by2p8rmxTiduae6KL+T6v6ZPKXHtLiaU4I9FQi7moOBEAECBkbcYCAAA= Archived-At: Cc: dhcwg , Bernie Volz Subject: Re: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 22:55:42 -0000 --Apple-Mail=_3FA521F1-3171-425E-A5FF-A277635C3185 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Erik, > On Feb 21, 2017, at 12:57 AM, Erik Kline wrote: >=20 > What about folding in to 3315bis (where other 3633 info is going)? I = have no strong preference one way or the other, just asking. That is certainly something worth considering, but I think = it should be independent of this document. There are people who = implement RFC3633 and it would be good if they can use this = independently without needing to wait for 3315bis. Thanks Suresh --Apple-Mail=_3FA521F1-3171-425E-A5FF-A277635C3185 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjIxMjI1NTM1WjAjBgkqhkiG9w0B CQQxFgQU3kh4+3BKkWwsxdakgiSdyYqB5eAwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQBFHuxjnK+sPZMzAfoZ4pYiAL/1gdrc54bqBgYcvWND5BEZF6J/06fiUCxG7CTe YKS0GFbpQPAqr/UsFWmNpVdXcn3qrJxIPLdX4O0zD4tmoX4C1P8kvGsIS5shOQvwaRlo4UIBvP4L O5eWQ5l7qE7xLNAfYX0NQB9JLEItgKZwMqIECflnqHoXbGY5kL6lt9QDhO71SARfTZAIVil/OBNm iHsVmGBa9jnY6dqrxxNm5RzY+KSW0NhXiaRtPfynlydpd2mphRfG+qKUtRw1r98Cx0po6rQqCRHi ePe3Q7kPNGHvcvEEcNIPk1g3poGf1cY6f1iZiiy+P8yi36HPDaP4AAAAAAAA --Apple-Mail=_3FA521F1-3171-425E-A5FF-A277635C3185-- From nobody Tue Feb 21 17:18:52 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40A61294BE for ; Tue, 21 Feb 2017 17:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 jEiimiIEhqgV for ; Tue, 21 Feb 2017 17:18:50 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700C41294BF for ; Tue, 21 Feb 2017 17:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1086; q=dns/txt; s=iport; t=1487726330; x=1488935930; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JsEmbxgrTubvPNvz9myQze8sIFB5xyunwGi4t7jXl6I=; b=WuFmr9QuygrDNCI1mxoCPtTYl0a8ZD+toAscG3fnomfNYDdIYSV4r/Ka R7S/cHwr5aBNhIGeiJtEC1zOQTg/T1jt3klcwlMKa6IkhFS36PyCXYnuD uq+MYln2EoePBD0NM/RGRsMFbR8fBWMmqxG6UEghRc5MyTwOUKk0w268F o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQBk5qxY/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBageNXJIWiAyNKIINhiICgnE/GAECAQEBAQEBAWIohHABAQE?= =?us-ascii?q?DATo/BQcEAgEIEQQBAQEeCQchERQJCAIEAQ0FCIlOAw0IsW6HPA2DdwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2LO4E8gRWBVDaFXgWbUToBjgOEEpEYikGIYgEfOEk?= =?us-ascii?q?3UxWFPoFIdYktgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,191,1484006400"; d="scan'208";a="388587516" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2017 01:18:49 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1M1InmC031382 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Feb 2017 01:18:49 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Feb 2017 19:18:49 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 21 Feb 2017 19:18:48 -0600 From: "Bernie Volz (volz)" To: Suresh Krishnan , Erik Kline Thread-Topic: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Thread-Index: AQHSjAdpZrZhqiHmrU2X2q8zezC2gKF0ZvoA///T33A= Date: Wed, 22 Feb 2017 01:18:48 +0000 Message-ID: <9a5b8e737dfc416dba5bbeda53854cb2@XCH-ALN-003.cisco.com> References: <7D7BC30A-FABA-43D1-BF60-4687476CE652@ericsson.com> In-Reply-To: <7D7BC30A-FABA-43D1-BF60-4687476CE652@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.255.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 01:18:51 -0000 And, at some point we have to draw the line as to what can be added to 3315= bis or it will never finish. I think having this as a standalone document is fine. Note that 3315bis doe= s reference it. - Bernie -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=20 Sent: Tuesday, February 21, 2017 5:56 PM To: Erik Kline Cc: tianxiang li ; dhcwg ; Bernie Vo= lz (volz) Subject: Re: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-le= ngth-hint-issue Hi Erik, > On Feb 21, 2017, at 12:57 AM, Erik Kline wrote: >=20 > What about folding in to 3315bis (where other 3633 info is going)? I hav= e no strong preference one way or the other, just asking. That is certainly something worth considering, but I think it s= hould be independent of this document. There are people who implement RFC36= 33 and it would be good if they can use this independently without needing = to wait for 3315bis. Thanks Suresh From nobody Wed Feb 22 09:28:05 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6526A12999E for ; Wed, 22 Feb 2017 09:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ZXAbD61_2d83 for ; Wed, 22 Feb 2017 09:28:01 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC3D12997E for ; Wed, 22 Feb 2017 09:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2403; q=dns/txt; s=iport; t=1487784481; x=1488994081; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yUJ0khoPi5dF+l6qBvMw2ENcrr2rBzXrdQ/rQXoACqU=; b=bwBwupRCKQN3hJNx3KQSQgIXLmeK6UHXlhOTkE/gz8gCmdakZSAFrBHP 44zJ5k+mrFDGei1khYB9BO3UXLzIJtUvnnbIT8S0UrumypsvLVbFJQIjA d4fcHwxgxr+05fy0ekw8DuDfud05FcvGQrWIquVteTGuxqVxuk0lxTvD2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBUya1Y/4QNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVyRWogMjSiCDR8LhXgCgwU/GAECAQEBAQEBAWIohHA?= =?us-ascii?q?BAQEDAQEBODQLBQcEAgEIEQQBAQEeCQchBgsUCQgCBAENBQiJVQMNCA6xK4dBD?= =?us-ascii?q?YN3AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWLO4E8gRWBVDaFXgWbVjoBjgOEFoI?= =?us-ascii?q?EjxWINYIMiGMBHzhJN1QVPoUBgUh1iQeBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,195,1484006400"; d="scan'208";a="201340996" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Feb 2017 17:28:00 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v1MHS0Hc023622 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Feb 2017 17:28:00 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Feb 2017 11:27:59 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Wed, 22 Feb 2017 11:27:59 -0600 From: "Bernie Volz (volz)" To: Suresh Krishnan , Erik Kline Thread-Topic: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Thread-Index: AQHSjAdpZrZhqiHmrU2X2q8zezC2gKF0ZvoA///T33CAAQpxEA== Date: Wed, 22 Feb 2017 17:27:59 +0000 Message-ID: References: <7D7BC30A-FABA-43D1-BF60-4687476CE652@ericsson.com> <9a5b8e737dfc416dba5bbeda53854cb2@XCH-ALN-003.cisco.com> In-Reply-To: <9a5b8e737dfc416dba5bbeda53854cb2@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 17:28:03 -0000 Hi: Also, my personal opinion (wg chair hat off) is that we DON'T tag this docu= ment to update 3633. There is no specific text in this draft that replaces = text in 3633. The section 3.6 is a "General Recommendation" and it could be= argued that 3633 always intended clients to include the hint in each reque= st. And, also if 3315bis obsoletes 3633, it might REQUIRE us to address this in= 3315bis? Rather than just reference it - and while we could add the "Gener= al Recommendation", one would then lose a lot of the background as to why t= his is important (and the rest of the prefix-hint draft isn't well suited t= o be incorporated in 3315bis). Hence, my personal opinion is that we: 1. Don't specify that this document updates 3633. 2. Have 3315bis reference it (which we already do). - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Tuesday, February 21, 2017 8:19 PM To: Suresh Krishnan ; Erik Kline Cc: dhcwg Subject: Re: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-le= ngth-hint-issue And, at some point we have to draw the line as to what can be added to 3315= bis or it will never finish. I think having this as a standalone document is fine. Note that 3315bis doe= s reference it. - Bernie -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=20 Sent: Tuesday, February 21, 2017 5:56 PM To: Erik Kline Cc: tianxiang li ; dhcwg ; Bernie Vo= lz (volz) Subject: Re: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-le= ngth-hint-issue Hi Erik, > On Feb 21, 2017, at 12:57 AM, Erik Kline wrote: >=20 > What about folding in to 3315bis (where other 3633 info is going)? I hav= e no strong preference one way or the other, just asking. That is certainly something worth considering, but I think it s= hould be independent of this document. There are people who implement RFC36= 33 and it would be good if they can use this independently without needing = to wait for 3315bis. Thanks Suresh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Feb 22 09:37:38 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D96129695; Wed, 22 Feb 2017 09:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7MAFlX8iDOWA; Wed, 22 Feb 2017 09:37:36 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC831296B6; Wed, 22 Feb 2017 09:37:36 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id z127so5071382lfa.2; Wed, 22 Feb 2017 09:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Wu3c+b9xnwAvqUzAU36Q03SBOAwYTNXBKXNq9KTlE6s=; b=VeeGzdhcuCdw5XbP7EnNw6H2Ybk+Oq/ft9V0BdYfxxdprmq3e3W8VopVtgrgWZtMyl oTFXNW1kmvx6M4T8D4nAcSzBEZtSI57yXxRrbG9iUWO9QNQoxE/TvUfVYE4kb6S0A6Sz P6FpAIYyl8IJznACCrWgS6vKh+iKSX84xWNRHOM1kLz1PH7vHULw1cvwDAvjbGtbrUAj D2YBVLApGMKisiTWHVpcZDDP+2QINY916HkZQ/NrB2zbx9L9dKoQ6FIObvNu1TSBMj9w pEIV/08/5el461LqpU7aHG3VnAFkIwCjtc5S+dajjz5Y4MRanhXgymdAUJE43+zUr2Q/ zBiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Wu3c+b9xnwAvqUzAU36Q03SBOAwYTNXBKXNq9KTlE6s=; b=ktYyUvPjPWFzgRXDpAJy3cqLCT5aVwT9ihpNMyCzoyr4smlMcpQpLlW720HAem9SS1 gL11ONsOQ3DMrYbng903F3jbCP8d9JRJjN2yIswAqr3XRMCmah2dHp2bbCF/b3Ul0m0e KbAWZfoSlwZSY/wys84n8NDyR9Im3/p2OfuuMzHvX2ExWozKSPLJYZNilJTptlhR+bV4 JfXDryiukUGkkxgi0+2NMJhO8XzMaT1/tZPYg2ZZO2tvAKQ8KjeALHrw7N62ssQeU348 edpYZJgw7+cFPcnd99qvQ8wVDTq9fNBIvHGSmMcrzrTAbikHvhGFBnDzMzFFcxAX353F q/jg== X-Gm-Message-State: AMke39kYfjkZ9Rr5w1sXl0IOdjh+RusXuL0k0yuuhtLQmQqTIroBITNPoHEF4Uj3584Gog== X-Received: by 10.25.21.214 with SMTP id 83mr1705100lfv.66.1487785054114; Wed, 22 Feb 2017 09:37:34 -0800 (PST) Received: from [192.168.0.6] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id f8sm620883lji.2.2017.02.22.09.37.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 09:37:33 -0800 (PST) From: Tomek Mrugalski To: dhcwg Message-ID: Date: Wed, 22 Feb 2017 18:37:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Softwires-wg , draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org Subject: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 17:37:37 -0000 Hi, This message initiates a two weeks long DHC WG adoption call on: Title: DHCPv4 over DHCPv6 Source Address Option Pages: 9 Date: 2017-02-01 Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 This document initially started as work intended to be adopted in Softwires, but after a discussion with chairs, responsible AD (Suresh) and presenting this work in DHC, the conclusion is to aim for DHC adoption, not Softwires. Therefore this is a DHC adoption call. This message is cross-posted to Softwires to let Softwire experts weigh in their opinion. Please be sure to post your comments to DHC list, though. Comments sent by end of March 8th, 2017 are much appreciated. Bernie & Tomek From nobody Wed Feb 22 09:45:16 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7568612968B for ; Wed, 22 Feb 2017 09:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 l3BIsXAiDch5 for ; Wed, 22 Feb 2017 09:45:14 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1233129503 for ; Wed, 22 Feb 2017 09:45:13 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id l12so5191509lfe.0 for ; Wed, 22 Feb 2017 09:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=HOz21pfuAIeoeDs5HYz4w/gRaU/dyD7CktjD/8lrVPE=; b=p0enfBhQZs3OGdk3CRxn/gEcToGphwa64ftQ/noAQhkP+x1c68WxE+MnG39Lv9fLmj tFPUCvsPeRSTTK/Gf89MTAUCW7t0Vtdbx2l8lAEwq+WiI282PzzyjM1frfkSMjl3Q8bk chqov/YkdVws1CdZqVgIF7EGiY79OKLXGN/CO3zDL4W84p5ILt+ROhbTSjOVEEyTc/0a UT80J2wJnOiva6Ko3tAtlqTFG4OhYPO1Yjsbr+TivcoxozyYkyFwnmvfClKmQq4gGph2 f0YKhqtIbZZ+gJGR8hWDSTLpaBv55+bqLgMMwBrOq27yo7pxh+iRQ6fAeriun//QRNdw z/PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HOz21pfuAIeoeDs5HYz4w/gRaU/dyD7CktjD/8lrVPE=; b=fewEH8ahvfFVxdpIbzvjqGnfOvdPDjt0G2EdFDw6K4gKYOlGPv05SqR3De5YifwRsj 7azZ5iZl7dz/rNVpGMCG98N1CDP0q1kyp+LMyCfNV16N0nGD8NTlui8AEf6se+YsWpz2 Vd9W6cnAlTW2fYJMFAvNxDOaNgveNrVRkTg6uFrPDi0ap56h4+XmlMAKdy/zm7JekU+6 W9fezGCzOs5p7z+quPG2I4GmuuTbCTOW8xuoObIHDadveLiZdzj8xKycsxQ3sZchgZlk RGxaIeOyeBYdzQPZQ8DhFpgtOV8wvObMvyZQVElkwj8bU7yQsoBVcXiiCRHD9+WB48Mw +WTg== X-Gm-Message-State: AMke39kpYEdpm3MdB4i5LGE2RSnazkRlgP4CQEaXrWNzv6Mu3jkTRrjguHduVVrw53lY1A== X-Received: by 10.46.83.66 with SMTP id t2mr9311915ljd.82.1487785511905; Wed, 22 Feb 2017 09:45:11 -0800 (PST) Received: from [192.168.0.6] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id s7sm7308423lja.27.2017.02.22.09.45.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 09:45:11 -0800 (PST) To: dhcwg@ietf.org References: From: Tomek Mrugalski Message-ID: Date: Wed, 22 Feb 2017 18:45:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 17:45:15 -0000 W dniu 21.02.2017 o 05:06, Suresh Krishnan pisze: >> On Feb 17, 2017, at 12:32 AM, tianxiang li wro= te: >> >> Hi all, >> >> The IESG review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue has = ended, several reviewers suggested this document should update RFC 3633, = as someone reading RFC3633 would need a pointer to this document. Hope to= receive the comments from the WG regarding this issue.=20 >> >> I personally have no objections to adding the Updates: RFC3633 tag to = the document. It would be great if other WG participants can chime in one= way or another. With my co-chair hat off, I don't have any specific preference here. On one hand, if we update 3633, we will be enforcing everyone to follow the recommendation made in prefix-length-hint-issue. The obvious benefit is that prefix-length-hint-issue will get more exposure, which is a good thing. On the other hand, the 3315bis work hopefully will be published later this year and it will obsolete 3633. Assuming the bis work gets published relatively soon, the window of opportunity when the 3633 update will be applicable is several months. As Bernie pointed out, 3315bis references prefix-length-hint-issue. If it was completely up to me, I would go with update 3633, because that would give this draft immediate exposure to more readers. Also, if 3315bis publication is delayed for whatever reason, updating seems like a better choice. But I wouldn't complain if we decide to go the "don't update" route. Tomek From nobody Fri Feb 24 06:41:25 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA9B129856; Fri, 24 Feb 2017 06:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.487 X-Spam-Level: X-Spam-Status: No, score=-4.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NRHJb6Ybqjj4; Fri, 24 Feb 2017 06:41:22 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BFE129850; Fri, 24 Feb 2017 06:41:22 -0800 (PST) Received: from ians-mbp.lan ([62.225.30.138]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MYg42-1cmClh03Yg-00VQDt; Fri, 24 Feb 2017 15:41:19 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ian Farrer In-Reply-To: Date: Fri, 24 Feb 2017 15:41:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <305F0B31-467B-4138-882D-8617764499A8@gmx.com> References: To: Tomek Mrugalski X-Mailer: Apple Mail (2.3124) X-Provags-ID: V03:K0:yEiD+qlHtHnl0z/jpCq/U2IcZd5CprW3EUTILOL+vt+0SZPDt5I uE/8gFRg6Ge+9LXo8Dn+c3e3KRqyP01/e9CO7+qPoRjJ8rNMlZIJdP2CMZ4PiN02IZRLogA QS4CpXHXIXhGQ0XiQJv4beq3370LnTpOp5Z+Nv3ITLTDv7x5b8HwvQcR4zRyPmyfuJMiWpf zz/JwKHiGGSNg8G4kGihg== X-UI-Out-Filterresults: notjunk:1;V01:K0:EygqqekIksI=:AT67hW1CX+j1tTxc1gy9oE UAAUBm/rZEEzx5KnRBWFYesB5f3ZwtB5fqTWaIX3/kcNPnc4JJwUcvBgshzMFugsPWUcLlR/2 fGx3lxXjSZokmJ6v2ZW9FgzIkGCtM8IRp8Lfnl4LM3cASPrdbNJfoTk3wc1iGuOYXtjOrkT0j m5ycSdY8LIyXUOiIECUCG0H3w0rzEwiBv2dseJt0DZJX2Mb3WJ0rKGdhbY7CtyqE4F0cZ26gt H65Qx3qO+xp79ZPqz6EK0l6dQC5fFHL8yK5tZ8WAPVZbF75ccct2NBJ5otCj4ZzynXakN6/w/ dZ8JYkO6b45e6wQJvCtdNiNWOIam6MavJZQCmvI8dZZDFjyMmOSjOyRVLRBcYQi6i1xLlvakm tiQSSgNCugduOlserq0AnfuCsiRAuWv823H4fK5xOeuhhX8yEefI/Y57D+vo4qyLLgL5uC5Pt 0uJIOJl+ah3cXoiPFDITxVlGGMfSHxitgta2leklea8he+kd+9q9A4ZCUYLQt82bjroyU0s5X EJ8OiXNeOFjGSYQILMukInf2GTgDqRiwzygWMtkM+DPjlHbg2zzkOHphE+D/XCJFHAd0mvUme nhBblvExDwzKWUMhmbUZ+LpN0l525fnQGRYgcQ8PdAvwxXGnWI7x+/LjsgYYLqpN52koTRSHC vFVnd4f1e6CWrKwizOwgOlP2VbJVNEvZvHw0VNnvRk63LcP/1MC3JGa6J+nE94j59IXpQTwbT c6nZvpSKWDXWGafNDtOnOeAOmSWDRIHA/iHuh8+YhEmhQlAexiy8bHeCMg2PFvpHp4yXidrp+ hHoVAMO Archived-At: Cc: Softwires-wg , dhcwg , draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org Subject: Re: [dhcwg] [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 14:41:24 -0000 Hi As a co-author, I support its adoption. We (DT) are currently testing an = implementation of DHCPv4oDHCPv6 which includes the Source Address option = with a plan to deploy. As this draft is predominantly concerned with = changes to DHCPv4o6 client and server implementations, it seems logical = to progress this in DHC. Thanks, Ian > On 22 Feb 2017, at 18:37, Tomek Mrugalski = wrote: >=20 > Hi, >=20 > This message initiates a two weeks long DHC WG adoption call on: >=20 > Title: DHCPv4 over DHCPv6 Source Address Option > Pages: 9 > Date: 2017-02-01 > Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 > Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 >=20 > This document initially started as work intended to be adopted in > Softwires, but after a discussion with chairs, responsible AD (Suresh) > and presenting this work in DHC, the conclusion is to aim for DHC > adoption, not Softwires. Therefore this is a DHC adoption call. >=20 > This message is cross-posted to Softwires to let Softwire experts = weigh > in their opinion. Please be sure to post your comments to DHC list, > though. Comments sent by end of March 8th, 2017 are much appreciated. >=20 > Bernie & Tomek >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From nobody Fri Feb 24 20:28:37 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C451299B9 for ; Fri, 24 Feb 2017 20:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 aK4OsAuuxXvv for ; Fri, 24 Feb 2017 20:28:35 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D848B129460 for ; Fri, 24 Feb 2017 20:28:34 -0800 (PST) X-AuditID: c618062d-d5fff700000009d8-fa-58b1184e27fe Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id E7.36.02520.E4811B85; Sat, 25 Feb 2017 06:38:25 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0319.002; Fri, 24 Feb 2017 23:28:30 -0500 From: Suresh Krishnan To: Tomek Mrugalski Thread-Topic: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Thread-Index: AQHSjTNw3QKW4kxv/0usH25z4fmyLKF5eKYA Date: Sat, 25 Feb 2017 04:28:29 +0000 Message-ID: <19A0AE7B-FBBA-44D3-A219-D7F43908B972@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_D548DC9E-E5EE-46C0-9496-D1E626C11AA5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyuXSPn26gxMYIg8ufrCzudrQwWuy/toDJ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4t3Qnc0G7TcXdZd2MDYxfzLsYOTkkBEwk WrvmsnQxcnEICaxnlPje18UM4SxnlGj6NI0NpIoNqGrDzs9MILaIgIHEuTvPwWxmAVWJpZc3 MILYwgIxElf/nGGHqImVaLmzBijOAWQbSRyfqg4SZgEq37X5OiuIzStgL3FrYTcjxK6djBJ3 J+8F28UpYCsxY8IWsCJGATGJ76fWQO0Sl7j1ZD4TxNUiEg8vnmaDsEUlXj7+xwphK0l8/D2f HWQos8AURoltJ5YyQmwTlDg58wnLBEaRWUhmzUJWNwtJHUSRtsSyha+ZZwE9wSygIzF5ISNE 2FTi9dGPULa1xIxfB9kgbEWJKd0P2Rcwcqxi5CgtLsjJTTcy2MQIjKxjEmy6OxjvT/c8xCjA wajEw7uhaUOEEGtiWXFl7iFGFaDWRxtWX2CUYsnLz0tVEuHtZNgYIcSbklhZlVqUH19UmpNa fIhRmoNFSZw3bvX9cCGB9MSS1OzU1ILUIpgsEwenVANjQlg2j3SzVoWbtd4ZjY76W1JL2v7U eEz9o/Tur+u5xBlistpl/oJmd14Xvfvo5nGC4fq3aQHiJvzHd278xHf+qcJJVmmV+/qrz7q0 bb+t+lvpd4rhNpk5ibc8GcwDRFvYz6ctmtVdYXd4elSv/fWv77Nm5Hg/t4iZpnt157LZ3zZe 5nHOf1msxFKckWioxVxUnAgAnllr+bQCAAA= Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Updating RFC 3633 with draft-ietf-dhc-dhcpv6-prefix-length-hint-issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 04:28:36 -0000 --Apple-Mail=_D548DC9E-E5EE-46C0-9496-D1E626C11AA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tomek, > On Feb 22, 2017, at 12:45 PM, Tomek Mrugalski = wrote: >=20 > W dniu 21.02.2017 o 05:06, Suresh Krishnan pisze: >>> On Feb 17, 2017, at 12:32 AM, tianxiang li = wrote: >>>=20 >>> Hi all, >>>=20 >>> The IESG review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue = has ended, several reviewers suggested this document should update RFC = 3633, as someone reading RFC3633 would need a pointer to this document. = Hope to receive the comments from the WG regarding this issue.=20 >>>=20 >>> I personally have no objections to adding the Updates: RFC3633 tag = to the document. It would be great if other WG participants can chime in = one way or another. > With my co-chair hat off, I don't have any specific preference here. = On > one hand, if we update 3633, we will be enforcing everyone to follow = the > recommendation made in prefix-length-hint-issue. The obvious benefit = is > that prefix-length-hint-issue will get more exposure, which is a good > thing. On the other hand, the 3315bis work hopefully will be published > later this year and it will obsolete 3633. Assuming the bis work gets > published relatively soon, the window of opportunity when the 3633 > update will be applicable is several months. As Bernie pointed out, > 3315bis references prefix-length-hint-issue. >=20 > If it was completely up to me, I would go with update 3633, because = that > would give this draft immediate exposure to more readers. Also, if > 3315bis publication is delayed for whatever reason, updating seems = like > a better choice. But I wouldn't complain if we decide to go the "don't > update" route. Yes. This was my position as well. I will let Bernie and you make the = call as chairs and let me know. Thanks Suresh= --Apple-Mail=_D548DC9E-E5EE-46C0-9496-D1E626C11AA5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjI1MDQyODMwWjAjBgkqhkiG9w0B CQQxFgQUA6EXUrGnh8Ww3P6prluYAsZXZn0wXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQB8wUnIea9RHMA3uq+2/9U8+XsarzMjtFRJPOi760JZPZYuScgi9b3LfseyVdjF 2KIKbjVa2J+CJ0fxe+pGIq2c2w4QExFxaPGZEaZV3af9oaYjxtnVlrrUkG5Qns3XkBf5/MbilqDE ZYHGuby9SShhTZSxINfUHvqJltVT8Tlq2cXgkzScX7inmLvDjZG3WCtwCzEow274XUvd7/DgN7UE AvB4JsU5BahMCgXB75vje/GZu+mtC8vbV1zIqqkBtoxhH29rsyI83K5iE8MEqAzWPL7/VgO3R7zD b4EtgAlsJHeEHp/IXxB6kAzJm5NfrVYqUk7HRkNWDopRN1bJmA0+AAAAAAAA --Apple-Mail=_D548DC9E-E5EE-46C0-9496-D1E626C11AA5-- From nobody Sun Feb 26 18:24:58 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9585F129605; Sun, 26 Feb 2017 18:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dBezWAr-221G; Sun, 26 Feb 2017 18:24:52 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D13129600; Sun, 26 Feb 2017 18:24:51 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id u108so13084532wrb.3; Sun, 26 Feb 2017 18:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gnn1NBst9I/YTcAgnLp8koDKg6G/QzYYn9eFyatqPpM=; b=lYO/QMJsH4QNbjsumwgapgALjcmyvgBx/j/VCVzB9sQZq8QRoyeomHlGaJTwseo8QY yQKA8ggHXYK6rIu28Jji5NJUiSUZtFKqswWnFDGo867hhWNq5gWz7QzXEycwGU8w7C6v 3QCU/etsh/sl6QqKDDwYFGFflgMdj9cpIgVc3OlJtFn6hyCwCipITgG0cHqX/Mvv5PBB DgA6agfyzePBWQoVOAGpR4/yvlclz+Bzp3rjgGjSR49qdf/OO/CLRfK16ZfvseDDznAw f9S4jEzS0CRfvsoWuqkSoN7gkg0bZIYibAYyARY185or3viRA9QuC7GNXEYXxEUI1IaU wq0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gnn1NBst9I/YTcAgnLp8koDKg6G/QzYYn9eFyatqPpM=; b=KIcPOi/WT1sI9rZz89OuHUzN/AmCTi1aZGd/gh+qvpl5EDg2oLsgbaoQqOOV/EPdbk TWDRNmC/gxK/6yKR6egUvgGm4blYgy8nqdwVZEasFWYTuEBoPQGs/vtE0C8eA7q9Yekj WUmaR3otcssCkWLSj+TcwjEtL75lnbfLcv3OMigqZPac4+GECz0upOY5ckoKhbXeS4jZ unYeEKEMyxUVubG4DCKBe03Nj6sGQ+bgxveQyfsLq2zQgd8F0l5pFMr35bjt6wlgjVOM 0uU0Mw6YZt6p/sCf/gJPdsYM1vE4VrvLprYSRFImjLFp/OVVZWBY2wKJVdDN+RBYtG1D p+Eg== X-Gm-Message-State: AMke39lXLEVq0tGww5Wa2DqRHIUm4EqwYq5gl9orXYykPkEnEbMxk5oNv3aLlHBcMcnkJzPNbd8fDo6VL2VW4A== X-Received: by 10.223.164.85 with SMTP id e21mr13358159wra.111.1488162290419; Sun, 26 Feb 2017 18:24:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.150.85 with HTTP; Sun, 26 Feb 2017 18:24:29 -0800 (PST) In-Reply-To: References: From: Linhui Sun Date: Mon, 27 Feb 2017 10:24:29 +0800 Message-ID: To: Tomek Mrugalski Content-Type: multipart/alternative; boundary=f403045f168ab04f1f054979c8f2 Archived-At: Cc: Softwires-wg , dhcwg , draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org Subject: Re: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 02:24:53 -0000 --f403045f168ab04f1f054979c8f2 Content-Type: text/plain; charset=UTF-8 Hi all, As a co-author, I support the adoption. This document defines new DHCP4o6 options that make dynamic provisioning of softwire mechanisms come true. Best, Linhui 2017-02-23 1:37 GMT+08:00 Tomek Mrugalski : > Hi, > > This message initiates a two weeks long DHC WG adoption call on: > > Title: DHCPv4 over DHCPv6 Source Address Option > Pages: 9 > Date: 2017-02-01 > Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 > Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 > > This document initially started as work intended to be adopted in > Softwires, but after a discussion with chairs, responsible AD (Suresh) > and presenting this work in DHC, the conclusion is to aim for DHC > adoption, not Softwires. Therefore this is a DHC adoption call. > > This message is cross-posted to Softwires to let Softwire experts weigh > in their opinion. Please be sure to post your comments to DHC list, > though. Comments sent by end of March 8th, 2017 are much appreciated. > > Bernie & Tomek > > --f403045f168ab04f1f054979c8f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

As a co-author, I support the a= doption. This document defines new DHCP4o6 options that make dynamic provis= ioning of softwire mechanisms come true.

Best,
Linhui

2017-02-23 1:37 GMT+08:00 Tomek Mrugalski <tomasz.mrugals= ki@gmail.com>:
Hi,

This message initiates a two weeks long DHC WG adoption call on:

Title: DHCPv4 over DHCPv6 Source Address Option
Pages: 9
Date: 2017-02-01
Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07
Link: tools.ietf.org/html/draft-fs= c-softwire-dhcp4o6-saddr-opt-07

This document initially started as work intended to be adopted in
Softwires, but after a discussion with chairs, responsible AD (Suresh)
and presenting this work in DHC, the conclusion is to aim for DHC
adoption, not Softwires. Therefore this is a DHC adoption call.

This message is cross-posted to Softwires to let Softwire experts weigh
in their opinion. Please be sure to post your comments to DHC list,
though. Comments sent by end of March 8th, 2017 are much appreciated.

Bernie & Tomek


--f403045f168ab04f1f054979c8f2-- From nobody Mon Feb 27 06:27:57 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9766912A03B; Mon, 27 Feb 2017 06:27:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148820567661.21101.966899725601394223.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 06:27:56 -0800 Archived-At: Cc: dhc-chairs@ietf.org, draft-ietf-dhc-relay-server-security@ietf.org, dhcwg@ietf.org Subject: [dhcwg] Last Call: (Security of Messages Exchanged Between Servers and Relay Agents) to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 14:27:56 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Security of Messages Exchanged Between Servers and Relay Agents' 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 2017-03-13. 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 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents, but does not require encryption. And, with recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay to relay and relay to server communication for DHCPv6 and relay to server communication for DHCPv4. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Feb 27 11:16:26 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CD3126BF7 for ; Mon, 27 Feb 2017 11:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 hxxJ2Y0qpUM7 for ; Mon, 27 Feb 2017 11:16:23 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446BB12956F for ; Mon, 27 Feb 2017 11:16:23 -0800 (PST) Received: (qmail 32342 invoked from network); 27 Feb 2017 20:09:40 +0100 Received: from pd9e116bb.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.22.187) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 27 Feb 2017 20:09:40 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <0EB0E49E-B201-441B-834B-47A050EDA757@cisco.com> Date: Mon, 27 Feb 2017 20:09:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55F8B4D9-9061-46AB-8D18-197BC834B4F3@kuehlewind.net> References: <148604665210.13944.15621944233917718081.idtracker@ietfa.amsl.com> <35D633DF-B240-4CB9-A1DC-A27FD1048213@kuehlewind.net> <0EB0E49E-B201-441B-834B-47A050EDA757@cisco.com> To: kkinnear X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhc-chairs@ietf.org, dhcwg@ietf.org, Bernie Volz , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, The IESG Subject: Re: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-dhcpv6-failover-protocol-04=3A_=28with_COMMENT=29?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:16:25 -0000 Hi Kim, sorry for my late reply. Thanks for the explanation. Makes sense to me. = I think slightly more explanation in the draft could be good to make = clear that the TCP blocking itself is not the problem but that one kind = of application layer message will block another kind which can lead to = total blocking given only one TCP connection is used for all kind of = message to reduce complexity in connection management. Because currently = it reads a little like if there is a problem with TCP which is not = really the case. Thanks! Mirja > Am 02.02.2017 um 18:43 schrieb kkinnear : >=20 > Mirja, >=20 > More comments, below... >=20 >=20 >> On Feb 2, 2017, at 12:07 PM, Mirja Kuehlewind (IETF) = wrote: >>=20 >> [... removed already handled issue -- Kim] >>=20 >>> 6.1. Creating Connections >>>=20 >>>=20 >>>>=20 >>>> - Also not really clear to me is why OPTION_F_MAX_UNACKED_BNDUPD = is >>>> needed and how the server should know the right value. I guess you = would >>>> want to calculate this based on the send buffer, however, not all = message >>>> have the same size and as such I don't know how to calculate that. = And is >>>> that really needed? If messages will not be accepted by the = receiver-side >>>> server, the receive window will be zero and the socket on the = sending >>>> side will be blocked; no additional message can be send. What will = be >>>> different if the sender knows in advance when it could potentially = happen >>>> (but also might not if the other end processes the messages quickly = and >>>> there is no excessive loss). >>>>=20 >>>=20 >>>=20 >>> The intent here is to keep the TCP connection unblocked, so >>> that information can flow in both directions. If one >>> direction is is maxed out, it shouldn't keep information from >>> flowing in the other direction. At a TCP level it won't, but >>> at an application level it will. Much of the failover >>> information flow involves one server sending a BNDUPD and then >>> the partner sends a BNDREPLY. If one server server sends more >>> BNDUPD's than the other server can absorb, the TCP connection >>> will block. This will mean that any BNDREPLY's from the >>> server that sent the BNDUPD's will also be blocked. Ideally, >>> the BNDUPD->BNDREPLY flow from each server to the other would >>> be independent, and the OPTION_F_MAX_UNACKED_BNDUPD count is >>> designed to help that be true. >>=20 >> So you mean this is purely an application parameter saying I will not = process more than X messages at once (before sending out a BNDREPLY). So = this is rather independent of any socket buffer configuration, expect = that the buffer needs to be large enough to at least handle X (max-size) = messages which maybe is a good thing to notice as well. >=20 > This is an application parameter saying that I can accept up > to X messages at once without blocking the TCP connection. > That isn't in conflict with what you said, but is focused a > bit differently. It is independent of any socket buffer > configuration -- this is application level flow control. >=20 >>=20 >> However, this basically means that you at sender-side anyway need a = way to cache BNDUPD message that you are not allowed to send out yet. = Why don=E2=80=99t you just basically set this value implicitly always to = 1 and say you can=E2=80=99t send another BNDUPD if an BNDREPLY is still = outstanding=E2=80=A6? I would guess it=E2=80=99s anyway rather unlikely = that you need to send more than one message at once, no? >=20 > Servers frequently need send far more than one BNDUPD at once. > The most extreme typical case is when one server is updating a > partner which has been down with information about what has > been happening while the partner was down. This will generate > thousands to tens of thousands of BNDUPD's. When one server > has lost its stable storage completely and needs to > essentially be initialized by the other server, millions of > BNDUPD's may need to flow across the link. >=20 > Doing them one at a time, while technically correct, typically > leaves a lot of performance on the table and could easily > extend the time before the servers synchronize from seconds to > tens of minutes (and possibly hours). Many DHCP servers are > multi-threaded and can process multiple BNDUPD's at the same > time (though they may batch up the writes to the disk). Thus, > we would expect that most servers implementing this protocol > would set this value to something substantial. >=20 >>=20 >>>=20 >>> Additionally, there are messages other than BNDUPD/BNDREPLY >>> (e.g. STATE, DISCONNECT, UPDDONE) that are important to >>> transmit from one server to the other and not have backed up >>> behind a blocked TCP connection that has been overloaded with >>> BNDUPD's for the partner to process. >>>=20 >>> We could have created a separate TCP connection for these >>> control messages, but the overhead of doing that (and >>> specifying that) was great enough that it seemed like using >>> the application-level flow control of the >>> OPTION_F_MAX_UNACKED_BNDUPD was a good tradeoff. >>=20 >> I would actually say that the overhead is rather low. Maybe one = should discuss this option at least as one potential implementation = possibility. The only hard requirement is that the receiver side would = be able to process message coming from different connections from the = same endpoint, which I assume would be easy given you anyway have to = handle different connections from different endpoints, no? >=20 > Having different implementation possibilities in something as > basic as connection management in a protocol already this > complex is something we have tried hard to avoid, and we could > only justify it if it were necessary to solve a very pressing > problem. >=20 > Thanks -- Kim >=20 >=20 From nobody Mon Feb 27 11:37:07 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D2712A2F4; Mon, 27 Feb 2017 11:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 8_jddlM3XEu9; Mon, 27 Feb 2017 11:36:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F5A12A2F3; Mon, 27 Feb 2017 11:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7528; q=dns/txt; s=iport; t=1488224219; x=1489433819; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hirQ+k+PrLun1JOriGE0xvA7rnHsT2HMGkNheKdjlj4=; b=BYQGLD+vVyXuYXKYyErjIJfU150J1oeG/n6cZC07wPxZVKwKhengPgiQ j9PwloxJxggVWSgyX/bwo/Qa+34XC1BfPWgBR74OV7gqoYjaNwdvsUlw6 JfE6IS0CYHeq5DiLwwEFxI2XOeCX2LdZMo2PWCP7vxn1rve9nWs4sveU0 M=; X-IronPort-AV: E=Sophos;i="5.35,215,1484006400"; d="scan'208";a="217359087" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2017 19:36:58 +0000 Received: from dhcp-161-44-67-126.cisco.com (dhcp-161-44-67-126.cisco.com [161.44.67.126]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v1RJavCS017027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2017 19:36:57 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: kkinnear In-Reply-To: <55F8B4D9-9061-46AB-8D18-197BC834B4F3@kuehlewind.net> Date: Mon, 27 Feb 2017 14:36:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148604665210.13944.15621944233917718081.idtracker@ietfa.amsl.com> <35D633DF-B240-4CB9-A1DC-A27FD1048213@kuehlewind.net> <0EB0E49E-B201-441B-834B-47A050EDA757@cisco.com> <55F8B4D9-9061-46AB-8D18-197BC834B4F3@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3124) X-Authenticated-User: kkinnear@cisco.com Archived-At: Cc: Bernie Volz , dhc-chairs@ietf.org, The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org, Kim Kinnear Subject: Re: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-dhcpv6-failover-protocol-04=3A_=28with_COMMENT=29?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:37:01 -0000 Mirja, Thanks for your comment. I will make two (identical) changes based on your suggestion: I will expand the first occurrence of the use of MAX_UNACKED_BNDUPD in Section 6.1.1 "Sending a CONNECT message", from the current: > o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of = BNDUPD > messages that this server is prepared to accept over the = failover > connection without causing the connection to block. to the following: o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of = BNDUPD messages that this server is prepared to accept over the failover connection without causing the connection to block. This is to implement application level flow control over the connection, so that a flood of BNDUPD messages does not cause the connection to = block and thereby prevent other messages from being transmitted=20 over the connection and received by the failover partner. I will also change the second place where OPTION_F_MAX_UNACKED_BNDUPD is transmitted in Section 6.1.2 "Receiving a CONNECT message", where it discusses creating a CONNECTREPLY message, to say the same thing (as it currently has the same "current" text). Thanks -- Kim > On Feb 27, 2017, at 2:09 PM, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Kim, >=20 > sorry for my late reply. Thanks for the explanation. Makes sense to = me. I think slightly more explanation in the draft could be good to make = clear that the TCP blocking itself is not the problem but that one kind = of application layer message will block another kind which can lead to = total blocking given only one TCP connection is used for all kind of = message to reduce complexity in connection management. Because currently = it reads a little like if there is a problem with TCP which is not = really the case. >=20 > Thanks! > Mirja >=20 >=20 >> Am 02.02.2017 um 18:43 schrieb kkinnear : >>=20 >> Mirja, >>=20 >> More comments, below... >>=20 >>=20 >>> On Feb 2, 2017, at 12:07 PM, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> [... removed already handled issue -- Kim] >>>=20 >>>> 6.1. Creating Connections >>>>=20 >>>>=20 >>>>>=20 >>>>> - Also not really clear to me is why OPTION_F_MAX_UNACKED_BNDUPD = is >>>>> needed and how the server should know the right value. I guess you = would >>>>> want to calculate this based on the send buffer, however, not all = message >>>>> have the same size and as such I don't know how to calculate that. = And is >>>>> that really needed? If messages will not be accepted by the = receiver-side >>>>> server, the receive window will be zero and the socket on the = sending >>>>> side will be blocked; no additional message can be send. What will = be >>>>> different if the sender knows in advance when it could potentially = happen >>>>> (but also might not if the other end processes the messages = quickly and >>>>> there is no excessive loss). >>>>>=20 >>>>=20 >>>>=20 >>>> The intent here is to keep the TCP connection unblocked, so >>>> that information can flow in both directions. If one >>>> direction is is maxed out, it shouldn't keep information from >>>> flowing in the other direction. At a TCP level it won't, but >>>> at an application level it will. Much of the failover >>>> information flow involves one server sending a BNDUPD and then >>>> the partner sends a BNDREPLY. If one server server sends more >>>> BNDUPD's than the other server can absorb, the TCP connection >>>> will block. This will mean that any BNDREPLY's from the >>>> server that sent the BNDUPD's will also be blocked. Ideally, >>>> the BNDUPD->BNDREPLY flow from each server to the other would >>>> be independent, and the OPTION_F_MAX_UNACKED_BNDUPD count is >>>> designed to help that be true. >>>=20 >>> So you mean this is purely an application parameter saying I will = not process more than X messages at once (before sending out a = BNDREPLY). So this is rather independent of any socket buffer = configuration, expect that the buffer needs to be large enough to at = least handle X (max-size) messages which maybe is a good thing to notice = as well. >>=20 >> This is an application parameter saying that I can accept up >> to X messages at once without blocking the TCP connection. >> That isn't in conflict with what you said, but is focused a >> bit differently. It is independent of any socket buffer >> configuration -- this is application level flow control. >>=20 >>>=20 >>> However, this basically means that you at sender-side anyway need a = way to cache BNDUPD message that you are not allowed to send out yet. = Why don=E2=80=99t you just basically set this value implicitly always to = 1 and say you can=E2=80=99t send another BNDUPD if an BNDREPLY is still = outstanding=E2=80=A6? I would guess it=E2=80=99s anyway rather unlikely = that you need to send more than one message at once, no? >>=20 >> Servers frequently need send far more than one BNDUPD at once. >> The most extreme typical case is when one server is updating a >> partner which has been down with information about what has >> been happening while the partner was down. This will generate >> thousands to tens of thousands of BNDUPD's. When one server >> has lost its stable storage completely and needs to >> essentially be initialized by the other server, millions of >> BNDUPD's may need to flow across the link. >>=20 >> Doing them one at a time, while technically correct, typically >> leaves a lot of performance on the table and could easily >> extend the time before the servers synchronize from seconds to >> tens of minutes (and possibly hours). Many DHCP servers are >> multi-threaded and can process multiple BNDUPD's at the same >> time (though they may batch up the writes to the disk). Thus, >> we would expect that most servers implementing this protocol >> would set this value to something substantial. >>=20 >>>=20 >>>>=20 >>>> Additionally, there are messages other than BNDUPD/BNDREPLY >>>> (e.g. STATE, DISCONNECT, UPDDONE) that are important to >>>> transmit from one server to the other and not have backed up >>>> behind a blocked TCP connection that has been overloaded with >>>> BNDUPD's for the partner to process. >>>>=20 >>>> We could have created a separate TCP connection for these >>>> control messages, but the overhead of doing that (and >>>> specifying that) was great enough that it seemed like using >>>> the application-level flow control of the >>>> OPTION_F_MAX_UNACKED_BNDUPD was a good tradeoff. >>>=20 >>> I would actually say that the overhead is rather low. Maybe one = should discuss this option at least as one potential implementation = possibility. The only hard requirement is that the receiver side would = be able to process message coming from different connections from the = same endpoint, which I assume would be easy given you anyway have to = handle different connections from different endpoints, no? >>=20 >> Having different implementation possibilities in something as >> basic as connection management in a protocol already this >> complex is something we have tried hard to avoid, and we could >> only justify it if it were necessary to solve a very pressing >> problem. >>=20 >> Thanks -- Kim >>=20 >>=20 >=20 From nobody Mon Feb 27 12:17:09 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC1012A2F6 for ; Mon, 27 Feb 2017 12:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 drLbQzLJMyah for ; Mon, 27 Feb 2017 12:17:05 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1052012A23B for ; Mon, 27 Feb 2017 12:17:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1RKH4CA023300; Mon, 27 Feb 2017 13:17:04 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1RKH1dh023278 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 27 Feb 2017 13:17:02 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 27 Feb 2017 12:17:01 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Mon, 27 Feb 2017 12:17:00 -0800 From: "Templin, Fred L" To: Ted Lemon Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSglOjbTsgor1qYk63PeyrUa0poqFqmOCwgAHRRkCAAWtvcIAAjxqAgACXmWCAABTKhYAOU7JA Date: Mon, 27 Feb 2017 20:17:00 +0000 Message-ID: <5109024ddba44de9a3270e58a4c3270a@XCH15-06-08.nw.nos.boeing.com> References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> <21bd317edc764fc89dc4a13aa541b1c1@XCH15-06-08.nw.nos.boeing.com> <3e5776023c0d447aaccb81dc8ec8724a@XCH-ALN-003.cisco.com> <49129cb6c19c4be3bd483ceb3312bd72@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_5109024ddba44de9a3270e58a4c3270aXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dhcwg , =?utf-8?B?56We5piO6YGU5ZOJ?= , "Bernie Volz \(volz\)" Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 20:17:08 -0000 --_000_5109024ddba44de9a3270e58a4c3270aXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVkLA0KDQpKdXN0IGdldHRpbmcgYmFjayB0byB0aGlzIGFmdGVyIGJlaW5nIGF3YXkgZm9y IHRoZSBwYXN0IHdlZWs6DQoNCg0Kw5ggIEZyZWQsIEkgdGhpbmsgd2UgYWxsIGFncmVlIHRoYXQg dGhpcyBwcm9ibGVtIG5lZWRzIHRvIGJlIHNvbHZlZC4NCg0KSSBzdGlsbCB0aGluayBpdCB3b3Vs ZCBiZSBjbGVhbmVzdCBhbmQgbW9zdCBjb25zaXN0ZW50IHdpdGggcGFzdCB3b3JrcyBpZiB0aGUg YmFzZQ0Kc2VkaGNwdjYgc3BlY2lmaWNhdGlvbiB3ZXJlIHRvIGluY2x1ZGUgdGhlIFJBQU4gb3B0 aW9uIGl0c2VsZi4gQnV0LCBpZiB0aGF0IHdvdWxkDQpub3QgYmUgcG9zc2libGUgYW5kIGlmIChh cyB5b3Ugc2F5KSB0aGVyZSBpcyBhZ3JlZW1lbnQgdGhhdCB0aGlzIHByb2JsZW0gbmVlZHMNCnRv IGJlIHNvbHZlZCwgdGhlbiB3ZSBzaG91bGQgYWRvcHQgdGhlIFJBQU4gZHJhZnQgYXMgYSBkaGN3 ZyB3b3JraW5nIGdyb3VwDQppdGVtIG5vdy4NCg0KDQrDmCAgV2UgZG9uJ3QgYWdyZWUgdGhhdCB3 b3JrIG9uIHRoZSBzZWN1cml0eSBkcmFmdCBtdXN0IHN0b3AgdW50aWwgdGhlIHJhYW4gZHJhZnQg aXMgZG9uZS4NCg0KSSBuZXZlciBzYWlkIG9yIG1lYW50IHRvIGltcGx5IHRoYXQgdGhlIHNlY3Vy aXR5IGRyYWZ0IG11c3Qgc3RvcCB1bnRpbCBSQUFOIGlzIGRvbmUuDQpUbyB0aGUgY29udHJhcnks IHRoZSB0d28gZG9jdW1lbnRzIGNvdWxkIHJ1biBpbiBwYXJhbGxlbCB3aXRoIGJvdGggYmVpbmcg ZGhjd2cgV0cNCml0ZW1zIG5vdyBhbmQgd2l0aCBubyBpbnRlcmRlcGVuZGVuY2llcy4gQnkgYWRv cHRpbmcgUkFBTiBhcyBhIFdHIGl0ZW0gbm93LA0KaW1wbGVtZW50ZXJzIHdvdWxkIGJlIG1vcmUg bGlrZWx5IHRvIGltcGxlbWVudCBSQUFOIGluIHBhcmFsbGVsIHdpdGggc2VkaGNwdjYNCnJhdGhl ciB0aGFuIGRlZmVyIGl0IHRvIHNvbWUgKG11Y2gpIGxhdGVyIHRpbWUuDQoNCg0Kw5ggIEl0J3Mg anVzdCBub3QgdGhhdCBoYXJkLg0KDQpEZWZpbml0ZWx5IGFncmVlLg0KDQpUaGFua3MgLSBGcmVk DQoNCkZyb206IFRlZCBMZW1vbiBbbWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dDQpTZW50OiBTYXR1 cmRheSwgRmVicnVhcnkgMTgsIDIwMTcgOToxNyBBTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyDnpZ7m mI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPjsgQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNp c2NvLmNvbT4NClN1YmplY3Q6IFJFOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQNCg0KRnJlZCwgSSB0aGluayB3 ZSBhbGwgYWdyZWUgdGhhdCB0aGlzIHByb2JsZW0gbmVlZHMgdG8gYmUgc29sdmVkLiBXZSBkb24n dCBhZ3JlZSB0aGF0IHdvcmsgb24gdGhlIHNlY3VyaXR5IGRyYWZ0IG11c3Qgc3RvcCB1bnRpbCB0 aGUgcmFhbiBkcmFmdCBpcyBkb25lLiBJdCdzIGp1c3Qgbm90IHRoYXQgaGFyZC4NCg0KT24gRmVi IDE4LCAyMDE3IDExOjI4IEFNLCAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSGkgQmVy bmllLA0KDQpNeSB1bmRlcnN0YW5kaW5nICBpcyB0aGF0IHNlZGhjcHY2IGlzIGludGVuZGVkIHRv IGJlIGEgcHJvZHVjdCBvZiB0aGUgSUVURiwNCnNvIEkgdGhlcmVmb3JlIGFzc3VtZSB0aGF0IGl0 IGlzIGludGVuZGVkIHRvIGJlIGEgcHJvZHVjdCBvZiBlbmdpbmVlcmluZy4gSXQNCmhhcyBiZWVu IHNob3duIHRoYXQgc2VkaGNwdjYgaGFzIGFuIG9taXNzaW9uIHRoYXQgd2lsbCBsaW1pdCBpdHMg YXBwbGljYWJpbGl0eSwNCmFuZCB0aGF0IHRoYXQgb21pc3Npb24gY2FuIGJlIHJhdGhlciBlYXNp bHkgcmVtZWRpZWQgcHJpb3IgdG8gcHVibGljYXRpb24uIEl0DQp0aGVyZWZvcmUgbWFrZXMgZ29v ZCBlbmdpbmVlcmluZyBzZW5zZSB0byBmaXggdGhlIG9taXNzaW9uIG5vdy4NCg0KVGhlIHByb3Bv c2FsIGFnYWluIGlzIHRvIGhhdmUgc2VkaGNwdjYgc3BlY2lmeSB0aGUgUkFBTiBvcHRpb24gYXMg cGFydCBvZg0KdGhlIGJhc2UgZG9jdW1lbnQuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogQmVy bmllIFZvbHogKHZvbHopIFttYWlsdG86dm9sekBjaXNjby5jb208bWFpbHRvOnZvbHpAY2lzY28u Y29tPl0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTcsIDIwMTcgMzowMCBQTQ0KVG86IFRlbXBs aW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4+OyBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb208bWFpbHRvOm1lbGxv bkBmdWd1ZS5jb20+Pjsg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcDxtYWlsdG86amlu bWVpQHdpZGUuYWQuanA+Pg0KDQpDYzogZGhjd2cgPGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3 Z0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0DQoNCkkgdGhpbmsgdGhl IHBsYW4gaGVyZSBtYWtlcyBzb21lIHNlbnNlIOKApiBzZURIQ1B2NiBoYXMgaGFkIHNldmVyYWwg YXR0ZW1wdHMgYW5kIGJlZW4ga2lja2VkIGJhY2sgdG8gdGhlIFdHLiBTbywgSSB0aGluayB0aGUg V0cgd2FudHMgdG8gZ28gc2xvd2x5IGFuZCBub3QgZGV2ZWxvcCBhIHNvbHV0aW9uIHVudGlsIHNl REhDUHY2IGlzIGxpa2VseSB0byBhZHZhbmNlIGluIHRoZSBJRVNHIChlbmNyeXB0aW9uIHdhcyBv bmx5IGFkZGVkIGZhaXJseSDigJxyZWNlbnRseeKAnSkuDQoNCkFuZCwgaXQgaXNu4oCZdCBsaWtl IHRoZSBkYXkgYWZ0ZXIgc2VESENQdjYgaXMg4oCcYXBwcm92ZWTigJ0gdGhhdCBldmVyeSBjbGll bnQgKGFuZCBzZXJ2ZXIpIHdpbGwgc3VwcG9ydCB0aGlzLiBJdCB3aWxsIHRha2UgdGltZSB0byBy b2xsIG91dC4gQW5kLCBob3BlZnVsbHkgd2UgY2FuIGdldCB0aGUgUkFBTiB3b3JrIG91dCBpbiBh IGZhaXJseSBzaG9ydCB0aW1lLg0KDQpJbiB5b3VyIG5ldHdvcmtzLCBpZiB5b3UgY2Fu4oCZdCBz dXBwb3J0IHNlREhDUHY2IHVudGlsIHlvdSBoYXZlIHNvbWV0aGluZyB0byBzbyBzb2x2ZSB0aGUg UkFBTiBpc3N1ZXMsIHlvdSBvYnZpb3VzbHkgY2Fu4oCZdCBkZXBsb3kgc2VESENQdjYuIEJ1dCB0 aGVyZSBtYXkgYmUgcGxlbnR5IG9mIG90aGVyIG5ldHdvcmtzIHdoZXJlIHRoaXMgaXNu4oCZdCBh biBpc3N1ZSBhbmQgaXQgY291bGQgc3RhcnQgdG8gYmUgZGVwbG95ZWQgKGNvZmZlZSBzaG9wcyBh bmQgZW50ZXJwcmlzZXMpLg0KDQoNCi0gICAgICAgICAgQmVybmllDQoNCkZyb206IFRlbXBsaW4s IEZyZWQgTCBbbWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb21dDQpTZW50OiBGcmlkYXks IEZlYnJ1YXJ5IDE3LCAyMDE3IDU6MzUgUE0NClRvOiBCZXJuaWUgVm9seiAodm9seikgPHZvbHpA Y2lzY28uY29tPG1haWx0bzp2b2x6QGNpc2NvLmNvbT4+OyBUZWQgTGVtb24gPG1lbGxvbkBmdWd1 ZS5jb208bWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20+Pjsg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lk ZS5hZC5qcDxtYWlsdG86amlubWVpQHdpZGUuYWQuanA+Pg0KQ2M6IGRoY3dnIDxkaGN3Z0BpZXRm Lm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtkaGN3Z10gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4 dA0KDQpCZXJuaWUsDQoNClRoZSBkaXNjdXNzaW9uIGdyYXZpdGF0ZWQgdG93YXJkcyBub3QgcmVz dXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2Ng0KSS1EIHByb2dyZXNzZXMgZnVydGhlci4gV2Ug d2lsbCByZWV2YWx1YXRlIHRoaXMgb25jZSBzZWRoY3B2NiBpcyBkb25lLg0KDQpUaGlzIGRvZXMg bm90IG1ha2Ugc2Vuc2UgdG8gbWU7IHNlZGhjcHY2IGlzIHRoZSB2ZXJ5IHJlYXNvbiB0aGF0IFJB QU4gaXMgaW1wb3J0YW50Lg0KSnVzdCBsaWtlIFJGQzM5NzEgZGlkIHdpdGggSVB2NiBORCBUaW1l c3RhbXAgYW5kIE5vbmNlIG9wdGlvbnMsIHNlZGhjcHY2IGNvdWxkDQpkZWZpbmUgdGhlIFJBQU4g b3BlcmF0aW9uIGFuZCBoYXZlIGV2ZXJ5dGhpbmcgb3ZlciBhbmQgZG9uZSB3aXRoIGluIG9uZSBw YXNzLg0KQW5kLCBJIGhhdmUgYWxyZWFkeSBpZGVudGlmaWVkIGEgdXNlIGNhc2Ugd2hlcmUgUkFB TiBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS4NCkFsc28sIEkgd2FzIHVuYWJsZSB0byBhdHRlbmQg IElFVEY5Nywgd2hlcmUgSSBjZXJ0YWlubHkgd291bGQgaGF2ZSBzdG9vZCB1cCBhbmQNCnZvaWNl ZCBteSBwb3NpdGlvbi4NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBkaGN3ZyBbbWFpbHRvOmRo Y3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJuaWUgVm9seiAodm9seikNClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyAyOjM5IFBNDQpUbzogVGVkIExlbW9uIDxt ZWxsb25AZnVndWUuY29tPG1haWx0bzptZWxsb25AZnVndWUuY29tPj47IOelnuaYjumBlOWTiSA8 amlubWVpQHdpZGUuYWQuanA8bWFpbHRvOmppbm1laUB3aWRlLmFkLmpwPj4NCkNjOiBkaGN3ZyA8 ZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbZGhj d2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRo Y3B2Ni0yMC50eHQNCg0KSSBwcmVzZW50ZWQgYWJvdXQgcmVzdXJyZWN0aW5nIGRyYWZ0LWlldGYt ZGhjLWRoY3B2Ni1hZ2VudG9wdC1kZWxlZ2F0ZSBhdCBJRVRGLTk3IChzZWUgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny1kaGMtcmVzdXJyZWN0LWRy YWZ0LWlldGYtZGhjLWRoY3B2Ni1hZ2VudG9wdC1kZWxlZ2F0ZS0wMC5wZGYpLg0KDQpBbmQgdGhl IGNvbmNsdXNpb24gdGhlbiB3YXMgKHNlZSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy85Ny9taW51dGVzL21pbnV0ZXMtOTctZGhjLTAwLnR4dCk6DQoNClRoZSBkaXNjdXNzaW9uIGdy YXZpdGF0ZWQgdG93YXJkcyBub3QgcmVzdXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2Ng0KSS1E IHByb2dyZXNzZXMgZnVydGhlci4gV2Ugd2lsbCByZWV2YWx1YXRlIHRoaXMgb25jZSBzZWRoY3B2 NiBpcyBkb25lLg0KDQoNCi0gICAgICAgICAgQmVybmllDQoNCkZyb206IGRoY3dnIFttYWlsdG86 ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KU2VudDogV2Vk bmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxNyAxOjQ5IFBNDQpUbzog56We5piO6YGU5ZOJIDxqaW5t ZWlAd2lkZS5hZC5qcDxtYWlsdG86amlubWVpQHdpZGUuYWQuanA+Pg0KQ2M6IGRoY3dnIDxkaGN3 Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtkaGN3Z10g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2 LTIwLnR4dA0KDQpPbiBGZWIgMTUsIDIwMTcsIGF0IDE6MzIgUE0sIOelnuaYjumBlOWTiSA8amlu bWVpQHdpZGUuYWQuanA8bWFpbHRvOmppbm1laUB3aWRlLmFkLmpwPj4gd3JvdGU6DQpJIHBlcnNv bmFsbHkgZG9uJ3QgdGhpbmsgaXQgYSBibG9ja2luZyBpc3N1ZSBmb3Igc2VkaGNwdjYsIGJ1dCwg b2YNCmNvdXJzZSwgdGhlIHdnIHNob3VsZCBkZWNpZGUgaXQuDQoNCkl0IGRlZmluaXRlbHkgaXNu J3QgYSBibG9ja2luZyBpc3N1ZSwgYnV0IEZyZWQgaXMgcmlnaHQgdGhhdCBpZiB3ZSBhcmUgZ29p bmcgYWhlYWQgd2l0aCBlbmNyeXB0aW9uLW9ubHksIHdoaWNoIEkgYWdyZWUgaXMgdGhlIHJpZ2h0 IG1vdmUsIHdlIG5lZWQgdG8gZG8gdGhpcyB3b3JrIGFzIHdlbGwuDQoNCg0K --_000_5109024ddba44de9a3270e58a4c3270aXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXI7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJ cGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tNzY5 MDM3NjU5NDEzODExMTk1M21zb2xpc3RwYXJhZ3JhcGgsIGxpLm03NjkwMzc2NTk0MTM4MTExOTUz bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm03NjkwMzc2NTk0MTM4MTExOTUzbXNvbGlzdHBhcmFncmFw aA0KCXttc28tc3R5bGUtbmFtZTptXzc2OTAzNzY1OTQxMzgxMTE5NTNtc29saXN0cGFyYWdyYXBo Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6NjUxNTY3ODM2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTg0MTkwMjkyNiAtMTQyNzIxMTkyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBUZWQs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KdXN0IGdldHRpbmcg YmFjayB0byB0aGlzIGFmdGVyIGJlaW5nIGF3YXkgZm9yIHRoZSBwYXN0IHdlZWs6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkZyZWQsIEkgdGhp bmsgd2UgYWxsIGFncmVlIHRoYXQgdGhpcyBwcm9ibGVtIG5lZWRzIHRvIGJlIHNvbHZlZC48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5JIHN0aWxsIHRoaW5rIGl0IHdvdWxkIGJlIGNsZWFuZXN0IGFuZCBtb3N0 IGNvbnNpc3RlbnQgd2l0aCBwYXN0IHdvcmtzIGlmIHRoZSBiYXNlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PnNlZGhjcHY2IHNwZWNpZmljYXRpb24gd2VyZSB0byBpbmNsdWRlIHRoZSBSQUFOIG9wdGlvbiBp dHNlbGYuIEJ1dCwgaWYgdGhhdCB3b3VsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ub3QgYmUgcG9zc2li bGUgYW5kIGlmIChhcyB5b3Ugc2F5KSB0aGVyZSBpcyBhZ3JlZW1lbnQgdGhhdCB0aGlzIHByb2Js ZW0gbmVlZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dG8gYmUgc29sdmVkLCB0aGVuIHdlIHNob3VsZCBh ZG9wdCB0aGUgUkFBTiBkcmFmdCBhcyBhIGRoY3dnIHdvcmtpbmcgZ3JvdXA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+aXRlbSBub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3 RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPldlIGRvbid0IGFncmVlIHRoYXQgd29yayBvbiB0aGUgc2VjdXJpdHkgZHJh ZnQgbXVzdCBzdG9wIHVudGlsIHRoZSByYWFuIGRyYWZ0IGlzIGRvbmUuPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SSBuZXZlciBzYWlkIG9yIG1lYW50IHRvIGltcGx5IHRoYXQgdGhlIHNlY3VyaXR5IGRyYWZ0 IG11c3Qgc3RvcCB1bnRpbCBSQUFOIGlzIGRvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvIHRoZSBj b250cmFyeSwgdGhlIHR3byBkb2N1bWVudHMgY291bGQgcnVuIGluIHBhcmFsbGVsIHdpdGggYm90 aCBiZWluZyBkaGN3ZyBXRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pdGVtcyBub3cgYW5kIHdpdGggbm8g aW50ZXJkZXBlbmRlbmNpZXMuIEJ5IGFkb3B0aW5nIFJBQU4gYXMgYSBXRyBpdGVtIG5vdyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+aW1wbGVtZW50ZXJzIHdvdWxkIGJlIG1vcmUgbGlrZWx5IHRvIGltcGxl bWVudCBSQUFOIGluIHBhcmFsbGVsIHdpdGggc2VkaGNwdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+cmF0 aGVyIHRoYW4gZGVmZXIgaXQgdG8gc29tZSAobXVjaCkgbGF0ZXIgdGltZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SXQncyBqdXN0IG5vdCB0 aGF0IGhhcmQuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RGVmaW5pdGVseSBhZ3JlZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBU ZWQgTGVtb24gW21haWx0bzptZWxsb25AZnVndWUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNh dHVyZGF5LCBGZWJydWFyeSAxOCwgMjAxNyA5OjE3IEFNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGlu LCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBkaGN3ZyAmbHQ7ZGhjd2dAaWV0Zi5vcmcmZ3Q7OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7npZ7mmI7pgZTl k4k8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gJmx0O2ppbm1laUB3aWRlLmFkLmpwJmd0OzsgQmVy bmllIFZvbHogKHZvbHopICZsdDt2b2x6QGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWll dGYtZGhjLXNlZGhjcHY2LTIwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5GcmVkLCBJIHRoaW5rIHdlIGFsbCBhZ3JlZSB0aGF0IHRoaXMg cHJvYmxlbSBuZWVkcyB0byBiZSBzb2x2ZWQuIFdlIGRvbid0IGFncmVlIHRoYXQgd29yayBvbiB0 aGUgc2VjdXJpdHkgZHJhZnQgbXVzdCBzdG9wIHVudGlsIHRoZSByYWFuIGRyYWZ0IGlzIGRvbmUu IEl0J3MganVzdCBub3QgdGhhdCBoYXJkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRmViIDE4LCAyMDE3IDExOjI4IEFNLCAmcXVvdDtUZW1w bGluLCBGcmVkIEwmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBCZXJuaWUsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TXkgdW5kZXJzdGFuZGluZyAmbmJzcDtp cyB0aGF0IHNlZGhjcHY2IGlzIGludGVuZGVkIHRvIGJlIGEgcHJvZHVjdCBvZiB0aGUgSUVURiw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5zbyBJIHRoZXJlZm9yZSBhc3N1bWUgdGhhdCBpdCBpcyBpbnRl bmRlZCB0byBiZSBhIHByb2R1Y3Qgb2YgZW5naW5lZXJpbmcuIEl0PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+aGFzIGJlZW4gc2hvd24gdGhhdCBzZWRoY3B2NiBoYXMgYW4gb21pc3Npb24gdGhhdCB3aWxs IGxpbWl0IGl0cyBhcHBsaWNhYmlsaXR5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFuZCB0aGF0IHRo YXQgb21pc3Npb24gY2FuIGJlIHJhdGhlciBlYXNpbHkgcmVtZWRpZWQgcHJpb3IgdG8gcHVibGlj YXRpb24uIEl0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlcmVmb3JlIG1ha2VzIGdvb2QgZW5naW5l ZXJpbmcgc2Vuc2UgdG8gZml4IHRoZSBvbWlzc2lvbiBub3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIHByb3Bvc2FsIGFnYWluIGlzIHRvIGhhdmUg c2VkaGNwdjYgc3BlY2lmeSB0aGUgUkFBTiBvcHRpb24gYXMgcGFydCBvZjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPnRoZSBiYXNlIGRvY3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmVybmllIFZvbHog KHZvbHopIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZvbHpAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+dm9sekBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVi cnVhcnkgMTcsIDIwMTcgMzowMCBQTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBMICZs dDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OzsgVGVkIExlbW9uICZsdDs8YSBo cmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1lbGxvbkBmdWd1 ZS5jb208L2E+Jmd0OzsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuelnuaYjumBlOWTiTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1laUB3aWRlLmFkLmpwIiB0YXJnZXQ9 Il9ibGFuayI+amlubWVpQHdpZGUuYWQuanA8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPkNj OjwvYj4gZGhjd2cgJmx0OzxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmRoY3dnQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtk aGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNl ZGhjcHY2LTIwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0 aGluayB0aGUgcGxhbiBoZXJlIG1ha2VzIHNvbWUgc2Vuc2Ug4oCmIHNlREhDUHY2IGhhcyBoYWQg c2V2ZXJhbCBhdHRlbXB0cyBhbmQgYmVlbiBraWNrZWQgYmFjayB0bw0KIHRoZSBXRy4gU28sIEkg dGhpbmsgdGhlIFdHIHdhbnRzIHRvIGdvIHNsb3dseSBhbmQgbm90IGRldmVsb3AgYSBzb2x1dGlv biB1bnRpbCBzZURIQ1B2NiBpcyBsaWtlbHkgdG8gYWR2YW5jZSBpbiB0aGUgSUVTRyAoZW5jcnlw dGlvbiB3YXMgb25seSBhZGRlZCBmYWlybHkg4oCccmVjZW50bHnigJ0pLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCwgaXQgaXNu4oCZdCBsaWtlIHRo ZSBkYXkgYWZ0ZXIgc2VESENQdjYgaXMg4oCcYXBwcm92ZWTigJ0gdGhhdCBldmVyeSBjbGllbnQg KGFuZCBzZXJ2ZXIpIHdpbGwgc3VwcG9ydA0KIHRoaXMuIEl0IHdpbGwgdGFrZSB0aW1lIHRvIHJv bGwgb3V0LiBBbmQsIGhvcGVmdWxseSB3ZSBjYW4gZ2V0IHRoZSBSQUFOIHdvcmsgb3V0IGluIGEg ZmFpcmx5IHNob3J0IHRpbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SW4geW91ciBuZXR3b3JrcywgaWYgeW91IGNhbuKAmXQgc3VwcG9ydCBzZURIQ1B2 NiB1bnRpbCB5b3UgaGF2ZSBzb21ldGhpbmcgdG8gc28gc29sdmUgdGhlIFJBQU4gaXNzdWVzLA0K IHlvdSBvYnZpb3VzbHkgY2Fu4oCZdCBkZXBsb3kgc2VESENQdjYuIEJ1dCB0aGVyZSBtYXkgYmUg cGxlbnR5IG9mIG90aGVyIG5ldHdvcmtzIHdoZXJlIHRoaXMgaXNu4oCZdCBhbiBpc3N1ZSBhbmQg aXQgY291bGQgc3RhcnQgdG8gYmUgZGVwbG95ZWQgKGNvZmZlZSBzaG9wcyBhbmQgZW50ZXJwcmlz ZXMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJtNzY5MDM3NjU5NDEzODExMTk1M21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5p ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRlbXBsaW4s IEZyZWQgTCBbPGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAxNywgMjAxNyA1OjM1IFBNPGJyPg0KPGI+VG86 PC9iPiBCZXJuaWUgVm9seiAodm9seikgJmx0OzxhIGhyZWY9Im1haWx0bzp2b2x6QGNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnZvbHpAY2lzY28uY29tPC9hPiZndDs7IFRlZCBMZW1vbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tZWxsb25A ZnVndWUuY29tPC9hPiZndDs7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gJmx0OzxhIGhyZWY9Im1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcCIgdGFy Z2V0PSJfYmxhbmsiPmppbm1laUB3aWRlLmFkLmpwPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IGRo Y3dnICZsdDs8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5k aGN3Z0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbZGhjd2ddIEZ3 ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0y MC50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5pZSw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgZGlzY3Vzc2lvbiBncmF2aXRhdGVkIHRvd2FyZHMgbm90 IHJlc3VycmVjdGluZyB1bnRpbCB0aGUgc2VkaGNwdjY8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JLUQgcHJvZ3Jlc3Nl cyBmdXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVhdGUgdGhpcyBvbmNlIHNlZGhjcHY2IGlzIGRvbmUu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBkb2Vz IG5vdCBtYWtlIHNlbnNlIHRvIG1lOyBzZWRoY3B2NiBpcyB0aGUgdmVyeSByZWFzb24gdGhhdCBS QUFOIGlzIGltcG9ydGFudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KdXN0IGxpa2UgUkZDMzk3MSBk aWQgd2l0aCBJUHY2IE5EIFRpbWVzdGFtcCBhbmQgTm9uY2Ugb3B0aW9ucywgc2VkaGNwdjYgY291 bGQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kZWZpbmUgdGhlIFJBQU4gb3BlcmF0aW9uIGFuZCBoYXZl IGV2ZXJ5dGhpbmcgb3ZlciBhbmQgZG9uZSB3aXRoIGluIG9uZSBwYXNzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkFuZCwgSSBoYXZlIGFscmVhZHkgaWRlbnRpZmllZCBhIHVzZSBjYXNlIHdoZXJlIFJB QU4gaXMgYWJzb2x1dGVseSBuZWNlc3NhcnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWxzbywgSSB3 YXMgdW5hYmxlIHRvIGF0dGVuZCAmbmJzcDtJRVRGOTcsIHdoZXJlIEkgY2VydGFpbmx5IHdvdWxk IGhhdmUgc3Rvb2QgdXAgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dm9pY2VkIG15IHBvc2l0aW9u Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAt IEZyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gZGhjd2cgWzxhIGhyZWY9Im1haWx0bzpkaGN3Zy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZXJuaWUgVm9seiAodm9seik8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE3IDI6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+ IFRlZCBMZW1vbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20iIHRhcmdldD0i X2JsYW5rIj5tZWxsb25AZnVndWUuY29tPC9hPiZndDs7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7npZ7mmI7p gZTlk4k8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gJmx0OzxhIGhyZWY9Im1haWx0bzpqaW5tZWlA d2lkZS5hZC5qcCIgdGFyZ2V0PSJfYmxhbmsiPmppbm1laUB3aWRlLmFkLmpwPC9hPiZndDs8YnI+ DQo8Yj5DYzo8L2I+IGRoY3dnICZsdDs8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5kaGN3Z0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRm LWRoYy1zZWRoY3B2Ni0yMC50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgcHJlc2VudGVk IGFib3V0IHJlc3VycmVjdGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtYWdlbnRvcHQtZGVsZWdh dGUgYXQgSUVURi05NyAoc2VlDQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LWRoYy1yZXN1cnJlY3QtZHJhZnQtaWV0Zi1kaGMtZGhj cHY2LWFnZW50b3B0LWRlbGVnYXRlLTAwLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny1kaGMtcmVzdXJyZWN0 LWRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1hZ2VudG9wdC1kZWxlZ2F0ZS0wMC5wZGY8L2E+KS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmQgdGhlIGNvbmNs dXNpb24gdGhlbiB3YXMgKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTcvbWludXRlcy9taW51dGVzLTk3LWRoYy0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L21pbnV0ZXMvbWludXRlcy05Ny1k aGMtMDAudHh0PC9hPik6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhl IGRpc2N1c3Npb24gZ3Jhdml0YXRlZCB0b3dhcmRzIG5vdCByZXN1cnJlY3RpbmcgdW50aWwgdGhl IHNlZGhjcHY2PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+SS1EIHByb2dyZXNzZXMgZnVydGhlci4gV2Ugd2lsbCByZWV2 YWx1YXRlIHRoaXMgb25jZSBzZWRoY3B2NiBpcyBkb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtNzY5MDM3NjU5NDEzODExMTk1 M21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5pZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IGRoY3dnIFs8YSBocmVmPSJtYWlsdG86ZGhjd2ctYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGVkIExlbW9uPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgRmVicnVhcnkgMTUsIDIwMTcgMTo0OSBQTTxicj4NCjxiPlRvOjwvYj4gPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhp YyZxdW90OyI+56We5piO6YGU5ZOJPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ICZsdDs8YSBocmVm PSJtYWlsdG86amlubWVpQHdpZGUuYWQuanAiIHRhcmdldD0iX2JsYW5rIj5qaW5tZWlAd2lkZS5h ZC5qcDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkaGN3ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRo Y3dnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZGhjd2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZlYiAxNSwgMjAxNywgYXQgMTozMiBQ TSwNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuelnuaY jumBlOWTiTwvc3Bhbj4gJmx0OzxhIGhyZWY9Im1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcCIgdGFy Z2V0PSJfYmxhbmsiPmppbm1laUB3aWRlLmFkLmpwPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNl cmlmIj5JIHBlcnNvbmFsbHkgZG9uJ3QgdGhpbmsgaXQgYSBibG9ja2luZyBpc3N1ZSBmb3Igc2Vk aGNwdjYsIGJ1dCwgb2Y8YnI+DQpjb3Vyc2UsIHRoZSB3ZyBzaG91bGQgZGVjaWRlIGl0Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SXQgZGVmaW5pdGVseSBpc24ndCBhIGJsb2NraW5nIGlzc3VlLCBidXQgRnJl ZCBpcyByaWdodCB0aGF0IGlmIHdlIGFyZSBnb2luZyBhaGVhZCB3aXRoIGVuY3J5cHRpb24tb25s eSwgd2hpY2ggSSBhZ3JlZSBpcyB0aGUgcmlnaHQgbW92ZSwgd2UgbmVlZCB0byBkbyB0aGlzIHdv cmsgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_5109024ddba44de9a3270e58a4c3270aXCH150608nwnosboeingcom_-- From nobody Mon Feb 27 12:21:48 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF7912A31B for ; Mon, 27 Feb 2017 12:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LsolJiHXypFi for ; Mon, 27 Feb 2017 12:21:36 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61A812A319 for ; Mon, 27 Feb 2017 12:21:34 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id u188so115905613qkc.2 for ; Mon, 27 Feb 2017 12:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ptjtBHZWJsMu3N+l02Z5n76+H7V/BYcOoTSmSULZKhg=; b=efMZJ2vQYjc0TMoOzlmnGfQw+xX+VK+XtK10P9BIvmZyY6w5HV8KnLr0hwX9VdnMmL nii2XvU/dz1X0rjR12hsR6Nv5bqPuJVx6S/bkqpQtNQK4s+oQKsrTy2sO/+qQ/MOLUMm h+Pq/XQjAd9UZN/lEwn3z7yk0QmEVsouOMh+OeWbTJwecjRNDQ+QFVGHor30oNP2exJp T5KyGbTCB8mZOFKt+lzf/H0p52MgGlP4fBxSSkA9ck+UTROrgmdXksL/rnt8OGX3ZLBZ 8psJm+vSOQDSIVPmtIZOu3BgQ4lY8cwwJ7ox6LXWAZcjE8wrpXlR/78TDOA6GcE4pCkr rg+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ptjtBHZWJsMu3N+l02Z5n76+H7V/BYcOoTSmSULZKhg=; b=Gm9laasBNUob0VEdCvK7snCyr/5XMKylTzmQ8k7hUeJyJxfr/9OFDcKFj5WwKKypok nidWqUbizfoA7HLPm2tJNcLgIh/d6MHjignCt3WK80C1C6xe69W0Vr8oG68VZEcb8S27 Kz+Q7uwapKOzYzD0vj/6Rymvc8gudHr+2TO4A6/Y0MdflK7hhuIDcDDbr+5Cnywsve62 VH/ac3BgrV/uVxoNlouH4t6j/Ge1KurOD0MrjTQoIsp8BiY1Yda6UPWo3s4ITHyXFr/V fCqNvcLV+pNcO0PAJhpJz1MZWah9mubEmRJue422G4PSrwbXWWdFWQ6TnIbMsnq2lfCR V7Cw== X-Gm-Message-State: AMke39nGP5SV3knU1Ofc1pOQ3HPT0z6TkFAn/8pCpW1uNv3M6rmtLA/D2AfAtNNsiUhSCw== X-Received: by 10.55.16.67 with SMTP id a64mr17914706qkh.226.1488226893820; Mon, 27 Feb 2017 12:21:33 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:38c7:e4f3:f1d1:bb09? ([2601:18f:801:600:38c7:e4f3:f1d1:bb09]) by smtp.gmail.com with ESMTPSA id y48sm2286103qtc.33.2017.02.27.12.21.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 12:21:33 -0800 (PST) From: Ralph Droms Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2541C9B3-ECFE-4F5E-90AF-AC15B4CCD596" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 27 Feb 2017 15:21:31 -0500 In-Reply-To: <5109024ddba44de9a3270e58a4c3270a@XCH15-06-08.nw.nos.boeing.com> To: "Bernie Volz (volz)" References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> <21bd317edc764fc89dc4a13aa541b1c1@XCH15-06-08.nw.nos.boeing.com> <3e5776023c0d447aaccb81dc8ec8724a@XCH-ALN-003.cisco.com> <49129cb6c19c4be3bd483ceb3312bd72@XCH15-06-08.nw.nos.boeing.com> <5109024ddba44de9a3270e58a4c3270a@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhcwg , Ted Lemon , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [dhcwg] New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 20:21:41 -0000 --Apple-Mail=_2541C9B3-ECFE-4F5E-90AF-AC15B4CCD596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Bernie - a long time ago, if I recall correctly, you asked me if I had = XML source for the earlier RAAN document. I searched around, but can't = seem to find that file. Is the text in that earlier doc at all useful = for this instantiation of RAAN? - Ralph > On Feb 27, 2017, at 3:17 PM, Templin, Fred L = wrote: >=20 > Hi Ted, > =20 > Just getting back to this after being away for the past week: > =20 > =C3=98 Fred, I think we all agree that this problem needs to be = solved. > =20 > I still think it would be cleanest and most consistent with past works = if the base > sedhcpv6 specification were to include the RAAN option itself. But, if = that would > not be possible and if (as you say) there is agreement that this = problem needs > to be solved, then we should adopt the RAAN draft as a dhcwg working = group > item now. > =20 > =C3=98 We don't agree that work on the security draft must stop until = the raan draft is done. > =20 > I never said or meant to imply that the security draft must stop until = RAAN is done. > To the contrary, the two documents could run in parallel with both = being dhcwg WG > items now and with no interdependencies. By adopting RAAN as a WG item = now, > implementers would be more likely to implement RAAN in parallel with = sedhcpv6 > rather than defer it to some (much) later time. > =20 > =C3=98 It's just not that hard. > =20 > Definitely agree. > =20 > Thanks - Fred > =20 > From: Ted Lemon [mailto:mellon@fugue.com]=20 > Sent: Saturday, February 18, 2017 9:17 AM > To: Templin, Fred L > Cc: dhcwg ; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = ; Bernie Volz (volz) > Subject: RE: [dhcwg] Fwd: New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > Fred, I think we all agree that this problem needs to be solved. We = don't agree that work on the security draft must stop until the raan = draft is done. It's just not that hard.=20 > =20 > On Feb 18, 2017 11:28 AM, "Templin, Fred L" > wrote: > Hi Bernie, > =20 > My understanding is that sedhcpv6 is intended to be a product of the = IETF, > so I therefore assume that it is intended to be a product of = engineering. It > has been shown that sedhcpv6 has an omission that will limit its = applicability, > and that that omission can be rather easily remedied prior to = publication. It > therefore makes good engineering sense to fix the omission now. > =20 > The proposal again is to have sedhcpv6 specify the RAAN option as part = of > the base document. > =20 > Thanks - Fred > =20 > From: Bernie Volz (volz) [mailto:volz@cisco.com = ]=20 > Sent: Friday, February 17, 2017 3:00 PM > To: Templin, Fred L >; Ted Lemon >;=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = > >=20 > Cc: dhcwg > > Subject: RE: [dhcwg] Fwd: New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > I think the plan here makes some sense =E2=80=A6 seDHCPv6 has had = several attempts and been kicked back to the WG. So, I think the WG = wants to go slowly and not develop a solution until seDHCPv6 is likely = to advance in the IESG (encryption was only added fairly = =E2=80=9Crecently=E2=80=9D). > =20 > And, it isn=E2=80=99t like the day after seDHCPv6 is =E2=80=9Capproved=E2= =80=9D that every client (and server) will support this. It will take = time to roll out. And, hopefully we can get the RAAN work out in a = fairly short time. > =20 > In your networks, if you can=E2=80=99t support seDHCPv6 until you have = something to so solve the RAAN issues, you obviously can=E2=80=99t = deploy seDHCPv6. But there may be plenty of other networks where this = isn=E2=80=99t an issue and it could start to be deployed (coffee shops = and enterprises). > =20 > - Bernie >=20 > =20 > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com = ]=20 > Sent: Friday, February 17, 2017 5:35 PM > To: Bernie Volz (volz) >; Ted = Lemon >; = =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89> > Cc: dhcwg > > Subject: RE: [dhcwg] Fwd: New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > Bernie, > =20 > The discussion gravitated towards not resurrecting until the sedhcpv6 > I-D progresses further. We will reevaluate this once sedhcpv6 is done. > =20 > This does not make sense to me; sedhcpv6 is the very reason that RAAN = is important. > Just like RFC3971 did with IPv6 ND Timestamp and Nonce options, = sedhcpv6 could > define the RAAN operation and have everything over and done with in = one pass. > And, I have already identified a use case where RAAN is absolutely = necessary. > Also, I was unable to attend IETF97, where I certainly would have = stood up and > voiced my position. > =20 > Thanks - Fred > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org = ] On Behalf Of Bernie Volz (volz) > Sent: Thursday, February 16, 2017 2:39 PM > To: Ted Lemon >; = =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > > Cc: dhcwg > > Subject: Re: [dhcwg] Fwd: New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > I presented about resurrecting draft-ietf-dhc-dhcpv6-agentopt-delegate = at IETF-97 = (seehttps://www.ietf.org/proceedings/97/slides/slides-97-dhc-resurrect-dra= ft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf = ). > =20 > And the conclusion then was (see = https://www.ietf.org/proceedings/97/minutes/minutes-97-dhc-00.txt = ): > =20 > The discussion gravitated towards not resurrecting until the sedhcpv6 > I-D progresses further. We will reevaluate this once sedhcpv6 is done. > =20 > - Bernie >=20 > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org = ] On Behalf Of Ted Lemon > Sent: Wednesday, February 15, 2017 1:49 PM > To: =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > > Cc: dhcwg > > Subject: Re: [dhcwg] Fwd: New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > On Feb 15, 2017, at 1:32 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = > wrote: > I personally don't think it a blocking issue for sedhcpv6, but, of > course, the wg should decide it. > =20 > It definitely isn't a blocking issue, but Fred is right that if we are = going ahead with encryption-only, which I agree is the right move, we = need to do this work as well. > =20 > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_2541C9B3-ECFE-4F5E-90AF-AC15B4CCD596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Bernie - a long time ago, if I recall correctly, you asked me = if I had XML source for the earlier RAAN document.  I searched = around, but can't seem to find that file.  Is the text in that = earlier doc at all useful for this instantiation of RAAN?

- Ralph

On Feb 27, 2017, at 3:17 PM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:

Hi Ted,
 
Just getting back to = this after being away for the past week:
 
=C3=98  Fred, = I think we all agree that this problem needs to be solved.
 
I still think it would = be cleanest and most consistent with past works if the base
sedhcpv6 specification were to include the = RAAN option itself. But, if that would
not be possible and if (as you say) there = is agreement that this problem needs
to be solved, then we should adopt the = RAAN draft as a dhcwg working group
item now.
 
=C3=98  We = don't agree that work on the security draft must stop until the raan = draft is done.
 
I never said or meant = to imply that the security draft must stop until RAAN is done.
To the contrary, the two documents could = run in parallel with both being dhcwg WG
items now and with no interdependencies. = By adopting RAAN as a WG item now,
implementers would be more likely to implement RAAN in = parallel with sedhcpv6
rather than defer it to some (much) later time.
 
=C3=98  It's = just not that hard.
 
Definitely agree.
 
Thanks - Fred
 
From: Ted Lemon = [mailto:mellon@fugue.com] 
Sent: Saturday, February 18, 2017 = 9:17 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: dhcwg= <dhcwg@ietf.org>; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>; = Bernie Volz (volz) <volz@cisco.com>
Subject: RE: [dhcwg] Fwd: New = Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
Fred, I think we all agree that this = problem needs to be solved. We don't agree that work on the security = draft must stop until the raan draft is done. It's just not that = hard. 
 
On Feb 18, 2017 11:28 = AM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
Hi Bernie,
 
My understanding  is that sedhcpv6 is = intended to be a product of the IETF,
so I therefore assume that it is intended = to be a product of engineering. It
has= been shown that sedhcpv6 has an omission that will limit its = applicability,
and that that omission = can be rather easily remedied prior to publication. It
therefore makes good engineering sense to = fix the omission now.
 
The proposal again is = to have sedhcpv6 specify the RAAN option as part of
the base document.
 
Thanks - Fred
 
From: Bernie Volz (volz) = [mailto:volz@cisco.com] 
Sent: Friday, February 17, 2017 = 3:00 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; Ted Lemon <mellon@fugue.com>;=E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 <jinmei@wide.ad.jp>

Cc: dhcwg <dhcwg@ietf.org>
Subject: RE: [dhcwg] Fwd: New = Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
I = think the plan here makes some sense =E2=80=A6 seDHCPv6 has had several = attempts and been kicked back to the WG. So, I think the WG wants to go = slowly and not develop a solution until seDHCPv6 is likely to advance in = the IESG (encryption was only added fairly =E2=80=9Crecently=E2=80=9D).
 
And, it isn=E2=80=99t like the day after = seDHCPv6 is =E2=80=9Capproved=E2=80=9D that every client (and server) = will support this. It will take time to roll out. And, hopefully we can = get the RAAN work out in a fairly short time.
 
In your networks, if you can=E2=80=99t = support seDHCPv6 until you have something to so solve the RAAN issues, = you obviously can=E2=80=99t deploy seDHCPv6. But there may be plenty of = other networks where this isn=E2=80=99t an issue and it could start to = be deployed (coffee shops and enterprises).
 

-          Bernie

 
From: Templin, = Fred L [mailto:Fred.L.Templin@boeing.com] 
Sent: Friday, February 17, 2017 = 5:35 PM
To: Bernie Volz (volz) <volz@cisco.com>; Ted = Lemon <mellon@fugue.com>; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89<jinmei@wide.ad.jp>
Cc: dhcwg= <dhcwg@ietf.org>
Subject: RE: [dhcwg] Fwd: New = Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
Bernie,
 
The = discussion gravitated towards not resurrecting until the = sedhcpv6
I-D progresses further. We will reevaluate this once sedhcpv6 = is done.
 
This does not make sense to me; sedhcpv6 = is the very reason that RAAN is important.
Just like RFC3971 did with IPv6 ND = Timestamp and Nonce options, sedhcpv6 could
define the RAAN operation and have = everything over and done with in one pass.
And, I have already identified a use case = where RAAN is absolutely necessary.
Also, I was unable to attend  IETF97, where I certainly = would have stood up and
voiced my position.
 
Thanks - = Fred
 
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Bernie Volz = (volz)
Sent: Thursday, February 16, 2017 = 2:39 PM
To: Ted Lemon <mellon@fugue.com>; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>
Cc: dhcwg= <dhcwg@ietf.org>
Subject: Re: [dhcwg] Fwd: New = Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
I presented about = resurrecting draft-ietf-dhc-dhcpv6-agentopt-delegate at IETF-97 (seehttps://www.ietf.org/proceedings/97/slides/slides-97-dhc-resurr= ect-draft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf).
 
And the conclusion then was (see https://www.ietf.org/proceedings/97/minutes/minutes-97-dhc-00.t= xt):
 
The = discussion gravitated towards not resurrecting until the = sedhcpv6
I-D progresses further. We will reevaluate this once sedhcpv6 = is done.
 

-          Bernie

 
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ted Lemon
Sent: Wednesday, February 15, = 2017 1:49 PM
To: =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>
Cc: dhcwg= <dhcwg@ietf.org>
Subject: Re: [dhcwg] Fwd: New = Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
On Feb 15, 2017, at 1:32 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp> = wrote:
I personally don't think it a blocking issue for sedhcpv6, = but, of
course, the wg should decide it.
 
It definitely isn't a blocking issue, but = Fred is right that if we are going ahead with encryption-only, which I = agree is the right move, we need to do this work as well.
 
 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

= --Apple-Mail=_2541C9B3-ECFE-4F5E-90AF-AC15B4CCD596-- From nobody Mon Feb 27 12:33:38 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28DF12A31D for ; Mon, 27 Feb 2017 12:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 LPu1deWXT_HV for ; Mon, 27 Feb 2017 12:33:34 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F4412A31B for ; Mon, 27 Feb 2017 12:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61928; q=dns/txt; s=iport; t=1488227614; x=1489437214; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fA9cY+OD0b5FtgHVKO7ala8F12PtZAVohqtpsM9hG9M=; b=Xm8MG2oQjhtoJSh8RKrYKulACpIfjfvR0e1jFKzr8rKMWbK1U+J+vlRn O+FqGbIu3nRnn4VLBRIMwq8xcmF6NnZEYyTgQrk1nCG/EJrlZe6IEyWyb LOTJ24UhAEiXiL518i/qBK6WymRpGD+d1/twl77jVtwyP6v4Mnd+uMn2h A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AQDRjLRY/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5iYYEJB4NUigiRYYgMjSmCCgMfAQ6FdAIaggk/GAECAQEBAQE?= =?us-ascii?q?BAWIohHABAQECAQEBASEKQQkCBQsCAQYCDgMEAQEhAQYDAgICHwYLFAkIAgQOB?= =?us-ascii?q?QgBEolBAw0IDpMJnViCJoc4DYNoAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYs7glG?= =?us-ascii?q?BYA0kCR+CUIJfBZVthXc6AY4FhBiRIYpKiGYBHziBAVQVPoRPHYFhdQGHXYEvg?= =?us-ascii?q?Q0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,215,1484006400"; d="scan'208,217";a="391050482" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2017 20:33:33 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v1RKXXlq017113 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Feb 2017 20:33:33 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Feb 2017 14:33:32 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Mon, 27 Feb 2017 14:33:32 -0600 From: "Bernie Volz (volz)" To: Ralph Droms Thread-Topic: [dhcwg] New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSkTcYLHgVrFA15kCLoS3gsOMP5aF9TAvA Date: Mon, 27 Feb 2017 20:33:32 +0000 Message-ID: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> <21bd317edc764fc89dc4a13aa541b1c1@XCH15-06-08.nw.nos.boeing.com> <3e5776023c0d447aaccb81dc8ec8724a@XCH-ALN-003.cisco.com> <49129cb6c19c4be3bd483ceb3312bd72@XCH15-06-08.nw.nos.boeing.com> <5109024ddba44de9a3270e58a4c3270a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.197] Content-Type: multipart/alternative; boundary="_000_ce035fef09694414854203da8e55ad8aXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: dhcwg , Ted Lemon Subject: Re: [dhcwg] New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 20:33:36 -0000 --_000_ce035fef09694414854203da8e55ad8aXCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNCkkgd291bGQgdGhpbmsgd2Ugd291bGQgc3RhcnQgd2l0aCB0aGUgY3VycmVudCBSQUFO IGRvY3VtZW50IChJIHRoaW5rIHdlIGNhbiBlYXNpbHkgY3JlYXRlIHRoZSBYTUwgZnJvbSB0aGUg VFhUOyB3b3VsZCBoYXZlIGJlZW4gZWFzaWVyIG5vdCB0byBoYXZlIHRvIGRvIHRoYXQgaWYgWE1M IHdhcyBhdmFpbGFibGUpLg0KDQpXZSBoYXZlbuKAmXQgZGlzY3Vzc2VkIGl0IHNlcmlvdXNseSBp biB0aGUgV0cgeWV0LCBhbmQgbm8gb25lIGhhcyByZXF1ZXN0ZWQgdGltZSB0byBkaXNjdXNzIGZ1 cnRoZXIgYXQgSUVURi05OCAoQ2hpY2FnbykuIFRob3VnaCBvZiBjb3Vyc2Ugd2UgY2FuIGRvIGl0 IGhlcmUgb24gdGhlIE1MLg0KDQpNeSBob3BlIHdvdWxkIGJlIHRoYXQgd2UgY2FuIHJlc3RhcnQg dGhpcyB3b3JrIHBlcmhhcHMgYmV0d2VlbiBDaGljYWdvIGFuZCBQcmFndWUsIGFzIGhvcGVmdWxs eSBzZURIQ1B2NiB3aWxsIGdvIHRvIFdHTEMgc29tZXRpbWUgc29vbi4gQnV0IG9mIGNvdXJzZSwg c2VESENQdjYgaGFzIGJlZW4gdGhlcmUgYmVmb3JlIGFuZCBpdCB3YXMgaW4gdGhlIElFU0cgdGhh dCBpdCB3YXMgYm91bmNlZCBiYWNrIHRvIHRoZSBXRyDigJMgdGhvdWdoIGhvcGVmdWxseSB0aGly ZCB0aW1lIHdpbGwgYmUgdGhlIGNoYXJtPw0KDQpXaGVuIGl0IGlzIHRpbWUsIEkgd2FzIGp1c3Qg cGxhbm5pbmcgdG8gZG8gdGhlIGNvbnZlcnNpb24gYW5kIHJlc3VibWl0IGl0IGFzIHRoZSBuZXh0 IHZlcnNpb24gb2YgdGhlIFJBQU4gZG9jdW1lbnQgKHBlcmhhcHMgd2l0aCBtaW5vciBlZGl0cyku IEkgZ3Vlc3MgdGhvdWdoIHRoZXJlIGlzIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHdlIHNob3Vs ZCDigJxyZXN0YXJ04oCdIGFzIGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiBvciB3aGV0aGVyIHRo ZSBXRyBqdXN0IGFncmVlcyB0byByZXN1bWUgd29yayBvbiB0aGlzIGRvY3VtZW50IGFzIGEgV0cg ZG9jdW1lbnQuIEFueXdheSwgd2UgY2FuIGRlYmF0ZSB0aGF0IG9uIHRoZSBsaXN0IGJlZm9yZSBw dWJsaWNhdGlvbi4NCg0KT2YgY291cnNlLCBhbHNvIG5lZWQgdG8gYWxzbyBjaGVjayB3aXRoIHRo ZSBjby1hdXRob3JzICh5b3UgYW5kIE9sZSkgdG8gc2VlIGhvdyBiZXN0IHRvIHByb2NlZWQuIEkg aGFkIGFzc3VtZWQgeW91IGJvdGggd291bGQgc3RheSBvbiDigKYNCg0KQXQgcHJlc2VudCwgdGhl IG9ubHkgb25lIHJlYWxseSBwdXNoaW5nIGZvciB0aGlzIHRvIHN0YXJ0IG5vdyBpcyBGcmVkIFQu DQoNCg0KLSAgICAgICAgICBCZXJuaWUNCg0KRnJvbTogUmFscGggRHJvbXMgW21haWx0bzpyZHJv bXMuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI3LCAyMDE3IDM6MjIg UE0NClRvOiBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPg0KQ2M6IFRlZCBMZW1v biA8bWVsbG9uQGZ1Z3VlLmNvbT47IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz47IOelnuaYjumBlOWT iSA8amlubWVpQHdpZGUuYWQuanA+OyBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20+DQpTdWJqZWN0OiBSZTogW2RoY3dnXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dA0KDQpCZXJuaWUgLSBhIGxvbmcgdGlt ZSBhZ28sIGlmIEkgcmVjYWxsIGNvcnJlY3RseSwgeW91IGFza2VkIG1lIGlmIEkgaGFkIFhNTCBz b3VyY2UgZm9yIHRoZSBlYXJsaWVyIFJBQU4gZG9jdW1lbnQuICBJIHNlYXJjaGVkIGFyb3VuZCwg YnV0IGNhbid0IHNlZW0gdG8gZmluZCB0aGF0IGZpbGUuICBJcyB0aGUgdGV4dCBpbiB0aGF0IGVh cmxpZXIgZG9jIGF0IGFsbCB1c2VmdWwgZm9yIHRoaXMgaW5zdGFudGlhdGlvbiBvZiBSQUFOPw0K DQotIFJhbHBoDQoNCk9uIEZlYiAyNywgMjAxNywgYXQgMzoxNyBQTSwgVGVtcGxpbiwgRnJlZCBM IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPj4gd3JvdGU6DQoNCkhpIFRlZCwNCg0KSnVzdCBnZXR0aW5nIGJhY2sgdG8gdGhpcyBhZnRl ciBiZWluZyBhd2F5IGZvciB0aGUgcGFzdCB3ZWVrOg0KDQo+ICBGcmVkLCBJIHRoaW5rIHdlIGFs bCBhZ3JlZSB0aGF0IHRoaXMgcHJvYmxlbSBuZWVkcyB0byBiZSBzb2x2ZWQuDQoNCkkgc3RpbGwg dGhpbmsgaXQgd291bGQgYmUgY2xlYW5lc3QgYW5kIG1vc3QgY29uc2lzdGVudCB3aXRoIHBhc3Qg d29ya3MgaWYgdGhlIGJhc2UNCnNlZGhjcHY2IHNwZWNpZmljYXRpb24gd2VyZSB0byBpbmNsdWRl IHRoZSBSQUFOIG9wdGlvbiBpdHNlbGYuIEJ1dCwgaWYgdGhhdCB3b3VsZA0Kbm90IGJlIHBvc3Np YmxlIGFuZCBpZiAoYXMgeW91IHNheSkgdGhlcmUgaXMgYWdyZWVtZW50IHRoYXQgdGhpcyBwcm9i bGVtIG5lZWRzDQp0byBiZSBzb2x2ZWQsIHRoZW4gd2Ugc2hvdWxkIGFkb3B0IHRoZSBSQUFOIGRy YWZ0IGFzIGEgZGhjd2cgd29ya2luZyBncm91cA0KaXRlbSBub3cuDQoNCj4gIFdlIGRvbid0IGFn cmVlIHRoYXQgd29yayBvbiB0aGUgc2VjdXJpdHkgZHJhZnQgbXVzdCBzdG9wIHVudGlsIHRoZSBy YWFuIGRyYWZ0IGlzIGRvbmUuDQoNCkkgbmV2ZXIgc2FpZCBvciBtZWFudCB0byBpbXBseSB0aGF0 IHRoZSBzZWN1cml0eSBkcmFmdCBtdXN0IHN0b3AgdW50aWwgUkFBTiBpcyBkb25lLg0KVG8gdGhl IGNvbnRyYXJ5LCB0aGUgdHdvIGRvY3VtZW50cyBjb3VsZCBydW4gaW4gcGFyYWxsZWwgd2l0aCBi b3RoIGJlaW5nIGRoY3dnIFdHDQppdGVtcyBub3cgYW5kIHdpdGggbm8gaW50ZXJkZXBlbmRlbmNp ZXMuIEJ5IGFkb3B0aW5nIFJBQU4gYXMgYSBXRyBpdGVtIG5vdywNCmltcGxlbWVudGVycyB3b3Vs ZCBiZSBtb3JlIGxpa2VseSB0byBpbXBsZW1lbnQgUkFBTiBpbiBwYXJhbGxlbCB3aXRoIHNlZGhj cHY2DQpyYXRoZXIgdGhhbiBkZWZlciBpdCB0byBzb21lIChtdWNoKSBsYXRlciB0aW1lLg0KDQo+ ICBJdCdzIGp1c3Qgbm90IHRoYXQgaGFyZC4NCg0KRGVmaW5pdGVseSBhZ3JlZS4NCg0KVGhhbmtz IC0gRnJlZA0KDQpGcm9tOiBUZWQgTGVtb24gW21haWx0bzptZWxsb25AZnVndWUuY29tXQ0KU2Vu dDogU2F0dXJkYXksIEZlYnJ1YXJ5IDE4LCAyMDE3IDk6MTcgQU0NClRvOiBUZW1wbGluLCBGcmVk IEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb20+Pg0KQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+ Pjsg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcDxtYWlsdG86amlubWVpQHdpZGUuYWQu anA+PjsgQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbTxtYWlsdG86dm9sekBjaXNj by5jb20+Pg0KU3ViamVjdDogUkU6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dA0KDQpGcmVkLCBJIHRoaW5rIHdl IGFsbCBhZ3JlZSB0aGF0IHRoaXMgcHJvYmxlbSBuZWVkcyB0byBiZSBzb2x2ZWQuIFdlIGRvbid0 IGFncmVlIHRoYXQgd29yayBvbiB0aGUgc2VjdXJpdHkgZHJhZnQgbXVzdCBzdG9wIHVudGlsIHRo ZSByYWFuIGRyYWZ0IGlzIGRvbmUuIEl0J3MganVzdCBub3QgdGhhdCBoYXJkLg0KDQpPbiBGZWIg MTgsIDIwMTcgMTE6MjggQU0sICJUZW1wbGluLCBGcmVkIEwiIDxGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpIaSBCZXJu aWUsDQoNCk15IHVuZGVyc3RhbmRpbmcgIGlzIHRoYXQgc2VkaGNwdjYgaXMgaW50ZW5kZWQgdG8g YmUgYSBwcm9kdWN0IG9mIHRoZSBJRVRGLA0Kc28gSSB0aGVyZWZvcmUgYXNzdW1lIHRoYXQgaXQg aXMgaW50ZW5kZWQgdG8gYmUgYSBwcm9kdWN0IG9mIGVuZ2luZWVyaW5nLiBJdA0KaGFzIGJlZW4g c2hvd24gdGhhdCBzZWRoY3B2NiBoYXMgYW4gb21pc3Npb24gdGhhdCB3aWxsIGxpbWl0IGl0cyBh cHBsaWNhYmlsaXR5LA0KYW5kIHRoYXQgdGhhdCBvbWlzc2lvbiBjYW4gYmUgcmF0aGVyIGVhc2ls eSByZW1lZGllZCBwcmlvciB0byBwdWJsaWNhdGlvbi4gSXQNCnRoZXJlZm9yZSBtYWtlcyBnb29k IGVuZ2luZWVyaW5nIHNlbnNlIHRvIGZpeCB0aGUgb21pc3Npb24gbm93Lg0KDQpUaGUgcHJvcG9z YWwgYWdhaW4gaXMgdG8gaGF2ZSBzZWRoY3B2NiBzcGVjaWZ5IHRoZSBSQUFOIG9wdGlvbiBhcyBw YXJ0IG9mDQp0aGUgYmFzZSBkb2N1bWVudC4NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBCZXJu aWUgVm9seiAodm9seikgW21haWx0bzp2b2x6QGNpc2NvLmNvbTxtYWlsdG86dm9sekBjaXNjby5j b20+XQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNywgMjAxNyAzOjAwIFBNDQpUbzogVGVtcGxp biwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tPj47IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86bWVsbG9u QGZ1Z3VlLmNvbT4+O+elnuaYjumBlOWTiSA8amlubWVpQHdpZGUuYWQuanA8bWFpbHRvOmppbm1l aUB3aWRlLmFkLmpwPj4NCg0KQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dA0KDQpJIHRoaW5rIHRoZSBw bGFuIGhlcmUgbWFrZXMgc29tZSBzZW5zZSDigKYgc2VESENQdjYgaGFzIGhhZCBzZXZlcmFsIGF0 dGVtcHRzIGFuZCBiZWVuIGtpY2tlZCBiYWNrIHRvIHRoZSBXRy4gU28sIEkgdGhpbmsgdGhlIFdH IHdhbnRzIHRvIGdvIHNsb3dseSBhbmQgbm90IGRldmVsb3AgYSBzb2x1dGlvbiB1bnRpbCBzZURI Q1B2NiBpcyBsaWtlbHkgdG8gYWR2YW5jZSBpbiB0aGUgSUVTRyAoZW5jcnlwdGlvbiB3YXMgb25s eSBhZGRlZCBmYWlybHkg4oCccmVjZW50bHnigJ0pLg0KDQpBbmQsIGl0IGlzbuKAmXQgbGlrZSB0 aGUgZGF5IGFmdGVyIHNlREhDUHY2IGlzIOKAnGFwcHJvdmVk4oCdIHRoYXQgZXZlcnkgY2xpZW50 IChhbmQgc2VydmVyKSB3aWxsIHN1cHBvcnQgdGhpcy4gSXQgd2lsbCB0YWtlIHRpbWUgdG8gcm9s bCBvdXQuIEFuZCwgaG9wZWZ1bGx5IHdlIGNhbiBnZXQgdGhlIFJBQU4gd29yayBvdXQgaW4gYSBm YWlybHkgc2hvcnQgdGltZS4NCg0KSW4geW91ciBuZXR3b3JrcywgaWYgeW91IGNhbuKAmXQgc3Vw cG9ydCBzZURIQ1B2NiB1bnRpbCB5b3UgaGF2ZSBzb21ldGhpbmcgdG8gc28gc29sdmUgdGhlIFJB QU4gaXNzdWVzLCB5b3Ugb2J2aW91c2x5IGNhbuKAmXQgZGVwbG95IHNlREhDUHY2LiBCdXQgdGhl cmUgbWF5IGJlIHBsZW50eSBvZiBvdGhlciBuZXR3b3JrcyB3aGVyZSB0aGlzIGlzbuKAmXQgYW4g aXNzdWUgYW5kIGl0IGNvdWxkIHN0YXJ0IHRvIGJlIGRlcGxveWVkIChjb2ZmZWUgc2hvcHMgYW5k IGVudGVycHJpc2VzKS4NCg0KDQotICAgICAgICAgIEJlcm5pZQ0KDQpGcm9tOiBUZW1wbGluLCBG cmVkIEwgW21haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tXQ0KU2VudDogRnJpZGF5LCBG ZWJydWFyeSAxNywgMjAxNyA1OjM1IFBNDQpUbzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNp c2NvLmNvbTxtYWlsdG86dm9sekBjaXNjby5jb20+PjsgVGVkIExlbW9uIDxtZWxsb25AZnVndWUu Y29tPG1haWx0bzptZWxsb25AZnVndWUuY29tPj47IOelnuaYjumBlOWTiTxqaW5tZWlAd2lkZS5h ZC5qcDxtYWlsdG86amlubWVpQHdpZGUuYWQuanA+Pg0KQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9y ZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtkaGN3Z10gRndkOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dA0K DQpCZXJuaWUsDQoNClRoZSBkaXNjdXNzaW9uIGdyYXZpdGF0ZWQgdG93YXJkcyBub3QgcmVzdXJy ZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2Ng0KSS1EIHByb2dyZXNzZXMgZnVydGhlci4gV2Ugd2ls bCByZWV2YWx1YXRlIHRoaXMgb25jZSBzZWRoY3B2NiBpcyBkb25lLg0KDQpUaGlzIGRvZXMgbm90 IG1ha2Ugc2Vuc2UgdG8gbWU7IHNlZGhjcHY2IGlzIHRoZSB2ZXJ5IHJlYXNvbiB0aGF0IFJBQU4g aXMgaW1wb3J0YW50Lg0KSnVzdCBsaWtlIFJGQzM5NzEgZGlkIHdpdGggSVB2NiBORCBUaW1lc3Rh bXAgYW5kIE5vbmNlIG9wdGlvbnMsIHNlZGhjcHY2IGNvdWxkDQpkZWZpbmUgdGhlIFJBQU4gb3Bl cmF0aW9uIGFuZCBoYXZlIGV2ZXJ5dGhpbmcgb3ZlciBhbmQgZG9uZSB3aXRoIGluIG9uZSBwYXNz Lg0KQW5kLCBJIGhhdmUgYWxyZWFkeSBpZGVudGlmaWVkIGEgdXNlIGNhc2Ugd2hlcmUgUkFBTiBp cyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS4NCkFsc28sIEkgd2FzIHVuYWJsZSB0byBhdHRlbmQgIElF VEY5Nywgd2hlcmUgSSBjZXJ0YWlubHkgd291bGQgaGF2ZSBzdG9vZCB1cCBhbmQNCnZvaWNlZCBt eSBwb3NpdGlvbi4NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBkaGN3ZyBbbWFpbHRvOmRoY3dn LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJuaWUgVm9seiAodm9seikNClNlbnQ6 IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyAyOjM5IFBNDQpUbzogVGVkIExlbW9uIDxtZWxs b25AZnVndWUuY29tPG1haWx0bzptZWxsb25AZnVndWUuY29tPj47IOelnuaYjumBlOWTiSA8amlu bWVpQHdpZGUuYWQuanA8bWFpbHRvOmppbm1laUB3aWRlLmFkLmpwPj4NCkNjOiBkaGN3ZyA8ZGhj d2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbZGhjd2dd IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2 Ni0yMC50eHQNCg0KSSBwcmVzZW50ZWQgYWJvdXQgcmVzdXJyZWN0aW5nIGRyYWZ0LWlldGYtZGhj LWRoY3B2Ni1hZ2VudG9wdC1kZWxlZ2F0ZSBhdCBJRVRGLTk3IChzZWVodHRwczovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LWRoYy1yZXN1cnJlY3QtZHJhZnQt aWV0Zi1kaGMtZGhjcHY2LWFnZW50b3B0LWRlbGVnYXRlLTAwLnBkZikuDQoNCkFuZCB0aGUgY29u Y2x1c2lvbiB0aGVuIHdhcyAoc2VlIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3 L21pbnV0ZXMvbWludXRlcy05Ny1kaGMtMDAudHh0KToNCg0KVGhlIGRpc2N1c3Npb24gZ3Jhdml0 YXRlZCB0b3dhcmRzIG5vdCByZXN1cnJlY3RpbmcgdW50aWwgdGhlIHNlZGhjcHY2DQpJLUQgcHJv Z3Jlc3NlcyBmdXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVhdGUgdGhpcyBvbmNlIHNlZGhjcHY2IGlz IGRvbmUuDQoNCg0KLSAgICAgICAgICBCZXJuaWUNCg0KRnJvbTogZGhjd2cgW21haWx0bzpkaGN3 Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIExlbW9uDQpTZW50OiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDE1LCAyMDE3IDE6NDkgUE0NClRvOiDnpZ7mmI7pgZTlk4kgPGppbm1laUB3 aWRlLmFkLmpwPG1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcD4+DQpDYzogZGhjd2cgPGRoY3dnQGll dGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2RoY3dnXSBGd2Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAu dHh0DQoNCk9uIEZlYiAxNSwgMjAxNywgYXQgMTozMiBQTSwg56We5piO6YGU5ZOJIDxqaW5tZWlA d2lkZS5hZC5qcDxtYWlsdG86amlubWVpQHdpZGUuYWQuanA+PiB3cm90ZToNCkkgcGVyc29uYWxs eSBkb24ndCB0aGluayBpdCBhIGJsb2NraW5nIGlzc3VlIGZvciBzZWRoY3B2NiwgYnV0LCBvZg0K Y291cnNlLCB0aGUgd2cgc2hvdWxkIGRlY2lkZSBpdC4NCg0KSXQgZGVmaW5pdGVseSBpc24ndCBh IGJsb2NraW5nIGlzc3VlLCBidXQgRnJlZCBpcyByaWdodCB0aGF0IGlmIHdlIGFyZSBnb2luZyBh aGVhZCB3aXRoIGVuY3J5cHRpb24tb25seSwgd2hpY2ggSSBhZ3JlZSBpcyB0aGUgcmlnaHQgbW92 ZSwgd2UgbmVlZCB0byBkbyB0aGlzIHdvcmsgYXMgd2VsbC4NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGhjd2cgbWFpbGluZyBsaXN0DQpkaGN3 Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RoY3dnDQoNCg== --_000_ce035fef09694414854203da8e55ad8aXCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGlj IjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcg MiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglw YW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 TWVubG8tUmVndWxhcjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQpwLm03NjkwMzc2NTk0MTM4MTExOTUzbXNvbGlzdHBhcmFncmFwaCwgbGkubTc2OTAzNzY1 OTQxMzgxMTE5NTNtc29saXN0cGFyYWdyYXBoLCBkaXYubTc2OTAzNzY1OTQxMzgxMTE5NTNtc29s aXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm03NjkwMzc2NTk0MTM4MTExOTUzbXNvbGlz dHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDE5 NDQ2ODg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjk4 Nzk0NTYgLTI5NTI4ODc3MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGk6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHdvdWxkIHRoaW5rIHdlIHdv dWxkIHN0YXJ0IHdpdGggdGhlIGN1cnJlbnQgUkFBTiBkb2N1bWVudCAoSSB0aGluayB3ZSBjYW4g ZWFzaWx5IGNyZWF0ZSB0aGUgWE1MIGZyb20gdGhlIFRYVDsgd291bGQgaGF2ZSBiZWVuIGVhc2ll ciBub3QgdG8gaGF2ZSB0byBkbyB0aGF0DQogaWYgWE1MIHdhcyBhdmFpbGFibGUpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZW7igJl0IGRpc2N1c3Nl ZCBpdCBzZXJpb3VzbHkgaW4gdGhlIFdHIHlldCwgYW5kIG5vIG9uZSBoYXMgcmVxdWVzdGVkIHRp bWUgdG8gZGlzY3VzcyBmdXJ0aGVyIGF0IElFVEYtOTggKENoaWNhZ28pLiBUaG91Z2ggb2YgY291 cnNlIHdlIGNhbiBkbyBpdCBoZXJlIG9uDQogdGhlIE1MLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+TXkgaG9wZSB3b3VsZCBiZSB0aGF0IHdlIGNhbiByZXN0YXJ0 IHRoaXMgd29yayBwZXJoYXBzIGJldHdlZW4gQ2hpY2FnbyBhbmQgUHJhZ3VlLCBhcyBob3BlZnVs bHkgc2VESENQdjYgd2lsbCBnbyB0byBXR0xDIHNvbWV0aW1lIHNvb24uIEJ1dCBvZiBjb3Vyc2Us IHNlREhDUHY2DQogaGFzIGJlZW4gdGhlcmUgYmVmb3JlIGFuZCBpdCB3YXMgaW4gdGhlIElFU0cg dGhhdCBpdCB3YXMgYm91bmNlZCBiYWNrIHRvIHRoZSBXRyDigJMgdGhvdWdoIGhvcGVmdWxseSB0 aGlyZCB0aW1lIHdpbGwgYmUgdGhlIGNoYXJtPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+V2hlbiBpdCBpcyB0aW1lLCBJIHdhcyBqdXN0IHBsYW5uaW5nIHRvIGRv IHRoZSBjb252ZXJzaW9uIGFuZCByZXN1Ym1pdCBpdCBhcyB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRo ZSBSQUFOIGRvY3VtZW50IChwZXJoYXBzIHdpdGggbWlub3IgZWRpdHMpLiBJIGd1ZXNzIHRob3Vn aA0KIHRoZXJlIGlzIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHdlIHNob3VsZCDigJxyZXN0YXJ0 4oCdIGFzIGFuIGluZGl2aWR1YWwgc3VibWlzc2lvbiBvciB3aGV0aGVyIHRoZSBXRyBqdXN0IGFn cmVlcyB0byByZXN1bWUgd29yayBvbiB0aGlzIGRvY3VtZW50IGFzIGEgV0cgZG9jdW1lbnQuIEFu eXdheSwgd2UgY2FuIGRlYmF0ZSB0aGF0IG9uIHRoZSBsaXN0IGJlZm9yZSBwdWJsaWNhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9mIGNvdXJzZSwgYWxz byBuZWVkIHRvIGFsc28gY2hlY2sgd2l0aCB0aGUgY28tYXV0aG9ycyAoeW91IGFuZCBPbGUpIHRv IHNlZSBob3cgYmVzdCB0byBwcm9jZWVkLiBJIGhhZCBhc3N1bWVkIHlvdSBib3RoIHdvdWxkIHN0 YXkgb24g4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BdCBw cmVzZW50LCB0aGUgb25seSBvbmUgcmVhbGx5IHB1c2hpbmcgZm9yIHRoaXMgdG8gc3RhcnQgbm93 IGlzIEZyZWQgVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVybmll PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSYWxwaCBEcm9tcyBb bWFpbHRvOnJkcm9tcy5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXks IEZlYnJ1YXJ5IDI3LCAyMDE3IDM6MjIgUE08YnI+DQo8Yj5Ubzo8L2I+IEJlcm5pZSBWb2x6ICh2 b2x6KSAmbHQ7dm9sekBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUZWQgTGVtb24gJmx0 O21lbGxvbkBmdWd1ZS5jb20mZ3Q7OyBkaGN3ZyAmbHQ7ZGhjd2dAaWV0Zi5vcmcmZ3Q7OyA8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290 aGljJnF1b3Q7Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gJmx0O2ppbm1l aUB3aWRlLmFkLmpwJmd0OzsgVGVtcGxpbiwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RoY3dnXSBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlcm5pZSAtIGEgbG9uZyB0aW1l IGFnbywgaWYgSSByZWNhbGwgY29ycmVjdGx5LCB5b3UgYXNrZWQgbWUgaWYgSSBoYWQgWE1MIHNv dXJjZSBmb3IgdGhlIGVhcmxpZXIgUkFBTiBkb2N1bWVudC4gJm5ic3A7SSBzZWFyY2hlZCBhcm91 bmQsIGJ1dCBjYW4ndCBzZWVtIHRvIGZpbmQgdGhhdCBmaWxlLiAmbmJzcDtJcyB0aGUgdGV4dCBp biB0aGF0IGVhcmxpZXIgZG9jIGF0IGFsbCB1c2VmdWwgZm9yIHRoaXMgaW5zdGFudGlhdGlvbg0K IG9mIFJBQU4/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t IFJhbHBoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBGZWIgMjcsIDIwMTcsIGF0IDM6MTcgUE0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEg aHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iPkZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBUZWQsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5KdXN0IGdldHRpbmcgYmFjayB0byB0aGlzIGFmdGVyIGJlaW5nIGF3YXkgZm9y IHRoZSBwYXN0IHdlZWs6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFG NDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPkZyZWQsIEkgdGhpbmsgd2UgYWxsIGFncmVlIHRoYXQgdGhpcyBwcm9ibGVtDQogbmVl ZHMgdG8gYmUgc29sdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHN0aWxsIHRoaW5rIGl0IHdvdWxkIGJlIGNsZWFu ZXN0IGFuZCBtb3N0IGNvbnNpc3RlbnQgd2l0aCBwYXN0IHdvcmtzIGlmIHRoZSBiYXNlPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnNlZGhjcHY2IHNwZWNpZmljYXRpb24gd2VyZSB0 byBpbmNsdWRlIHRoZSBSQUFOIG9wdGlvbiBpdHNlbGYuIEJ1dCwgaWYgdGhhdCB3b3VsZDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ub3QgYmUgcG9zc2libGUgYW5kIGlmIChhcyB5 b3Ugc2F5KSB0aGVyZSBpcyBhZ3JlZW1lbnQgdGhhdCB0aGlzIHByb2JsZW0gbmVlZHM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dG8gYmUgc29sdmVkLCB0aGVuIHdlIHNob3VsZCBh ZG9wdCB0aGUgUkFBTiBkcmFmdCBhcyBhIGRoY3dnIHdvcmtpbmcgZ3JvdXA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+aXRlbSBub3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5n ZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPldlIGRvbid0IGFncmVlIHRoYXQgd29yayBvbiB0aGUgc2Vj dXJpdHkNCiBkcmFmdCBtdXN0IHN0b3AgdW50aWwgdGhlIHJhYW4gZHJhZnQgaXMgZG9uZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SSBuZXZlciBzYWlkIG9yIG1lYW50IHRvIGltcGx5IHRoYXQgdGhlIHNlY3VyaXR5IGRy YWZ0IG11c3Qgc3RvcCB1bnRpbCBSQUFOIGlzIGRvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRvIHRoZSBjb250cmFyeSwgdGhlIHR3byBkb2N1bWVudHMgY291bGQgcnVuIGlu IHBhcmFsbGVsIHdpdGggYm90aCBiZWluZyBkaGN3ZyBXRzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5pdGVtcyBub3cgYW5kIHdpdGggbm8gaW50ZXJkZXBlbmRlbmNpZXMuIEJ5IGFk b3B0aW5nIFJBQU4gYXMgYSBXRyBpdGVtIG5vdyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+aW1wbGVtZW50ZXJzIHdvdWxkIGJlIG1vcmUgbGlrZWx5IHRvIGltcGxlbWVudCBSQUFO IGluIHBhcmFsbGVsIHdpdGggc2VkaGNwdjY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+cmF0aGVyIHRoYW4gZGVmZXIgaXQgdG8gc29tZSAobXVjaCkgbGF0ZXIgdGltZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+SXQncyBqdXN0IG5vdCB0 aGF0IGhhcmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkRlZmluaXRlbHkgYWdyZWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFu a3MgLSBGcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+VGVkDQogTGVtb24gWzxhIGhyZWY9Im1haWx0bzptZWxsb25AZnVndWUuY29tIj5t YWlsdG86bWVsbG9uQGZ1Z3VlLmNvbTwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TYXR1cmRheSwgRmVicnVhcnkgMTgsIDIwMTcg OToxNyBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+VGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbSI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5kaGN3ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5kaGN3Z0BpZXRm Lm9yZzwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmx0OzxhIGhyZWY9Im1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcCI+amlu bWVpQHdpZGUuYWQuanA8L2E+Jmd0OzsNCiBCZXJuaWUgVm9seiAodm9seikgJmx0OzxhIGhyZWY9 Im1haWx0bzp2b2x6QGNpc2NvLmNvbSI+dm9sekBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5SRTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0 Zi1kaGMtc2VkaGNwdjYtMjAudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyZWQsIEkg dGhpbmsgd2UgYWxsIGFncmVlIHRoYXQgdGhpcyBwcm9ibGVtIG5lZWRzIHRvIGJlIHNvbHZlZC4g V2UgZG9uJ3QgYWdyZWUgdGhhdCB3b3JrIG9uIHRoZSBzZWN1cml0eSBkcmFmdCBtdXN0IHN0b3Ag dW50aWwgdGhlIHJhYW4gZHJhZnQgaXMgZG9uZS4gSXQncyBqdXN0IG5vdCB0aGF0IGhhcmQuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMTgsIDIwMTcgMTE6MjggQU0sICZxdW90O1Rl bXBsaW4sIEZyZWQgTCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkhpIEJlcm5pZSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk15IHVuZGVyc3RhbmRpbmcgJm5ic3A7aXMg dGhhdCBzZWRoY3B2NiBpcyBpbnRlbmRlZCB0byBiZSBhIHByb2R1Y3Qgb2YgdGhlIElFVEYsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnNvIEkgdGhlcmVmb3JlIGFzc3VtZSB0aGF0 IGl0IGlzIGludGVuZGVkIHRvIGJlIGEgcHJvZHVjdCBvZiBlbmdpbmVlcmluZy4gSXQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aGFzIGJlZW4gc2hvd24gdGhhdCBzZWRoY3B2NiBo YXMgYW4gb21pc3Npb24gdGhhdCB3aWxsIGxpbWl0IGl0cyBhcHBsaWNhYmlsaXR5LDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hbmQgdGhhdCB0aGF0IG9taXNzaW9uIGNhbiBiZSBy YXRoZXIgZWFzaWx5IHJlbWVkaWVkIHByaW9yIHRvIHB1YmxpY2F0aW9uLiBJdDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGVyZWZvcmUgbWFrZXMgZ29vZCBlbmdpbmVlcmluZyBz ZW5zZSB0byBmaXggdGhlIG9taXNzaW9uIG5vdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm9wb3Nh bCBhZ2FpbiBpcyB0byBoYXZlIHNlZGhjcHY2IHNwZWNpZnkgdGhlIFJBQU4gb3B0aW9uIGFzIHBh cnQgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlIGJhc2UgZG9jdW1lbnQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QmVybmllDQogVm9seiAodm9seikgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86dm9sekBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj52b2x6QGNpc2NvLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5LCBG ZWJydWFyeSAxNywgMjAxNyAzOjAwIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UZW1wbGluLCBGcmVkIEwgJmx0OzxhIGhy ZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvc3Bhbj48 L2E+Jmd0OzsgVGVkIExlbW9uICZsdDs8YSBocmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1lbGxvbkBmdWd1ZS5j b208L3NwYW4+PC9hPiZndDs7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+56We5piO6YGU5ZOJPC9zcGFuPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDs8YSBocmVmPSJtYWlsdG86amlubWVpQHdp ZGUuYWQuanAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qaW5t ZWlAd2lkZS5hZC5qcDwvc3Bhbj48L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxi cj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+ZGhjd2cgJmx0OzxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRoY3dnQGlldGYub3JnPC9zcGFuPjwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlJFOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0 aGUgcGxhbiBoZXJlIG1ha2VzIHNvbWUgc2Vuc2Ug4oCmIHNlREhDUHY2IGhhcyBoYWQgc2V2ZXJh bCBhdHRlbXB0cyBhbmQgYmVlbiBraWNrZWQgYmFjayB0byB0aGUgV0cuIFNvLCBJIHRoaW5rIHRo ZSBXRyB3YW50cyB0byBnbyBzbG93bHkgYW5kIG5vdCBkZXZlbG9wDQogYSBzb2x1dGlvbiB1bnRp bCBzZURIQ1B2NiBpcyBsaWtlbHkgdG8gYWR2YW5jZSBpbiB0aGUgSUVTRyAoZW5jcnlwdGlvbiB3 YXMgb25seSBhZGRlZCBmYWlybHkg4oCccmVjZW50bHnigJ0pLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5k LCBpdCBpc27igJl0IGxpa2UgdGhlIGRheSBhZnRlciBzZURIQ1B2NiBpcyDigJxhcHByb3ZlZOKA nSB0aGF0IGV2ZXJ5IGNsaWVudCAoYW5kIHNlcnZlcikgd2lsbCBzdXBwb3J0IHRoaXMuIEl0IHdp bGwgdGFrZSB0aW1lIHRvIHJvbGwgb3V0LiBBbmQsIGhvcGVmdWxseSB3ZSBjYW4NCiBnZXQgdGhl IFJBQU4gd29yayBvdXQgaW4gYSBmYWlybHkgc2hvcnQgdGltZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklu IHlvdXIgbmV0d29ya3MsIGlmIHlvdSBjYW7igJl0IHN1cHBvcnQgc2VESENQdjYgdW50aWwgeW91 IGhhdmUgc29tZXRoaW5nIHRvIHNvIHNvbHZlIHRoZSBSQUFOIGlzc3VlcywgeW91IG9idmlvdXNs eSBjYW7igJl0IGRlcGxveSBzZURIQ1B2Ni4gQnV0IHRoZXJlIG1heSBiZSBwbGVudHkNCiBvZiBv dGhlciBuZXR3b3JrcyB3aGVyZSB0aGlzIGlzbuKAmXQgYW4gaXNzdWUgYW5kIGl0IGNvdWxkIHN0 YXJ0IHRvIGJlIGRlcGxveWVkIChjb2ZmZWUgc2hvcHMgYW5kIGVudGVycHJpc2VzKS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0ibTc2OTAzNzY1OTQxMzgxMTE5NTNtc29saXN0cGFyYWdyYXBoIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5p ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRlbXBsaW4sDQogRnJlZCBMIFs8YSBocmVmPSJtYWls dG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPm1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9zcGFuPjwv YT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5GcmlkYXksIEZlYnJ1YXJ5IDE3LCAyMDE3IDU6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkJlcm5pZSBWb2x6 ICh2b2x6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZvbHpAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dm9sekBjaXNjby5jb208L3NwYW4+PC9hPiZn dDs7IFRlZCBMZW1vbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tZWxsb25AZnVndWUuY29tPC9z cGFuPjwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1laUB3aWRlLmFkLmpwIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+amlubWVpQHdpZGUuYWQuanA8L3NwYW4+PC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPmRoY3dnICZsdDs8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaGN3Z0BpZXRmLm9yZzwvc3Bhbj48 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5pZSw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBkaXNjdXNzaW9uIGdyYXZp dGF0ZWQgdG93YXJkcyBub3QgcmVzdXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2Njwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5JLUQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVhdGUgdGhpcyBvbmNl IHNlZGhjcHY2IGlzIGRvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGRvZXMgbm90IG1ha2Ugc2Vu c2UgdG8gbWU7IHNlZGhjcHY2IGlzIHRoZSB2ZXJ5IHJlYXNvbiB0aGF0IFJBQU4gaXMgaW1wb3J0 YW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KdXN0IGxpa2UgUkZDMzk3MSBk aWQgd2l0aCBJUHY2IE5EIFRpbWVzdGFtcCBhbmQgTm9uY2Ugb3B0aW9ucywgc2VkaGNwdjYgY291 bGQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZGVmaW5lIHRoZSBSQUFOIG9wZXJh dGlvbiBhbmQgaGF2ZSBldmVyeXRoaW5nIG92ZXIgYW5kIGRvbmUgd2l0aCBpbiBvbmUgcGFzcy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kLCBJIGhhdmUgYWxyZWFkeSBpZGVu dGlmaWVkIGEgdXNlIGNhc2Ugd2hlcmUgUkFBTiBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWxzbywgSSB3YXMgdW5hYmxlIHRvIGF0dGVu ZCAmbmJzcDtJRVRGOTcsIHdoZXJlIEkgY2VydGFpbmx5IHdvdWxkIGhhdmUgc3Rvb2QgdXAgYW5k PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnZvaWNlZCBteSBwb3NpdGlvbi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5kaGN3Zw0KIFs8YSBocmVmPSJtYWlsdG86ZGhjd2ct Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPm1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+QmVybmllIFZv bHogKHZvbHopPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyAyOjM5IFBNPGJy Pg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5UZWQgTGVtb24gJmx0OzxhIGhyZWY9Im1haWx0bzptZWxsb25AZnVndWUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWVsbG9uQGZ1Z3VlLmNvbTwv c3Bhbj48L2E+Jmd0Ozs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O01TIEdvdGhpYyZxdW90OyI+56We5piO6YGU5ZOJPC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZsdDs8YSBocmVmPSJtYWlsdG86amlubWVpQHdpZGUuYWQuanAiIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qaW5tZWlAd2lkZS5hZC5q cDwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZGhjd2cgJmx0OzxhIGhyZWY9Im1haWx0bzpkaGN3Z0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRoY3dn QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbZGhjd2ddIEZ3ZDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBwcmVz ZW50ZWQgYWJvdXQgcmVzdXJyZWN0aW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1hZ2VudG9wdC1k ZWxlZ2F0ZSBhdCBJRVRGLTk3IChzZWU8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LWRoYy1yZXN1cnJlY3QtZHJhZnQtaWV0Zi1kaGMt ZGhjcHY2LWFnZW50b3B0LWRlbGVnYXRlLTAwLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L3Ns aWRlcy9zbGlkZXMtOTctZGhjLXJlc3VycmVjdC1kcmFmdC1pZXRmLWRoYy1kaGNwdjYtYWdlbnRv cHQtZGVsZWdhdGUtMDAucGRmPC9zcGFuPjwvYT4pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kIHRoZSBj b25jbHVzaW9uIHRoZW4gd2FzIChzZWU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTcvbWludXRlcy9taW51dGVzLTk3LWRoYy0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9t aW51dGVzL21pbnV0ZXMtOTctZGhjLTAwLnR4dDwvc3Bhbj48L2E+KTo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBkaXNjdXNzaW9uIGdyYXZp dGF0ZWQgdG93YXJkcyBub3QgcmVzdXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2Njwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5JLUQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVhdGUgdGhpcyBvbmNl IHNlZGhjcHY2IGlzIGRvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Im03NjkwMzc2NTk0MTM4 MTExOTUzbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi08 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5CZXJuaWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5kaGN3Zw0K IFs8YSBocmVmPSJtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3Jn PC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+VGVkIExlbW9uPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgRmVicnVhcnkgMTUs IDIwMTcgMTo0OSBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+56We5piO6YGU5ZOJPC9zcGFuPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDs8YSBocmVmPSJtYWlsdG86amlubWVp QHdpZGUuYWQuanAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5q aW5tZWlAd2lkZS5hZC5qcDwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZGhjd2cgJmx0OzxhIGhyZWY9 Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmRoY3dnQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBb ZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1z ZWRoY3B2Ni0yMC50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMTUsIDIwMTcsIGF0IDE6 MzIgUE0sPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuelnuaYjumBlOWT iTwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ Jmx0OzxhIGhyZWY9Im1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcCIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmppbm1laUB3aWRlLmFkLmpwPC9zcGFuPjwvYT4mZ3Q7 DQogd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6TWVubG8tUmVndWxhciI+SSBwZXJzb25hbGx5IGRvbid0IHRoaW5rIGl0IGEgYmxvY2tp bmcgaXNzdWUgZm9yIHNlZGhjcHY2LCBidXQsIG9mPGJyPg0KY291cnNlLCB0aGUgd2cgc2hvdWxk IGRlY2lkZSBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQg ZGVmaW5pdGVseSBpc24ndCBhIGJsb2NraW5nIGlzc3VlLCBidXQgRnJlZCBpcyByaWdodCB0aGF0 IGlmIHdlIGFyZSBnb2luZyBhaGVhZCB3aXRoIGVuY3J5cHRpb24tb25seSwgd2hpY2ggSSBhZ3Jl ZSBpcyB0aGUgcmlnaHQgbW92ZSwgd2UgbmVlZCB0byBkbyB0aGlzIHdvcmsgYXMgd2VsbC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxhciI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkaGN3ZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2ciPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_ce035fef09694414854203da8e55ad8aXCHALN003ciscocom_-- From nobody Mon Feb 27 12:43:32 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1333C12A324 for ; Mon, 27 Feb 2017 12:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 8zQ2yJahigP4 for ; Mon, 27 Feb 2017 12:43:28 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D359C12A31A for ; Mon, 27 Feb 2017 12:43:27 -0800 (PST) Received: (qmail 5231 invoked from network); 27 Feb 2017 21:43:26 +0100 Received: from pd9e116bb.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.22.187) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 27 Feb 2017 21:43:26 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Mon, 27 Feb 2017 21:43:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C7DF2A8-7920-458D-906F-4CE4FDF3EB02@kuehlewind.net> References: <148604665210.13944.15621944233917718081.idtracker@ietfa.amsl.com> <35D633DF-B240-4CB9-A1DC-A27FD1048213@kuehlewind.net> <0EB0E49E-B201-441B-834B-47A050EDA757@cisco.com> <55F8B4D9-9061-46AB-8D18-197BC834B4F3@kuehlewind.net> To: kkinnear X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhc-chairs@ietf.org, dhcwg@ietf.org, Bernie Volz , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, The IESG Subject: Re: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-dhcpv6-failover-protocol-04=3A_=28with_COMMENT=29?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 20:43:30 -0000 Great! Thanks! > Am 27.02.2017 um 20:36 schrieb kkinnear : >=20 > Mirja, >=20 > Thanks for your comment. I will make two (identical) changes based > on your suggestion: >=20 > I will expand the first occurrence of the use of MAX_UNACKED_BNDUPD > in Section 6.1.1 "Sending a CONNECT message", from the current: >=20 >> o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of = BNDUPD >> messages that this server is prepared to accept over the = failover >> connection without causing the connection to block. >=20 > to the following: >=20 > o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of = BNDUPD > messages that this server is prepared to accept over the failover > connection without causing the connection to block. This is to > implement application level flow control over the connection, so > that a flood of BNDUPD messages does not cause the connection to = block > and thereby prevent other messages from being transmitted=20 > over the connection and received by the failover partner. >=20 > I will also change the second place where OPTION_F_MAX_UNACKED_BNDUPD > is transmitted in Section 6.1.2 "Receiving a CONNECT message", where = it > discusses creating a CONNECTREPLY message, to say the same thing (as = it > currently has the same "current" text). >=20 > Thanks -- Kim >=20 >> On Feb 27, 2017, at 2:09 PM, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Kim, >>=20 >> sorry for my late reply. Thanks for the explanation. Makes sense to = me. I think slightly more explanation in the draft could be good to make = clear that the TCP blocking itself is not the problem but that one kind = of application layer message will block another kind which can lead to = total blocking given only one TCP connection is used for all kind of = message to reduce complexity in connection management. Because currently = it reads a little like if there is a problem with TCP which is not = really the case. >>=20 >> Thanks! >> Mirja >>=20 >>=20 >>> Am 02.02.2017 um 18:43 schrieb kkinnear : >>>=20 >>> Mirja, >>>=20 >>> More comments, below... >>>=20 >>>=20 >>>> On Feb 2, 2017, at 12:07 PM, Mirja Kuehlewind (IETF) = wrote: >>>>=20 >>>> [... removed already handled issue -- Kim] >>>>=20 >>>>> 6.1. Creating Connections >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> - Also not really clear to me is why OPTION_F_MAX_UNACKED_BNDUPD = is >>>>>> needed and how the server should know the right value. I guess = you would >>>>>> want to calculate this based on the send buffer, however, not all = message >>>>>> have the same size and as such I don't know how to calculate = that. And is >>>>>> that really needed? If messages will not be accepted by the = receiver-side >>>>>> server, the receive window will be zero and the socket on the = sending >>>>>> side will be blocked; no additional message can be send. What = will be >>>>>> different if the sender knows in advance when it could = potentially happen >>>>>> (but also might not if the other end processes the messages = quickly and >>>>>> there is no excessive loss). >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> The intent here is to keep the TCP connection unblocked, so >>>>> that information can flow in both directions. If one >>>>> direction is is maxed out, it shouldn't keep information from >>>>> flowing in the other direction. At a TCP level it won't, but >>>>> at an application level it will. Much of the failover >>>>> information flow involves one server sending a BNDUPD and then >>>>> the partner sends a BNDREPLY. If one server server sends more >>>>> BNDUPD's than the other server can absorb, the TCP connection >>>>> will block. This will mean that any BNDREPLY's from the >>>>> server that sent the BNDUPD's will also be blocked. Ideally, >>>>> the BNDUPD->BNDREPLY flow from each server to the other would >>>>> be independent, and the OPTION_F_MAX_UNACKED_BNDUPD count is >>>>> designed to help that be true. >>>>=20 >>>> So you mean this is purely an application parameter saying I will = not process more than X messages at once (before sending out a = BNDREPLY). So this is rather independent of any socket buffer = configuration, expect that the buffer needs to be large enough to at = least handle X (max-size) messages which maybe is a good thing to notice = as well. >>>=20 >>> This is an application parameter saying that I can accept up >>> to X messages at once without blocking the TCP connection. >>> That isn't in conflict with what you said, but is focused a >>> bit differently. It is independent of any socket buffer >>> configuration -- this is application level flow control. >>>=20 >>>>=20 >>>> However, this basically means that you at sender-side anyway need a = way to cache BNDUPD message that you are not allowed to send out yet. = Why don=E2=80=99t you just basically set this value implicitly always to = 1 and say you can=E2=80=99t send another BNDUPD if an BNDREPLY is still = outstanding=E2=80=A6? I would guess it=E2=80=99s anyway rather unlikely = that you need to send more than one message at once, no? >>>=20 >>> Servers frequently need send far more than one BNDUPD at once. >>> The most extreme typical case is when one server is updating a >>> partner which has been down with information about what has >>> been happening while the partner was down. This will generate >>> thousands to tens of thousands of BNDUPD's. When one server >>> has lost its stable storage completely and needs to >>> essentially be initialized by the other server, millions of >>> BNDUPD's may need to flow across the link. >>>=20 >>> Doing them one at a time, while technically correct, typically >>> leaves a lot of performance on the table and could easily >>> extend the time before the servers synchronize from seconds to >>> tens of minutes (and possibly hours). Many DHCP servers are >>> multi-threaded and can process multiple BNDUPD's at the same >>> time (though they may batch up the writes to the disk). Thus, >>> we would expect that most servers implementing this protocol >>> would set this value to something substantial. >>>=20 >>>>=20 >>>>>=20 >>>>> Additionally, there are messages other than BNDUPD/BNDREPLY >>>>> (e.g. STATE, DISCONNECT, UPDDONE) that are important to >>>>> transmit from one server to the other and not have backed up >>>>> behind a blocked TCP connection that has been overloaded with >>>>> BNDUPD's for the partner to process. >>>>>=20 >>>>> We could have created a separate TCP connection for these >>>>> control messages, but the overhead of doing that (and >>>>> specifying that) was great enough that it seemed like using >>>>> the application-level flow control of the >>>>> OPTION_F_MAX_UNACKED_BNDUPD was a good tradeoff. >>>>=20 >>>> I would actually say that the overhead is rather low. Maybe one = should discuss this option at least as one potential implementation = possibility. The only hard requirement is that the receiver side would = be able to process message coming from different connections from the = same endpoint, which I assume would be easy given you anyway have to = handle different connections from different endpoints, no? >>>=20 >>> Having different implementation possibilities in something as >>> basic as connection management in a protocol already this >>> complex is something we have tried hard to avoid, and we could >>> only justify it if it were necessary to solve a very pressing >>> problem. >>>=20 >>> Thanks -- Kim >>>=20 >>>=20 >>=20 >=20 From nobody Mon Feb 27 13:09:36 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E2A12A0B3; Mon, 27 Feb 2017 13:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ppFLSbTRUHih; Mon, 27 Feb 2017 13:09:29 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA6A12A32E; Mon, 27 Feb 2017 13:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1371; q=dns/txt; s=iport; t=1488229769; x=1489439369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VslAP1HT0uJ8QZhWBAYHH0756il1sMSLiM9LNKY/Je4=; b=hyscMrNurkot+lDpXE/762ZMAUidUyoGiawwjyzsiDbf/Yrk19Os0lvb UGGcOqCWvBtHJSrEGWTm0ni/E5pBfpvYiyTW/+esa6DwaCQfmPIBArLb/ WyCul8EO0bWV9TNjFq4Q7eSamypCzO6WnnnIfZY2ctTvPetNj6bBuArha E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQCSlLRY/4oNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHjVyRYZU1gg0fC4V4AoIjPxgBAgEBAQEBAQFiKIRwAQE?= =?us-ascii?q?BBAEBGx0xAwsMBAIBCA4DAwEBAR8JBycLFAkIAgQBDQUIiWwOswWLMQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2LO4E8iH0FnB4BhnOLKoIEU4RNiX2TMAEfODxFVBU?= =?us-ascii?q?YJoUFgUh1iQ2BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,215,1484006400"; d="scan'208";a="389715055" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Feb 2017 21:09:27 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v1RL9RQW004338 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Feb 2017 21:09:27 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Feb 2017 15:09:27 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Mon, 27 Feb 2017 15:09:26 -0600 From: "Bernie Volz (volz)" To: Tomek Mrugalski , dhcwg Thread-Topic: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 Thread-Index: AQHSjTJgTzD0DDvvFUWkJqPj+VlWC6F9YOpA Date: Mon, 27 Feb 2017 21:09:26 +0000 Message-ID: <65a17561d3b34db7bc162cfb7b99dca9@XCH-ALN-003.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Softwires-wg , "draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org" Subject: Re: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 21:09:31 -0000 I support adoption of this draft in the DHC WG. - Bernie (w/DHC WG co-chair hat off) -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, February 22, 2017 12:38 PM To: dhcwg Cc: Softwires-wg ; draft-fsc-softwire-dhcp4o6-saddr-opt= @ietf.org Subject: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 = - Respond by Mar 8th, 2017 Hi, This message initiates a two weeks long DHC WG adoption call on: Title: DHCPv4 over DHCPv6 Source Address Option Pages: 9 Date: 2017-02-01 Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 This document initially started as work intended to be adopted in Softwires, but after a discussion with chairs, responsible AD (Suresh) and presenting this work in DHC, the conclusion is to aim for DHC adoption, not Softwires. Therefore this is a DHC adoption call. This message is cross-posted to Softwires to let Softwire experts weigh in their opinion. Please be sure to post your comments to DHC list, though. Comments sent by end of March 8th, 2017 are much appreciated. Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Feb 27 13:38:55 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B798128DF6; Mon, 27 Feb 2017 13:38:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148823153450.13763.11460376414288331652.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 13:38:54 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-failover-protocol-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 21:38:54 -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 of the IETF. Title : DHCPv6 Failover Protocol Authors : Tomasz Mrugalski Kim Kinnear Filename : draft-ietf-dhc-dhcpv6-failover-protocol-06.txt Pages : 94 Date : 2017-02-27 Abstract: DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" (RFC3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC7031). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-failover-protocol-06 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 Mon Feb 27 13:50:47 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60D41293FC; Mon, 27 Feb 2017 13:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 uZC7rrv1G8hd; Mon, 27 Feb 2017 13:50:40 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9761293DC; Mon, 27 Feb 2017 13:50:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1981; q=dns/txt; s=iport; t=1488232240; x=1489441840; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=XKoc5J3lZu+Z/5giu6fqu5Teev+Ub5lSNxvDYVpuPnY=; b=dW7QrvGYsB/gJaGX8YLfb41l40srPYORCYfFamfiq11sK2hteno0EaIf PzgMOAPDl48T0Qh5CyqXa3m7YFhnwqqAJBgabSu+lOVyCOmzsjhIuxQ+N TpX1L/RywlFJ6ZkZo8gOY6w3YdDc2VEU9HsoemuG1XghnHcMW0pigyatA k=; X-IronPort-AV: E=Sophos;i="5.35,215,1484006400"; d="scan'208";a="390465047" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2017 21:50:39 +0000 Received: from dhcp-161-44-67-126.cisco.com (dhcp-161-44-67-126.cisco.com [161.44.67.126]) (authenticated bits=0) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v1RLocXl000362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2017 21:50:39 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: kkinnear In-Reply-To: <74FB30F1-234A-4D1C-BF3C-ED4DAA4C3F4E@cisco.com> Date: Mon, 27 Feb 2017 16:50:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148599922705.18700.14648245113952484559.idtracker@ietfa.amsl.com> <2BD6519B-F6AC-4630-8666-13D3ED54054C@cisco.com> <8f0ee693-8fd9-0202-209d-09b503f2231b@cs.tcd.ie> <74FB30F1-234A-4D1C-BF3C-ED4DAA4C3F4E@cisco.com> To: dhc-chairs@ietf.org, The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, "" , Bernie Volz X-Mailer: Apple Mail (2.3124) X-Authenticated-User: kkinnear@cisco.com Archived-At: Cc: Kim Kinnear Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-failover-protocol-04 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 21:50:42 -0000 I have submitted a new version of the DHCPv6 Failover Protocol: draft-ietf-dhc-dhcpv6-failover-protocol-06 = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ = which reflects the final changes resulting from the IESG and directorate reviews to date. All of these changes are to explain things more clearly or explicitly. None of them alter the intended operation of the protocol. The first two changes resulted from a COMMENT by Mirja Kuhlewind. * Expanded the first occurrence of the use of MAX_UNACKED_BNDUPD in Section 6.1.1 "Sending a CONNECT message", from the current: > o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of = BNDUPD > messages that this server is prepared to accept over the failover > connection without causing the connection to block. to the following: o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of BNDUPD messages that this server is prepared to accept over the failover connection without causing the connection to block. This is to implement application level flow control over the connection, so that a flood of BNDUPD messages does not cause the connection to = block and thereby prevent other messages from being transmitted=20 over the connection and received by the failover partner. * Changed the second place where OPTION_F_MAX_UNACKED_BNDUPD is transmitted in Section 6.1.2 "Receiving a CONNECT message", where it discusses creating a CONNECTREPLY message, to say the same thing as above (as it currently has the same "current" text). * Fixed several typographical errors observed while making the above changes (OPTION_F_MAX_UNACKED_BNDUPD was referenced as OPTION_F_UNACKED_BNDUPD). * Added a missing "a" in recently added paragraph in Security Considerations section. Regards -- Kim From nobody Mon Feb 27 19:45:27 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E211294B6; Mon, 27 Feb 2017 19:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 v1D4zPdg-Hrl; Mon, 27 Feb 2017 19:45:24 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19AE129494; Mon, 27 Feb 2017 19:45:23 -0800 (PST) X-AuditID: c618062d-d5fff700000009d8-f4-58b502ce20a7 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id 71.AF.02520.EC205B85; Tue, 28 Feb 2017 05:55:44 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Mon, 27 Feb 2017 22:45:20 -0500 From: Suresh Krishnan To: "Mirja Kuehlewind (IETF)" Thread-Topic: =?utf-8?B?W2RoY3dnXSBNaXJqYSBLw7xobGV3aW5kJ3MgTm8gT2JqZWN0aW9uIG9uIGRy?= =?utf-8?B?YWZ0LWlldGYtZGhjLWRoY3B2Ni1mYWlsb3Zlci1wcm90b2NvbC0wNDogKHdp?= =?utf-8?Q?th_COMMENT)?= Thread-Index: AQHSkTDjW7Up3LdW3kGw2MqZvI6Ba6F9pbiAgAB14YA= Date: Tue, 28 Feb 2017 03:45:20 +0000 Message-ID: <3D105328-2B2D-4E44-B7D7-E6E9210AC4ED@ericsson.com> References: <148604665210.13944.15621944233917718081.idtracker@ietfa.amsl.com> <35D633DF-B240-4CB9-A1DC-A27FD1048213@kuehlewind.net> <0EB0E49E-B201-441B-834B-47A050EDA757@cisco.com> <55F8B4D9-9061-46AB-8D18-197BC834B4F3@kuehlewind.net> <9C7DF2A8-7920-458D-906F-4CE4FDF3EB02@kuehlewind.net> In-Reply-To: <9C7DF2A8-7920-458D-906F-4CE4FDF3EB02@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/signed; boundary="Apple-Mail=_D6B69CCA-F71F-4059-8D53-0DDDC80E8533"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyuXRPiO4Fpq0RBqs7mC3mdO9msrjb0cJo sfBztcWMPxOZLV5c/8hssa3hM5PF8hmaDuweU35vZPVYsuQnk0fLx4WsAcxRXDYpqTmZZalF +nYJXBlXd21hK9iVV9H65zxTA+PWhC5GDg4JAROJj+uiuhi5OIQE1jNKHN90lBnCWc4o8ezM JMYuRk4ONqCiDTs/M4HYIgLGEocnf2cFKWIW6GaSeH/2K5gjLLCLUWLj0inMEFW7GSUae4og bCuJX+cvgsVZBFQlvm7Yzw5i8wrYS1x8NokJYl0/s8S5r72sIAlOASeJ3cd+gTUwCohJfD+1 Bmw1s4C4xK0n88FsCQERiYcXT7NB2KISLx//Y4WwlSTmvL7GDHHeFEaJr4v2s0JsE5Q4OfMJ ywRGkVlIZs1CVjcLSR1EkbbEsoWvmSFsTYn93cuh4qYSr49+ZISwrSVm/DrIBmErSkzpfsi+ gJFjFSNHaXFBTm66kcEmRmBcHpNg093BeH+65yFGAQ5GJR5eg/ItEUKsiWXFlbmHGFWAWh9t WH2BUYolLz8vVUmE9/4moDRvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeuNX3w4UE0hNLUrNTUwtS i2CyTBycUg2MOZczriQtKJZmuRByVZ61lcWhyq1YRzb94DNNjv0+provtA8ztDHEK2wLO36w trdvzU8NB6YFb3ZMVJCpF8u4c0Rj5YspUsy8UZl9dw24ArJKjpSKGNW3WXl/bPseornoSush s23z/vuplhsdYrtyY4Em10n/jKkHn4l8nf9tvUFkSIJA4T0lluKMREMt5qLiRAALtnxG0wIA AA== Archived-At: Cc: Bernie Volz , "dhc-chairs@ietf.org" , The IESG , "draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org" , dhcwg , kkinnear Subject: Re: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-dhcpv6-failover-protocol-04=3A_=28with_COMMENT=29?= X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 03:45:25 -0000 --Apple-Mail=_D6B69CCA-F71F-4059-8D53-0DDDC80E8533 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Mirja. Yours was the last pending comment. I will go ahead and = approve the document. Regards Suresh > On Feb 27, 2017, at 3:43 PM, Mirja Kuehlewind (IETF) = wrote: >=20 > Great! Thanks! >=20 >> Am 27.02.2017 um 20:36 schrieb kkinnear : >>=20 >> Mirja, >>=20 >> Thanks for your comment. I will make two (identical) changes based >> on your suggestion: >>=20 >> I will expand the first occurrence of the use of MAX_UNACKED_BNDUPD >> in Section 6.1.1 "Sending a CONNECT message", from the current: >>=20 >>> o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of = BNDUPD >>> messages that this server is prepared to accept over the = failover >>> connection without causing the connection to block. >>=20 >> to the following: >>=20 >> o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of = BNDUPD >> messages that this server is prepared to accept over the failover >> connection without causing the connection to block. This is to >> implement application level flow control over the connection, so >> that a flood of BNDUPD messages does not cause the connection to = block >> and thereby prevent other messages from being transmitted=20 >> over the connection and received by the failover partner. >>=20 >> I will also change the second place where OPTION_F_MAX_UNACKED_BNDUPD >> is transmitted in Section 6.1.2 "Receiving a CONNECT message", where = it >> discusses creating a CONNECTREPLY message, to say the same thing (as = it >> currently has the same "current" text). >>=20 >> Thanks -- Kim >>=20 >>> On Feb 27, 2017, at 2:09 PM, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> Hi Kim, >>>=20 >>> sorry for my late reply. Thanks for the explanation. Makes sense to = me. I think slightly more explanation in the draft could be good to make = clear that the TCP blocking itself is not the problem but that one kind = of application layer message will block another kind which can lead to = total blocking given only one TCP connection is used for all kind of = message to reduce complexity in connection management. Because currently = it reads a little like if there is a problem with TCP which is not = really the case. >>>=20 >>> Thanks! >>> Mirja >>>=20 >>>=20 >>>> Am 02.02.2017 um 18:43 schrieb kkinnear : >>>>=20 >>>> Mirja, >>>>=20 >>>> More comments, below... >>>>=20 >>>>=20 >>>>> On Feb 2, 2017, at 12:07 PM, Mirja Kuehlewind (IETF) = wrote: >>>>>=20 >>>>> [... removed already handled issue -- Kim] >>>>>=20 >>>>>> 6.1. Creating Connections >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> - Also not really clear to me is why OPTION_F_MAX_UNACKED_BNDUPD = is >>>>>>> needed and how the server should know the right value. I guess = you would >>>>>>> want to calculate this based on the send buffer, however, not = all message >>>>>>> have the same size and as such I don't know how to calculate = that. And is >>>>>>> that really needed? If messages will not be accepted by the = receiver-side >>>>>>> server, the receive window will be zero and the socket on the = sending >>>>>>> side will be blocked; no additional message can be send. What = will be >>>>>>> different if the sender knows in advance when it could = potentially happen >>>>>>> (but also might not if the other end processes the messages = quickly and >>>>>>> there is no excessive loss). >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The intent here is to keep the TCP connection unblocked, so >>>>>> that information can flow in both directions. If one >>>>>> direction is is maxed out, it shouldn't keep information from >>>>>> flowing in the other direction. At a TCP level it won't, but >>>>>> at an application level it will. Much of the failover >>>>>> information flow involves one server sending a BNDUPD and then >>>>>> the partner sends a BNDREPLY. If one server server sends more >>>>>> BNDUPD's than the other server can absorb, the TCP connection >>>>>> will block. This will mean that any BNDREPLY's from the >>>>>> server that sent the BNDUPD's will also be blocked. Ideally, >>>>>> the BNDUPD->BNDREPLY flow from each server to the other would >>>>>> be independent, and the OPTION_F_MAX_UNACKED_BNDUPD count is >>>>>> designed to help that be true. >>>>>=20 >>>>> So you mean this is purely an application parameter saying I will = not process more than X messages at once (before sending out a = BNDREPLY). So this is rather independent of any socket buffer = configuration, expect that the buffer needs to be large enough to at = least handle X (max-size) messages which maybe is a good thing to notice = as well. >>>>=20 >>>> This is an application parameter saying that I can accept up >>>> to X messages at once without blocking the TCP connection. >>>> That isn't in conflict with what you said, but is focused a >>>> bit differently. It is independent of any socket buffer >>>> configuration -- this is application level flow control. >>>>=20 >>>>>=20 >>>>> However, this basically means that you at sender-side anyway need = a way to cache BNDUPD message that you are not allowed to send out yet. = Why don=E2=80=99t you just basically set this value implicitly always to = 1 and say you can=E2=80=99t send another BNDUPD if an BNDREPLY is still = outstanding=E2=80=A6? I would guess it=E2=80=99s anyway rather unlikely = that you need to send more than one message at once, no? >>>>=20 >>>> Servers frequently need send far more than one BNDUPD at once. >>>> The most extreme typical case is when one server is updating a >>>> partner which has been down with information about what has >>>> been happening while the partner was down. This will generate >>>> thousands to tens of thousands of BNDUPD's. When one server >>>> has lost its stable storage completely and needs to >>>> essentially be initialized by the other server, millions of >>>> BNDUPD's may need to flow across the link. >>>>=20 >>>> Doing them one at a time, while technically correct, typically >>>> leaves a lot of performance on the table and could easily >>>> extend the time before the servers synchronize from seconds to >>>> tens of minutes (and possibly hours). Many DHCP servers are >>>> multi-threaded and can process multiple BNDUPD's at the same >>>> time (though they may batch up the writes to the disk). Thus, >>>> we would expect that most servers implementing this protocol >>>> would set this value to something substantial. >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Additionally, there are messages other than BNDUPD/BNDREPLY >>>>>> (e.g. STATE, DISCONNECT, UPDDONE) that are important to >>>>>> transmit from one server to the other and not have backed up >>>>>> behind a blocked TCP connection that has been overloaded with >>>>>> BNDUPD's for the partner to process. >>>>>>=20 >>>>>> We could have created a separate TCP connection for these >>>>>> control messages, but the overhead of doing that (and >>>>>> specifying that) was great enough that it seemed like using >>>>>> the application-level flow control of the >>>>>> OPTION_F_MAX_UNACKED_BNDUPD was a good tradeoff. >>>>>=20 >>>>> I would actually say that the overhead is rather low. Maybe one = should discuss this option at least as one potential implementation = possibility. The only hard requirement is that the receiver side would = be able to process message coming from different connections from the = same endpoint, which I assume would be easy given you anyway have to = handle different connections from different endpoints, no? >>>>=20 >>>> Having different implementation possibilities in something as >>>> basic as connection management in a protocol already this >>>> complex is something we have tried hard to avoid, and we could >>>> only justify it if it were necessary to solve a very pressing >>>> problem. >>>>=20 >>>> Thanks -- Kim >>>>=20 >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_D6B69CCA-F71F-4059-8D53-0DDDC80E8533 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjI4MDM0NTE5WjAjBgkqhkiG9w0B CQQxFgQUOuubvLhgcf9pVvHD3tah2jUxTU0wXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQDPhtMqCEEUtepHJY/QsSJWTxsOAdoeFWIkW9cr8viFfD7WVgb3baeiASovWaV9 TVQSvUJMxj1WbETg2CB74HdWL6M3MAidz21AtsU6MmKfzLaL/vNq0ekVKrHl4+s7nkDxwVs5EUbT uEkyYkF/avdj6665ScdCVAchNlsF7o/4HDiTgwMwZNs5N67UleJXawKZN4Mxes/DSl8pNh19TFaC V3CGp3mNhjKcJLbuPNcd3tUIwSt4g/7gZihE1ZM9nFT+O+UUcjMGXx/DCsHGYucKQQcmLVsyWX8c 6ZAcd06REHzxfECXYA0RKQX4TS9ecH6Ii6qXzLZZJyeq1s2Us7cuAAAAAAAA --Apple-Mail=_D6B69CCA-F71F-4059-8D53-0DDDC80E8533-- From nobody Tue Feb 28 05:25:21 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6119A1295FB; Tue, 28 Feb 2017 05:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Mdk7pq3cWx3y; Tue, 28 Feb 2017 05:25:19 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172D812952E; Tue, 28 Feb 2017 05:25:19 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id x10so7484952otb.1; Tue, 28 Feb 2017 05:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jOMVcQajZi+fhRwnEmI2vrlWfOcWpKcTmbHGuQU77zE=; b=FVcJ50+baL/NEtOynoGpu9Ie66Q9NjgM71AXYb8mltJl+HrTf3Z3yKNNKtccy+0eOp 53O8+DtUfGmRLFam5/dWvQAC7yAyUa5f7YmPGmy/1W5ke70VJr+KscsX35k0JLwoOSJc zm3FRHgv5E5ko/pKhcwIx3O1OM87355BtX9fktS/ajtVVCoz6l2+MtGXg0VabIu1E4Oa ZdoBqHP0SkbRFPk7/7uPP0lETcgBAIw4h7z74gNkDN1j7UCGErQtxjpezWKts+SPy97v krXxVOmR/vE6/ALwmu3GjaCQ4VD0nFbqi61CF710KtNjrSwrjxROmRIyaZNqGajZvApz 3qyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jOMVcQajZi+fhRwnEmI2vrlWfOcWpKcTmbHGuQU77zE=; b=X/q1XyzRSOpmw7y++o7u1yIrZIO4pYAoTM/xsr2lxxMItFGn6yraikhVp8I4PPzmRP ca8t9248gLTERQI2B2w7vFzIMpf5XpVpteJclE6WyVjDeHn8eROwCBAWXLEAJkwcQ2iB h3ylNQeCSH0cHZYjMB4H0y6qQt/a9zR3IeTjbXwLpAmmqE+nL1SaEIjqr0ewUDUwgxWl aJppsfe+J3cxTZbJP0BX8aqpFsDMpfwZ+Q6yLvgHWr2V4h3y4RNEQAYUdGQfz7rZ+HIb UIkfhTbAXUmfvOgpoXnUHh4vE4SRyyoZb+CLKVrtomL7bDTwkQe3Iyu/hEfe9bEQpoWn okKw== X-Gm-Message-State: AMke39ltxJqb1Df5Uh5/qRIFxG5iSCGiKMTz9QSdNEK00ILtqDQ+IpmKlGANZhhktaHg94rZRZrvDXnHBpHQFQ== X-Received: by 10.157.12.148 with SMTP id b20mr1086952otb.262.1488288318450; Tue, 28 Feb 2017 05:25:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.1.204 with HTTP; Tue, 28 Feb 2017 05:24:38 -0800 (PST) In-Reply-To: References: From: tianxiang li Date: Tue, 28 Feb 2017 21:24:38 +0800 Message-ID: To: Tomek Mrugalski Content-Type: multipart/alternative; boundary=001a1141995a8b7351054997202e Archived-At: Cc: Softwires-wg , dhcwg , draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org Subject: Re: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 13:25:20 -0000 --001a1141995a8b7351054997202e Content-Type: text/plain; charset=UTF-8 Hi all, I participated in the review of this draft, I think it is an important document for the dynamic provisioning of some 4over6 Softwire mechanisms. I support its adoption. Cheers, Tianxiang 2017-02-23 1:37 GMT+08:00 Tomek Mrugalski : > Hi, > > This message initiates a two weeks long DHC WG adoption call on: > > Title: DHCPv4 over DHCPv6 Source Address Option > Pages: 9 > Date: 2017-02-01 > Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 > Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 > > This document initially started as work intended to be adopted in > Softwires, but after a discussion with chairs, responsible AD (Suresh) > and presenting this work in DHC, the conclusion is to aim for DHC > adoption, not Softwires. Therefore this is a DHC adoption call. > > This message is cross-posted to Softwires to let Softwire experts weigh > in their opinion. Please be sure to post your comments to DHC list, > though. Comments sent by end of March 8th, 2017 are much appreciated. > > Bernie & Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --001a1141995a8b7351054997202e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

= I participated in the review of this draft, I think it is an important docu= ment for the dynamic provisioning of some 4over6 Softwire mechanisms. I sup= port its adoption.

=
Cheers,
<= span style=3D"font-size:14px">Tianxiang

2017-02-23 1:37 GMT+08:00 Tomek Mr= ugalski <tomasz.mrugalski@gmail.com>:
Hi,

This message initiates a two weeks long DHC WG adoption call on:

Title: DHCPv4 over DHCPv6 Source Address Option
Pages: 9
Date: 2017-02-01
Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07
Link: tools.ietf.org/html/draft-fs= c-softwire-dhcp4o6-saddr-opt-07

This document initially started as work intended to be adopted in
Softwires, but after a discussion with chairs, responsible AD (Suresh)
and presenting this work in DHC, the conclusion is to aim for DHC
adoption, not Softwires. Therefore this is a DHC adoption call.

This message is cross-posted to Softwires to let Softwire experts weigh
in their opinion. Please be sure to post your comments to DHC list,
though. Comments sent by end of March 8th, 2017 are much appreciated.

Bernie & Tomek

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

--001a1141995a8b7351054997202e-- From nobody Tue Feb 28 05:46:03 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04023129539 for ; Tue, 28 Feb 2017 05:46:02 -0800 (PST) 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 fWDJUyMoN6so for ; Tue, 28 Feb 2017 05:46:00 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF00129449 for ; Tue, 28 Feb 2017 05:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488289555; x=1488894355; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=mYjFQU/fvP4I+X1zkVptEfOjX MnmvRBLN1L820wVNwU=; b=LXYgLFvP+LD0zZ0fGNmsnCKq1VeXFy1RFy+GouYbQ j73JNP1JmSzHqZEuDaewlKZ7yo4UBAR4R70+gMLxcdrmQiCKS7Ezt/gP+eEItpt4 e/tCxlCiVqn6eR019YOBgCAF+XuFtLbjd+YmgGn8jYUhpOaKaBwrcwabhWXz4PNG VY= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=HatpPWB0RqUMBVV58rn1dtXcpJzzCAMP+6TOQWkBiPoOK6RS7T0ZDtAfqgDk H/ITyrQRZpy3L+VoBqErP6nWcMMa3qmn6YqYg9u79fU9PSmxJkabuRO0V pcvKF1g/oWaaOq+46dG8ZzJzC/3IX2+7GM0yuOGYUS2lwCFSyTLwx0=; X-MDAV-Processed: mail.consulintel.es, Tue, 28 Feb 2017 14:45:55 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 28 Feb 2017 14:45:52 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005375771.msg for ; Tue, 28 Feb 2017 14:45:52 +0100 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170228:md50005375771::88wFDBuaOjvtN/Rf:00000RIk X-Return-Path: prvs=123297a6ff=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: dhcwg@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 28 Feb 2017 14:45:50 +0100 From: JORDI PALET MARTINEZ To: Softwires-wg Message-ID: <310EA505-584D-4CBB-BC77-C111E95E3576@consulintel.es> Thread-Topic: [Softwires] [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: dhcwg , draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org Subject: Re: [dhcwg] [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 13:46:02 -0000 +1 Saludos, Jordi -----Mensaje original----- De: Softwires en nombre de tianxiang li Responder a: Fecha: martes, 28 de febrero de 2017, 14:24 Para: Tomek Mrugalski CC: Softwires-wg , dhcwg , Asunto: Re: [Softwires] [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 Hi all, I participated in the review of this draft, I think it is an important document for the dynamic provisioning of some 4over6 Softwire mechanisms. I support its adoption. Cheers, Tianxiang 2017-02-23 1:37 GMT+08:00 Tomek Mrugalski : Hi, This message initiates a two weeks long DHC WG adoption call on: Title: DHCPv4 over DHCPv6 Source Address Option Pages: 9 Date: 2017-02-01 Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 This document initially started as work intended to be adopted in Softwires, but after a discussion with chairs, responsible AD (Suresh) and presenting this work in DHC, the conclusion is to aim for DHC adoption, not Softwires. Therefore this is a DHC adoption call. This message is cross-posted to Softwires to let Softwire experts weigh in their opinion. Please be sure to post your comments to DHC list, though. Comments sent by end of March 8th, 2017 are much appreciated. Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From nobody Tue Feb 28 06:36:37 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B81C1295A6 for ; Tue, 28 Feb 2017 06:36:35 -0800 (PST) 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 lFolcuaebuW6 for ; Tue, 28 Feb 2017 06:36:34 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD218129506 for ; Tue, 28 Feb 2017 06:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1488292504; x=1488897304; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=LJMKejqUsWf7LYPE/6xkkfwmL YNijUNLYjIC5S6OGPY=; b=CV7O6VLJbqR1VHGF45C8BGu3+xz2juAAEpzzPSPvc vXgcIYxhF1oDx2HWJm6/x+5reBRWrDaPRZx/Yrb4ff8ED4tpkM5p99vz3d2RpuJe ARuAQthFp2F5t80/PVBiqM0MFDaWENkfriTZq8jarjeA3hr+dngXtigDNfioqmr7 0g= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=SQ8BYECx33US1FDvQycocF1c9t0cxZO4LsNTHp7+rOWJTR6kwWsV75azEstV lSdATsQ/PrB+NR7C7RgmVA7x8+0MOa/5XBBZcpp40fkftckJP4HhZJaVv JmAzo2lHrM5BR3h11xf6SA9C6e92pYUDRkXV6elih8V9D67H0Hingg=; X-MDAV-Processed: mail.consulintel.es, Tue, 28 Feb 2017 15:35:04 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 28 Feb 2017 15:35:01 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005375807.msg for ; Tue, 28 Feb 2017 15:35:00 +0100 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170228:md50005375807::3hL+UB0AVU1QwVET:00001RZw X-Return-Path: prvs=123297a6ff=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: dhcwg@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 28 Feb 2017 15:34:58 +0100 From: JORDI PALET MARTINEZ To: Softwires-wg , dhcwg Message-ID: <73A065E1-9BA8-4CED-A0E7-FB20CCFD22E0@consulintel.es> Thread-Topic: [Softwires] [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 References: <28B67AF7-8C70-467E-9D31-606291FB539F@consulintel.es> In-Reply-To: <28B67AF7-8C70-467E-9D31-606291FB539F@consulintel.es> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org Subject: Re: [dhcwg] [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 14:36:35 -0000 By the way =E2=80=A6 While working in draft-palet-v6ops-rfc7084-bis-01, I have reviewed all the = documents to be included as CE requirements for different transition mechan= isms, and one of them is RFC7598. =20 Then I was looking at your document draft-fsc-softwire-dhcp4o6-saddr-opt-07= and I was surprised to read that this document, if approved, will update R= FC7568. =20 RFC7568 is about SSL 3.0. =20 So, my guess is that you meant to update RFC7598? =20 Just so the authors can update the XML to avoid this error to go on ... Regards, Jordi =20 -----Mensaje original----- De: JORDI PALET MARTINEZ Fecha: martes, 28 de febrero de 2017, 14:45 Para: Softwires-wg CC: dhcwg , Asunto: Re: [Softwires] [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o= 6-saddr-opt-07 - Respond by Mar 8th, 2017 +1 =20 Saludos, Jordi =20 =20 -----Mensaje original----- De: Softwires en nombre de tianxiang li Responder a: Fecha: martes, 28 de febrero de 2017, 14:24 Para: Tomek Mrugalski CC: Softwires-wg , dhcwg , Asunto: Re: [Softwires] [dhcwg] Adoption call for draft-fsc-softwire-dh= cp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 =20 Hi all, I participated in the review of this draft, I think it is an import= ant document for the dynamic provisioning of some 4over6 Softwire mechanism= s. I support its adoption. =20 =20 Cheers, Tianxiang =20 =20 2017-02-23 1:37 GMT+08:00 Tomek Mrugalski : =20 Hi, =20 This message initiates a two weeks long DHC WG adoption call on: =20 Title: DHCPv4 over DHCPv6 Source Address Option Pages: 9 Date: 2017-02-01 Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 <= http://tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07> =20 This document initially started as work intended to be adopted in Softwires, but after a discussion with chairs, responsible AD (Sure= sh) and presenting this work in DHC, the conclusion is to aim for DHC adoption, not Softwires. Therefore this is a DHC adoption call. =20 This message is cross-posted to Softwires to let Softwire experts w= eigh in their opinion. Please be sure to post your comments to DHC list, though. Comments sent by end of March 8th, 2017 are much appreciate= d. =20 Bernie & Tomek =20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg =20 =20 =20 =20 =20 _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Tue Feb 28 06:44:49 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40271295A6; Tue, 28 Feb 2017 06:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KqM3CpXhZ3CS; Tue, 28 Feb 2017 06:44:46 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08281295A1; Tue, 28 Feb 2017 06:44:45 -0800 (PST) Received: from ians-mbp.lan ([80.159.248.112]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0Lfjxq-1byz951weg-00pIgS; Tue, 28 Feb 2017 15:44:29 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ian Farrer In-Reply-To: <73A065E1-9BA8-4CED-A0E7-FB20CCFD22E0@consulintel.es> Date: Tue, 28 Feb 2017 15:44:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <754344A6-D33A-4189-9D2B-D139C34AB130@gmx.com> References: <28B67AF7-8C70-467E-9D31-606291FB539F@consulintel.es> <73A065E1-9BA8-4CED-A0E7-FB20CCFD22E0@consulintel.es> To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.3124) X-Provags-ID: V03:K0:gYo+lpQ/1PI4elqm6vM+LFn+6vLIiBf1kpJDO0uFgejFmT9OV/b +LxlBA9KEcst7uRdTnjInXDX+onR7FeiQWwZ+n88q9VMVBQlB+WO31cQcVNiqHnE8fS+K1g kg870ebD/2k+j2VMEWy6NMykHUscyCSsphUy9FzJR/BJgxyj+hvGB+wy/eVUJv+/PudaGn7 KtRdk6zOAR/uZOYNt9pTA== X-UI-Out-Filterresults: notjunk:1;V01:K0:cZ02c/h7GR8=:25jHPozwfDfXkdUyud2Ydf STOv/c8yTG67hnloggeyDG37XjIBRbupjWadMo1gDFx6LFT//v3R05ylS2cxP3O451frO5aWx FfOpwySyrm40VozB25x64OPPvbpHupCZaVmJaAEXYn66G9jK7kGPzdydswcBQZ4dgNPhzGpvc IsiLmnAgHrmDtpvkGDjZqrWHjoW2rDiiexqi99D1zpJFF6MeH0paPCSHcdSMXiHwGKgguYO5U eyM7Dp1JiBoYRR98ru40ciIgwwylwo+Z4tLgY6JJzpZlsxqoAc3oAVWQPdFpxHHfoyn0jEZV9 RVLgY1mkd3COVn6DtPxeGYYfkWhpxZr7oaHTd0crNKjlyOCwcgfRHv00XfWzvdVI2tlufkoYr ELul6XhqTRl2+S2rA5oHiKlSoJdy2h+upiCAD9yIYEyFYoQ+/oLfLg9KdvQXIaC+lFqxNeF7h BF1LZx7ROce4RQwA8mtpGnRmQW3aFMcN1kL07z2IZ8GSRjAvE1lr9VPDjRdPNYltthlGKHOO8 PIc29a5+WBEE+LUVXYq66kqYzn5M2VxFiL7mGqQ3rRnZ1R5w50YpD3/jGgdS0E+eCTwuDJRV3 yQKBqu4UyB8k4EP4aeJHk6FkeUiaBRtjWt/GZ90LOfBCUlU6uNLesNjI3Vjuuav74jNCPOQhK DOdKtw9UpD5a4LS8pdbk4EoIuldFlbJMj1Zv6Ew+5u/pwrQieyqjSvFRJRs6sqvrnb/WnbSoJ XiDsDYvI8Ru/Ubqz83fgvSTy6e2JjALSR920w6C1AHyuer6qYWeG+IeEBBWV7T0AcHnifEHYA is66uWo Archived-At: Cc: Softwires-wg , dhcwg , draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org Subject: Re: [dhcwg] [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 14:44:48 -0000 Hi Jordi, Thanks for that. Will fix in the next update. Regards, Ian > On 28 Feb 2017, at 15:34, JORDI PALET MARTINEZ = wrote: >=20 > By the way =E2=80=A6 >=20 > While working in draft-palet-v6ops-rfc7084-bis-01, I have reviewed all = the documents to be included as CE requirements for different transition = mechanisms, and one of them is RFC7598. >=20 > Then I was looking at your document = draft-fsc-softwire-dhcp4o6-saddr-opt-07 and I was surprised to read that = this document, if approved, will update RFC7568. >=20 > RFC7568 is about SSL 3.0. >=20 > So, my guess is that you meant to update RFC7598? >=20 > Just so the authors can update the XML to avoid this error to go on = ... >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: JORDI PALET MARTINEZ > Fecha: martes, 28 de febrero de 2017, 14:45 > Para: Softwires-wg > CC: dhcwg , = > Asunto: Re: [Softwires] [dhcwg] Adoption call for = draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 >=20 > +1 >=20 > Saludos, > Jordi >=20 >=20 > -----Mensaje original----- > De: Softwires en nombre de tianxiang = li > Responder a: > Fecha: martes, 28 de febrero de 2017, 14:24 > Para: Tomek Mrugalski > CC: Softwires-wg , dhcwg , = > Asunto: Re: [Softwires] [dhcwg] Adoption call for = draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 >=20 > Hi all, > I participated in the review of this draft, I think it is an = important document for the dynamic provisioning of some 4over6 Softwire = mechanisms. I support its adoption. >=20 >=20 > Cheers, > Tianxiang >=20 >=20 > 2017-02-23 1:37 GMT+08:00 Tomek Mrugalski = : >=20 > Hi, >=20 > This message initiates a two weeks long DHC WG adoption call = on: >=20 > Title: DHCPv4 over DHCPv6 Source Address Option > Pages: 9 > Date: 2017-02-01 > Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 > Link: = tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 = >=20 > This document initially started as work intended to be adopted = in > Softwires, but after a discussion with chairs, responsible AD = (Suresh) > and presenting this work in DHC, the conclusion is to aim for = DHC > adoption, not Softwires. Therefore this is a DHC adoption call. >=20 > This message is cross-posted to Softwires to let Softwire = experts weigh > in their opinion. Please be sure to post your comments to DHC = list, > though. Comments sent by end of March 8th, 2017 are much = appreciated. >=20 > Bernie & Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From nobody Tue Feb 28 08:55:55 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245FC12963D for ; Tue, 28 Feb 2017 08:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8I_pTMddGav2 for ; Tue, 28 Feb 2017 08:55:50 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CF012962F for ; Tue, 28 Feb 2017 08:55:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1SGto3N017152; Tue, 28 Feb 2017 09:55:50 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1SGtfXm016687 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 28 Feb 2017 09:55:42 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 28 Feb 2017 08:55:41 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 28 Feb 2017 08:55:41 -0800 From: "Templin, Fred L" To: "Bernie Volz (volz)" , Ralph Droms Thread-Topic: [dhcwg] New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt Thread-Index: AQHSkeN+m1DREdn2RkuklFBIH0ZAjg== Date: Tue, 28 Feb 2017 16:55:40 +0000 Message-ID: References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> <21bd317edc764fc89dc4a13aa541b1c1@XCH15-06-08.nw.nos.boeing.com> <3e5776023c0d447aaccb81dc8ec8724a@XCH-ALN-003.cisco.com> <49129cb6c19c4be3bd483ceb3312bd72@XCH15-06-08.nw.nos.boeing.com> <5109024ddba44de9a3270e58a4c3270a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_b26b403617954e2d82e7e946cda86385XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: dhcwg , Ted Lemon Subject: Re: [dhcwg] New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 16:55:53 -0000 --_000_b26b403617954e2d82e7e946cda86385XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVybmllIGFuZCBSYWxwaCwNCg0KWWVzLCBJIGFtIGludGVyZXN0ZWQgaW4gc2VlaW5nIHRo ZSBSQUFOIHdvcmsgcmVzdW1lLiBCdXQsIGl0IHNob3VsZG7igJl0IGJlIHNlZW4NCmFzIGp1c3Qg bWUgcHVzaGluZyBmb3IgaXQsIGJ1dCByYXRoZXIgdGhhdCBhIG5lZWQgaGFzIGJlZW4gaWRlbnRp ZmllZCB0aGF0IHdvdWxkDQpiZSBpbiB0aGUgYmVzdCBpbnRlcmVzdCBvZiB0aGUgd29ya2luZyBn cm91cCBhcyBhIHdob2xlIHRvIGFkZHJlc3MuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogQmVy bmllIFZvbHogKHZvbHopIFttYWlsdG86dm9sekBjaXNjby5jb21dDQpTZW50OiBNb25kYXksIEZl YnJ1YXJ5IDI3LCAyMDE3IDEyOjM0IFBNDQpUbzogUmFscGggRHJvbXMgPHJkcm9tcy5pZXRmQGdt YWlsLmNvbT4NCkNjOiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+OyBkaGN3ZyA8ZGhjd2dA aWV0Zi5vcmc+OyBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpT dWJqZWN0OiBSRTogW2RoY3dnXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWll dGYtZGhjLXNlZGhjcHY2LTIwLnR4dA0KDQpIaToNCg0KSSB3b3VsZCB0aGluayB3ZSB3b3VsZCBz dGFydCB3aXRoIHRoZSBjdXJyZW50IFJBQU4gZG9jdW1lbnQgKEkgdGhpbmsgd2UgY2FuIGVhc2ls eSBjcmVhdGUgdGhlIFhNTCBmcm9tIHRoZSBUWFQ7IHdvdWxkIGhhdmUgYmVlbiBlYXNpZXIgbm90 IHRvIGhhdmUgdG8gZG8gdGhhdCBpZiBYTUwgd2FzIGF2YWlsYWJsZSkuDQoNCldlIGhhdmVu4oCZ dCBkaXNjdXNzZWQgaXQgc2VyaW91c2x5IGluIHRoZSBXRyB5ZXQsIGFuZCBubyBvbmUgaGFzIHJl cXVlc3RlZCB0aW1lIHRvIGRpc2N1c3MgZnVydGhlciBhdCBJRVRGLTk4IChDaGljYWdvKS4gVGhv dWdoIG9mIGNvdXJzZSB3ZSBjYW4gZG8gaXQgaGVyZSBvbiB0aGUgTUwuDQoNCk15IGhvcGUgd291 bGQgYmUgdGhhdCB3ZSBjYW4gcmVzdGFydCB0aGlzIHdvcmsgcGVyaGFwcyBiZXR3ZWVuIENoaWNh Z28gYW5kIFByYWd1ZSwgYXMgaG9wZWZ1bGx5IHNlREhDUHY2IHdpbGwgZ28gdG8gV0dMQyBzb21l dGltZSBzb29uLiBCdXQgb2YgY291cnNlLCBzZURIQ1B2NiBoYXMgYmVlbiB0aGVyZSBiZWZvcmUg YW5kIGl0IHdhcyBpbiB0aGUgSUVTRyB0aGF0IGl0IHdhcyBib3VuY2VkIGJhY2sgdG8gdGhlIFdH IOKAkyB0aG91Z2ggaG9wZWZ1bGx5IHRoaXJkIHRpbWUgd2lsbCBiZSB0aGUgY2hhcm0/DQoNCldo ZW4gaXQgaXMgdGltZSwgSSB3YXMganVzdCBwbGFubmluZyB0byBkbyB0aGUgY29udmVyc2lvbiBh bmQgcmVzdWJtaXQgaXQgYXMgdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgUkFBTiBkb2N1bWVudCAo cGVyaGFwcyB3aXRoIG1pbm9yIGVkaXRzKS4gSSBndWVzcyB0aG91Z2ggdGhlcmUgaXMgdGhlIHF1 ZXN0aW9uIG9mIHdoZXRoZXIgd2Ugc2hvdWxkIOKAnHJlc3RhcnTigJ0gYXMgYW4gaW5kaXZpZHVh bCBzdWJtaXNzaW9uIG9yIHdoZXRoZXIgdGhlIFdHIGp1c3QgYWdyZWVzIHRvIHJlc3VtZSB3b3Jr IG9uIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyBkb2N1bWVudC4gQW55d2F5LCB3ZSBjYW4gZGViYXRl IHRoYXQgb24gdGhlIGxpc3QgYmVmb3JlIHB1YmxpY2F0aW9uLg0KDQpPZiBjb3Vyc2UsIGFsc28g bmVlZCB0byBhbHNvIGNoZWNrIHdpdGggdGhlIGNvLWF1dGhvcnMgKHlvdSBhbmQgT2xlKSB0byBz ZWUgaG93IGJlc3QgdG8gcHJvY2VlZC4gSSBoYWQgYXNzdW1lZCB5b3UgYm90aCB3b3VsZCBzdGF5 IG9uIOKApg0KDQpBdCBwcmVzZW50LCB0aGUgb25seSBvbmUgcmVhbGx5IHB1c2hpbmcgZm9yIHRo aXMgdG8gc3RhcnQgbm93IGlzIEZyZWQgVC4NCg0KDQotICAgICAgICAgIEJlcm5pZQ0KDQpGcm9t OiBSYWxwaCBEcm9tcyBbbWFpbHRvOnJkcm9tcy5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRh eSwgRmVicnVhcnkgMjcsIDIwMTcgMzoyMiBQTQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9s ekBjaXNjby5jb208bWFpbHRvOnZvbHpAY2lzY28uY29tPj4NCkNjOiBUZWQgTGVtb24gPG1lbGxv bkBmdWd1ZS5jb208bWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20+PjsgZGhjd2cgPGRoY3dnQGlldGYu b3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4+OyDnpZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFk LmpwPG1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcD4+OyBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+Pg0KU3Vi amVjdDogUmU6IFtkaGN3Z10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRm LWRoYy1zZWRoY3B2Ni0yMC50eHQNCg0KQmVybmllIC0gYSBsb25nIHRpbWUgYWdvLCBpZiBJIHJl Y2FsbCBjb3JyZWN0bHksIHlvdSBhc2tlZCBtZSBpZiBJIGhhZCBYTUwgc291cmNlIGZvciB0aGUg ZWFybGllciBSQUFOIGRvY3VtZW50LiAgSSBzZWFyY2hlZCBhcm91bmQsIGJ1dCBjYW4ndCBzZWVt IHRvIGZpbmQgdGhhdCBmaWxlLiAgSXMgdGhlIHRleHQgaW4gdGhhdCBlYXJsaWVyIGRvYyBhdCBh bGwgdXNlZnVsIGZvciB0aGlzIGluc3RhbnRpYXRpb24gb2YgUkFBTj8NCg0KLSBSYWxwaA0KDQpP biBGZWIgMjcsIDIwMTcsIGF0IDM6MTcgUE0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0K DQpIaSBUZWQsDQoNCkp1c3QgZ2V0dGluZyBiYWNrIHRvIHRoaXMgYWZ0ZXIgYmVpbmcgYXdheSBm b3IgdGhlIHBhc3Qgd2VlazoNCg0KPiAgRnJlZCwgSSB0aGluayB3ZSBhbGwgYWdyZWUgdGhhdCB0 aGlzIHByb2JsZW0gbmVlZHMgdG8gYmUgc29sdmVkLg0KDQpJIHN0aWxsIHRoaW5rIGl0IHdvdWxk IGJlIGNsZWFuZXN0IGFuZCBtb3N0IGNvbnNpc3RlbnQgd2l0aCBwYXN0IHdvcmtzIGlmIHRoZSBi YXNlDQpzZWRoY3B2NiBzcGVjaWZpY2F0aW9uIHdlcmUgdG8gaW5jbHVkZSB0aGUgUkFBTiBvcHRp b24gaXRzZWxmLiBCdXQsIGlmIHRoYXQgd291bGQNCm5vdCBiZSBwb3NzaWJsZSBhbmQgaWYgKGFz IHlvdSBzYXkpIHRoZXJlIGlzIGFncmVlbWVudCB0aGF0IHRoaXMgcHJvYmxlbSBuZWVkcw0KdG8g YmUgc29sdmVkLCB0aGVuIHdlIHNob3VsZCBhZG9wdCB0aGUgUkFBTiBkcmFmdCBhcyBhIGRoY3dn IHdvcmtpbmcgZ3JvdXANCml0ZW0gbm93Lg0KDQo+ICBXZSBkb24ndCBhZ3JlZSB0aGF0IHdvcmsg b24gdGhlIHNlY3VyaXR5IGRyYWZ0IG11c3Qgc3RvcCB1bnRpbCB0aGUgcmFhbiBkcmFmdCBpcyBk b25lLg0KDQpJIG5ldmVyIHNhaWQgb3IgbWVhbnQgdG8gaW1wbHkgdGhhdCB0aGUgc2VjdXJpdHkg ZHJhZnQgbXVzdCBzdG9wIHVudGlsIFJBQU4gaXMgZG9uZS4NClRvIHRoZSBjb250cmFyeSwgdGhl IHR3byBkb2N1bWVudHMgY291bGQgcnVuIGluIHBhcmFsbGVsIHdpdGggYm90aCBiZWluZyBkaGN3 ZyBXRw0KaXRlbXMgbm93IGFuZCB3aXRoIG5vIGludGVyZGVwZW5kZW5jaWVzLiBCeSBhZG9wdGlu ZyBSQUFOIGFzIGEgV0cgaXRlbSBub3csDQppbXBsZW1lbnRlcnMgd291bGQgYmUgbW9yZSBsaWtl bHkgdG8gaW1wbGVtZW50IFJBQU4gaW4gcGFyYWxsZWwgd2l0aCBzZWRoY3B2Ng0KcmF0aGVyIHRo YW4gZGVmZXIgaXQgdG8gc29tZSAobXVjaCkgbGF0ZXIgdGltZS4NCg0KPiAgSXQncyBqdXN0IG5v dCB0aGF0IGhhcmQuDQoNCkRlZmluaXRlbHkgYWdyZWUuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJv bTogVGVkIExlbW9uIFttYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBG ZWJydWFyeSAxOCwgMjAxNyA5OjE3IEFNDQpUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4NCkNjOiBk aGN3ZyA8ZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPj47IOelnuaYjumBlOWT iSA8amlubWVpQHdpZGUuYWQuanA8bWFpbHRvOmppbm1laUB3aWRlLmFkLmpwPj47IEJlcm5pZSBW b2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb208bWFpbHRvOnZvbHpAY2lzY28uY29tPj4NClN1Ympl Y3Q6IFJFOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1p ZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQNCg0KRnJlZCwgSSB0aGluayB3ZSBhbGwgYWdyZWUgdGhh dCB0aGlzIHByb2JsZW0gbmVlZHMgdG8gYmUgc29sdmVkLiBXZSBkb24ndCBhZ3JlZSB0aGF0IHdv cmsgb24gdGhlIHNlY3VyaXR5IGRyYWZ0IG11c3Qgc3RvcCB1bnRpbCB0aGUgcmFhbiBkcmFmdCBp cyBkb25lLiBJdCdzIGp1c3Qgbm90IHRoYXQgaGFyZC4NCg0KT24gRmViIDE4LCAyMDE3IDExOjI4 IEFNLCAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSGkgQmVybmllLA0KDQpNeSB1bmRl cnN0YW5kaW5nICBpcyB0aGF0IHNlZGhjcHY2IGlzIGludGVuZGVkIHRvIGJlIGEgcHJvZHVjdCBv ZiB0aGUgSUVURiwNCnNvIEkgdGhlcmVmb3JlIGFzc3VtZSB0aGF0IGl0IGlzIGludGVuZGVkIHRv IGJlIGEgcHJvZHVjdCBvZiBlbmdpbmVlcmluZy4gSXQNCmhhcyBiZWVuIHNob3duIHRoYXQgc2Vk aGNwdjYgaGFzIGFuIG9taXNzaW9uIHRoYXQgd2lsbCBsaW1pdCBpdHMgYXBwbGljYWJpbGl0eSwN CmFuZCB0aGF0IHRoYXQgb21pc3Npb24gY2FuIGJlIHJhdGhlciBlYXNpbHkgcmVtZWRpZWQgcHJp b3IgdG8gcHVibGljYXRpb24uIEl0DQp0aGVyZWZvcmUgbWFrZXMgZ29vZCBlbmdpbmVlcmluZyBz ZW5zZSB0byBmaXggdGhlIG9taXNzaW9uIG5vdy4NCg0KVGhlIHByb3Bvc2FsIGFnYWluIGlzIHRv IGhhdmUgc2VkaGNwdjYgc3BlY2lmeSB0aGUgUkFBTiBvcHRpb24gYXMgcGFydCBvZg0KdGhlIGJh c2UgZG9jdW1lbnQuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogQmVybmllIFZvbHogKHZvbHop IFttYWlsdG86dm9sekBjaXNjby5jb208bWFpbHRvOnZvbHpAY2lzY28uY29tPl0NClNlbnQ6IEZy aWRheSwgRmVicnVhcnkgMTcsIDIwMTcgMzowMCBQTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+ OyBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb208bWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20+Pjvn pZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPG1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcD4+ DQoNCkNjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPj4NClN1 YmplY3Q6IFJFOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQNCg0KSSB0aGluayB0aGUgcGxhbiBoZXJlIG1ha2Vz IHNvbWUgc2Vuc2Ug4oCmIHNlREhDUHY2IGhhcyBoYWQgc2V2ZXJhbCBhdHRlbXB0cyBhbmQgYmVl biBraWNrZWQgYmFjayB0byB0aGUgV0cuIFNvLCBJIHRoaW5rIHRoZSBXRyB3YW50cyB0byBnbyBz bG93bHkgYW5kIG5vdCBkZXZlbG9wIGEgc29sdXRpb24gdW50aWwgc2VESENQdjYgaXMgbGlrZWx5 IHRvIGFkdmFuY2UgaW4gdGhlIElFU0cgKGVuY3J5cHRpb24gd2FzIG9ubHkgYWRkZWQgZmFpcmx5 IOKAnHJlY2VudGx54oCdKS4NCg0KQW5kLCBpdCBpc27igJl0IGxpa2UgdGhlIGRheSBhZnRlciBz ZURIQ1B2NiBpcyDigJxhcHByb3ZlZOKAnSB0aGF0IGV2ZXJ5IGNsaWVudCAoYW5kIHNlcnZlcikg d2lsbCBzdXBwb3J0IHRoaXMuIEl0IHdpbGwgdGFrZSB0aW1lIHRvIHJvbGwgb3V0LiBBbmQsIGhv cGVmdWxseSB3ZSBjYW4gZ2V0IHRoZSBSQUFOIHdvcmsgb3V0IGluIGEgZmFpcmx5IHNob3J0IHRp bWUuDQoNCkluIHlvdXIgbmV0d29ya3MsIGlmIHlvdSBjYW7igJl0IHN1cHBvcnQgc2VESENQdjYg dW50aWwgeW91IGhhdmUgc29tZXRoaW5nIHRvIHNvIHNvbHZlIHRoZSBSQUFOIGlzc3VlcywgeW91 IG9idmlvdXNseSBjYW7igJl0IGRlcGxveSBzZURIQ1B2Ni4gQnV0IHRoZXJlIG1heSBiZSBwbGVu dHkgb2Ygb3RoZXIgbmV0d29ya3Mgd2hlcmUgdGhpcyBpc27igJl0IGFuIGlzc3VlIGFuZCBpdCBj b3VsZCBzdGFydCB0byBiZSBkZXBsb3llZCAoY29mZmVlIHNob3BzIGFuZCBlbnRlcnByaXNlcyku DQoNCg0KLSAgICAgICAgICBCZXJuaWUNCg0KRnJvbTogVGVtcGxpbiwgRnJlZCBMIFttYWlsdG86 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbV0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTcsIDIw MTcgNTozNSBQTQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb208bWFpbHRv OnZvbHpAY2lzY28uY29tPj47IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86bWVs bG9uQGZ1Z3VlLmNvbT4+OyDnpZ7mmI7pgZTlk4k8amlubWVpQHdpZGUuYWQuanA8bWFpbHRvOmpp bm1laUB3aWRlLmFkLmpwPj4NCkNjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dn QGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQNCg0KQmVybmllLA0KDQpU aGUgZGlzY3Vzc2lvbiBncmF2aXRhdGVkIHRvd2FyZHMgbm90IHJlc3VycmVjdGluZyB1bnRpbCB0 aGUgc2VkaGNwdjYNCkktRCBwcm9ncmVzc2VzIGZ1cnRoZXIuIFdlIHdpbGwgcmVldmFsdWF0ZSB0 aGlzIG9uY2Ugc2VkaGNwdjYgaXMgZG9uZS4NCg0KVGhpcyBkb2VzIG5vdCBtYWtlIHNlbnNlIHRv IG1lOyBzZWRoY3B2NiBpcyB0aGUgdmVyeSByZWFzb24gdGhhdCBSQUFOIGlzIGltcG9ydGFudC4N Ckp1c3QgbGlrZSBSRkMzOTcxIGRpZCB3aXRoIElQdjYgTkQgVGltZXN0YW1wIGFuZCBOb25jZSBv cHRpb25zLCBzZWRoY3B2NiBjb3VsZA0KZGVmaW5lIHRoZSBSQUFOIG9wZXJhdGlvbiBhbmQgaGF2 ZSBldmVyeXRoaW5nIG92ZXIgYW5kIGRvbmUgd2l0aCBpbiBvbmUgcGFzcy4NCkFuZCwgSSBoYXZl IGFscmVhZHkgaWRlbnRpZmllZCBhIHVzZSBjYXNlIHdoZXJlIFJBQU4gaXMgYWJzb2x1dGVseSBu ZWNlc3NhcnkuDQpBbHNvLCBJIHdhcyB1bmFibGUgdG8gYXR0ZW5kICBJRVRGOTcsIHdoZXJlIEkg Y2VydGFpbmx5IHdvdWxkIGhhdmUgc3Rvb2QgdXAgYW5kDQp2b2ljZWQgbXkgcG9zaXRpb24uDQoN ClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQmVybmllIFZvbHogKHZvbHopDQpTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgMTYsIDIwMTcgMjozOSBQTQ0KVG86IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxt YWlsdG86bWVsbG9uQGZ1Z3VlLmNvbT4+OyDnpZ7mmI7pgZTlk4kgPGppbm1laUB3aWRlLmFkLmpw PG1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcD4+DQpDYzogZGhjd2cgPGRoY3dnQGlldGYub3JnPG1h aWx0bzpkaGN3Z0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0DQoNCkkg cHJlc2VudGVkIGFib3V0IHJlc3VycmVjdGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtYWdlbnRv cHQtZGVsZWdhdGUgYXQgSUVURi05NyAoc2VlaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvOTcvc2xpZGVzL3NsaWRlcy05Ny1kaGMtcmVzdXJyZWN0LWRyYWZ0LWlldGYtZGhjLWRoY3B2 Ni1hZ2VudG9wdC1kZWxlZ2F0ZS0wMC5wZGYpLg0KDQpBbmQgdGhlIGNvbmNsdXNpb24gdGhlbiB3 YXMgKHNlZSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9taW51dGVzL21pbnV0 ZXMtOTctZGhjLTAwLnR4dCk6DQoNClRoZSBkaXNjdXNzaW9uIGdyYXZpdGF0ZWQgdG93YXJkcyBu b3QgcmVzdXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2Ng0KSS1EIHByb2dyZXNzZXMgZnVydGhl ci4gV2Ugd2lsbCByZWV2YWx1YXRlIHRoaXMgb25jZSBzZWRoY3B2NiBpcyBkb25lLg0KDQoNCi0g ICAgICAgICAgQmVybmllDQoNCkZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAx NSwgMjAxNyAxOjQ5IFBNDQpUbzog56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcDxtYWls dG86amlubWVpQHdpZGUuYWQuanA+Pg0KQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZzxtYWlsdG86 ZGhjd2dAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtkaGN3Z10gRndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dA0KDQpPbiBGZWIg MTUsIDIwMTcsIGF0IDE6MzIgUE0sIOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUuYWQuanA8bWFp bHRvOmppbm1laUB3aWRlLmFkLmpwPj4gd3JvdGU6DQpJIHBlcnNvbmFsbHkgZG9uJ3QgdGhpbmsg aXQgYSBibG9ja2luZyBpc3N1ZSBmb3Igc2VkaGNwdjYsIGJ1dCwgb2YNCmNvdXJzZSwgdGhlIHdn IHNob3VsZCBkZWNpZGUgaXQuDQoNCkl0IGRlZmluaXRlbHkgaXNuJ3QgYSBibG9ja2luZyBpc3N1 ZSwgYnV0IEZyZWQgaXMgcmlnaHQgdGhhdCBpZiB3ZSBhcmUgZ29pbmcgYWhlYWQgd2l0aCBlbmNy eXB0aW9uLW9ubHksIHdoaWNoIEkgYWdyZWUgaXMgdGhlIHJpZ2h0IG1vdmUsIHdlIG5lZWQgdG8g ZG8gdGhpcyB3b3JrIGFzIHdlbGwuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCmRoY3dnIG1haWxpbmcgbGlzdA0KZGhjd2dAaWV0Zi5vcmc8bWFp bHRvOmRoY3dnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kaGN3Zw0KDQo= --_000_b26b403617954e2d82e7e946cda86385XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAx MSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXI7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJ cGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tNzY5 MDM3NjU5NDEzODExMTk1M21zb2xpc3RwYXJhZ3JhcGgsIGxpLm03NjkwMzc2NTk0MTM4MTExOTUz bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm03NjkwMzc2NTk0MTM4MTExOTUzbXNvbGlzdHBhcmFncmFw aA0KCXttc28tc3R5bGUtbmFtZTptNzY5MDM3NjU5NDEzODExMTk1M21zb2xpc3RwYXJhZ3JhcGg7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLWNv bnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQxOTQ0Njg4Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5ODc5NDU2IC0yOTUy ODg3NzAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFy dC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEJlcm5pZSBhbmQgUmFscGgs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZZXMsIEkgYW0gaW50 ZXJlc3RlZCBpbiBzZWVpbmcgdGhlIFJBQU4gd29yayByZXN1bWUuIEJ1dCwgaXQgc2hvdWxkbuKA mXQgYmUgc2VlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hcyBqdXN0IG1lIHB1c2hpbmcgZm9yIGl0LCBi dXQgcmF0aGVyIHRoYXQgYSBuZWVkIGhhcyBiZWVuIGlkZW50aWZpZWQgdGhhdCB3b3VsZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5iZSBpbiB0aGUgYmVzdCBpbnRlcmVzdCBvZiB0aGUgd29ya2luZyBncm91 cCBhcyBhIHdob2xlIHRvIGFkZHJlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmVybmllIFZvbHogKHZvbHopIFtt YWlsdG86dm9sekBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFy eSAyNywgMjAxNyAxMjozNCBQTTxicj4NCjxiPlRvOjwvYj4gUmFscGggRHJvbXMgJmx0O3Jkcm9t cy5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFRlZCBMZW1vbiAmbHQ7bWVsbG9u QGZ1Z3VlLmNvbSZndDs7IGRoY3dnICZsdDtkaGN3Z0BpZXRmLm9yZyZndDs7IFRlbXBsaW4sIEZy ZWQgTCAmbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFtkaGN3Z10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRo Yy1zZWRoY3B2Ni0yMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGk6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHdvdWxkIHRoaW5rIHdlIHdvdWxkIHN0YXJ0 IHdpdGggdGhlIGN1cnJlbnQgUkFBTiBkb2N1bWVudCAoSSB0aGluayB3ZSBjYW4gZWFzaWx5IGNy ZWF0ZSB0aGUgWE1MIGZyb20gdGhlIFRYVDsgd291bGQgaGF2ZSBiZWVuIGVhc2llciBub3QgdG8g aGF2ZSB0byBkbyB0aGF0DQogaWYgWE1MIHdhcyBhdmFpbGFibGUpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZW7igJl0IGRpc2N1c3NlZCBpdCBzZXJp b3VzbHkgaW4gdGhlIFdHIHlldCwgYW5kIG5vIG9uZSBoYXMgcmVxdWVzdGVkIHRpbWUgdG8gZGlz Y3VzcyBmdXJ0aGVyIGF0IElFVEYtOTggKENoaWNhZ28pLiBUaG91Z2ggb2YgY291cnNlIHdlIGNh biBkbyBpdCBoZXJlIG9uDQogdGhlIE1MLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+TXkgaG9wZSB3b3VsZCBiZSB0aGF0IHdlIGNhbiByZXN0YXJ0IHRoaXMgd29y ayBwZXJoYXBzIGJldHdlZW4gQ2hpY2FnbyBhbmQgUHJhZ3VlLCBhcyBob3BlZnVsbHkgc2VESENQ djYgd2lsbCBnbyB0byBXR0xDIHNvbWV0aW1lIHNvb24uIEJ1dCBvZiBjb3Vyc2UsIHNlREhDUHY2 DQogaGFzIGJlZW4gdGhlcmUgYmVmb3JlIGFuZCBpdCB3YXMgaW4gdGhlIElFU0cgdGhhdCBpdCB3 YXMgYm91bmNlZCBiYWNrIHRvIHRoZSBXRyDigJMgdGhvdWdoIGhvcGVmdWxseSB0aGlyZCB0aW1l IHdpbGwgYmUgdGhlIGNoYXJtPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+V2hlbiBpdCBpcyB0aW1lLCBJIHdhcyBqdXN0IHBsYW5uaW5nIHRvIGRvIHRoZSBjb252 ZXJzaW9uIGFuZCByZXN1Ym1pdCBpdCBhcyB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBSQUFOIGRv Y3VtZW50IChwZXJoYXBzIHdpdGggbWlub3IgZWRpdHMpLiBJIGd1ZXNzIHRob3VnaA0KIHRoZXJl IGlzIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHdlIHNob3VsZCDigJxyZXN0YXJ04oCdIGFzIGFu IGluZGl2aWR1YWwgc3VibWlzc2lvbiBvciB3aGV0aGVyIHRoZSBXRyBqdXN0IGFncmVlcyB0byBy ZXN1bWUgd29yayBvbiB0aGlzIGRvY3VtZW50IGFzIGEgV0cgZG9jdW1lbnQuIEFueXdheSwgd2Ug Y2FuIGRlYmF0ZSB0aGF0IG9uIHRoZSBsaXN0IGJlZm9yZSBwdWJsaWNhdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9mIGNvdXJzZSwgYWxzbyBuZWVkIHRv IGFsc28gY2hlY2sgd2l0aCB0aGUgY28tYXV0aG9ycyAoeW91IGFuZCBPbGUpIHRvIHNlZSBob3cg YmVzdCB0byBwcm9jZWVkLiBJIGhhZCBhc3N1bWVkIHlvdSBib3RoIHdvdWxkIHN0YXkgb24g4oCm PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BdCBwcmVzZW50LCB0 aGUgb25seSBvbmUgcmVhbGx5IHB1c2hpbmcgZm9yIHRoaXMgdG8gc3RhcnQgbm93IGlzIEZyZWQg VC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVybmllPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSYWxwaCBEcm9tcyBbPGEgaHJlZj0i bWFpbHRvOnJkcm9tcy5pZXRmQGdtYWlsLmNvbSI+bWFpbHRvOnJkcm9tcy5pZXRmQGdtYWlsLmNv bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSAyNywgMjAxNyAzOjIy IFBNPGJyPg0KPGI+VG86PC9iPiBCZXJuaWUgVm9seiAodm9seikgJmx0OzxhIGhyZWY9Im1haWx0 bzp2b2x6QGNpc2NvLmNvbSI+dm9sekBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g VGVkIExlbW9uICZsdDs8YSBocmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbSI+bWVsbG9uQGZ1 Z3VlLmNvbTwvYT4mZ3Q7OyBkaGN3ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3Jn Ij5kaGN3Z0BpZXRmLm9yZzwvYT4mZ3Q7Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+56We5piO6YGU5ZOJPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+ICZsdDs8YSBocmVmPSJtYWlsdG86amlubWVpQHdpZGUuYWQu anAiPmppbm1laUB3aWRlLmFkLmpwPC9hPiZndDs7IFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iPkZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RoY3dnXSBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIwLnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlcm5pZSAtIGEgbG9uZyB0 aW1lIGFnbywgaWYgSSByZWNhbGwgY29ycmVjdGx5LCB5b3UgYXNrZWQgbWUgaWYgSSBoYWQgWE1M IHNvdXJjZSBmb3IgdGhlIGVhcmxpZXIgUkFBTiBkb2N1bWVudC4gJm5ic3A7SSBzZWFyY2hlZCBh cm91bmQsIGJ1dCBjYW4ndCBzZWVtIHRvIGZpbmQgdGhhdCBmaWxlLiAmbmJzcDtJcyB0aGUgdGV4 dCBpbiB0aGF0IGVhcmxpZXIgZG9jIGF0IGFsbCB1c2VmdWwgZm9yIHRoaXMgaW5zdGFudGlhdGlv bg0KIG9mIFJBQU4/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tIFJhbHBoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBGZWIgMjcsIDIwMTcsIGF0IDM6MTcgUE0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iPkZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBUZWQsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5KdXN0IGdldHRpbmcgYmFjayB0byB0aGlzIGFmdGVyIGJlaW5nIGF3YXkg Zm9yIHRoZSBwYXN0IHdlZWs6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6 IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPkZyZWQsIEkgdGhpbmsgd2UgYWxsIGFncmVlIHRoYXQgdGhpcyBwcm9ibGVtDQog bmVlZHMgdG8gYmUgc29sdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHN0aWxsIHRoaW5rIGl0IHdvdWxkIGJlIGNs ZWFuZXN0IGFuZCBtb3N0IGNvbnNpc3RlbnQgd2l0aCBwYXN0IHdvcmtzIGlmIHRoZSBiYXNlPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnNlZGhjcHY2IHNwZWNpZmljYXRpb24gd2Vy ZSB0byBpbmNsdWRlIHRoZSBSQUFOIG9wdGlvbiBpdHNlbGYuIEJ1dCwgaWYgdGhhdCB3b3VsZDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ub3QgYmUgcG9zc2libGUgYW5kIGlmIChh cyB5b3Ugc2F5KSB0aGVyZSBpcyBhZ3JlZW1lbnQgdGhhdCB0aGlzIHByb2JsZW0gbmVlZHM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dG8gYmUgc29sdmVkLCB0aGVuIHdlIHNob3Vs ZCBhZG9wdCB0aGUgUkFBTiBkcmFmdCBhcyBhIGRoY3dnIHdvcmtpbmcgZ3JvdXA8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aXRlbSBub3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPldlIGRvbid0IGFncmVlIHRoYXQgd29yayBvbiB0aGUg c2VjdXJpdHkNCiBkcmFmdCBtdXN0IHN0b3AgdW50aWwgdGhlIHJhYW4gZHJhZnQgaXMgZG9uZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SSBuZXZlciBzYWlkIG9yIG1lYW50IHRvIGltcGx5IHRoYXQgdGhlIHNlY3VyaXR5 IGRyYWZ0IG11c3Qgc3RvcCB1bnRpbCBSQUFOIGlzIGRvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRvIHRoZSBjb250cmFyeSwgdGhlIHR3byBkb2N1bWVudHMgY291bGQgcnVu IGluIHBhcmFsbGVsIHdpdGggYm90aCBiZWluZyBkaGN3ZyBXRzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5pdGVtcyBub3cgYW5kIHdpdGggbm8gaW50ZXJkZXBlbmRlbmNpZXMuIEJ5 IGFkb3B0aW5nIFJBQU4gYXMgYSBXRyBpdGVtIG5vdyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+aW1wbGVtZW50ZXJzIHdvdWxkIGJlIG1vcmUgbGlrZWx5IHRvIGltcGxlbWVudCBS QUFOIGluIHBhcmFsbGVsIHdpdGggc2VkaGNwdjY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+cmF0aGVyIHRoYW4gZGVmZXIgaXQgdG8gc29tZSAobXVjaCkgbGF0ZXIgdGltZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+SXQncyBqdXN0IG5v dCB0aGF0IGhhcmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRlZmluaXRlbHkgYWdyZWUuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U aGFua3MgLSBGcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+VGVkDQogTGVtb24gWzxhIGhyZWY9Im1haWx0bzptZWxsb25AZnVndWUuY29t Ij5tYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbTwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TYXR1cmRheSwgRmVicnVhcnkgMTgsIDIw MTcgOToxNyBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+VGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5kaGN3ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5kaGN3Z0Bp ZXRmLm9yZzwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmx0OzxhIGhyZWY9Im1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcCI+ amlubWVpQHdpZGUuYWQuanA8L2E+Jmd0OzsNCiBCZXJuaWUgVm9seiAodm9seikgJmx0OzxhIGhy ZWY9Im1haWx0bzp2b2x6QGNpc2NvLmNvbSI+dm9sekBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5SRTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyZWQs IEkgdGhpbmsgd2UgYWxsIGFncmVlIHRoYXQgdGhpcyBwcm9ibGVtIG5lZWRzIHRvIGJlIHNvbHZl ZC4gV2UgZG9uJ3QgYWdyZWUgdGhhdCB3b3JrIG9uIHRoZSBzZWN1cml0eSBkcmFmdCBtdXN0IHN0 b3AgdW50aWwgdGhlIHJhYW4gZHJhZnQgaXMgZG9uZS4gSXQncyBqdXN0IG5vdCB0aGF0IGhhcmQu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMTgsIDIwMTcgMTE6MjggQU0sICZxdW90 O1RlbXBsaW4sIEZyZWQgTCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkhpIEJlcm5pZSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk15IHVuZGVyc3RhbmRpbmcgJm5ic3A7 aXMgdGhhdCBzZWRoY3B2NiBpcyBpbnRlbmRlZCB0byBiZSBhIHByb2R1Y3Qgb2YgdGhlIElFVEYs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnNvIEkgdGhlcmVmb3JlIGFzc3VtZSB0 aGF0IGl0IGlzIGludGVuZGVkIHRvIGJlIGEgcHJvZHVjdCBvZiBlbmdpbmVlcmluZy4gSXQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aGFzIGJlZW4gc2hvd24gdGhhdCBzZWRoY3B2 NiBoYXMgYW4gb21pc3Npb24gdGhhdCB3aWxsIGxpbWl0IGl0cyBhcHBsaWNhYmlsaXR5LDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hbmQgdGhhdCB0aGF0IG9taXNzaW9uIGNhbiBi ZSByYXRoZXIgZWFzaWx5IHJlbWVkaWVkIHByaW9yIHRvIHB1YmxpY2F0aW9uLiBJdDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGVyZWZvcmUgbWFrZXMgZ29vZCBlbmdpbmVlcmlu ZyBzZW5zZSB0byBmaXggdGhlIG9taXNzaW9uIG5vdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm9w b3NhbCBhZ2FpbiBpcyB0byBoYXZlIHNlZGhjcHY2IHNwZWNpZnkgdGhlIFJBQU4gb3B0aW9uIGFz IHBhcnQgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlIGJhc2UgZG9jdW1l bnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QmVybmllDQogVm9seiAodm9seikgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86dm9sekBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj52b2x6QGNpc2NvLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50Ojwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5 LCBGZWJydWFyeSAxNywgMjAxNyAzOjAwIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UZW1wbGluLCBGcmVkIEwgJmx0Ozxh IGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvc3Bh bj48L2E+Jmd0OzsgVGVkIExlbW9uICZsdDs8YSBocmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1lbGxvbkBmdWd1 ZS5jb208L3NwYW4+PC9hPiZndDs7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+56We5piO6YGU5ZOJPC9zcGFuPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDs8YSBocmVmPSJtYWlsdG86amlubWVp QHdpZGUuYWQuanAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5q aW5tZWlAd2lkZS5hZC5qcDwvc3Bhbj48L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pjxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+ZGhjd2cgJmx0OzxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRoY3dnQGlldGYub3JnPC9zcGFu PjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJFOiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50eHQ8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGlu ayB0aGUgcGxhbiBoZXJlIG1ha2VzIHNvbWUgc2Vuc2Ug4oCmIHNlREhDUHY2IGhhcyBoYWQgc2V2 ZXJhbCBhdHRlbXB0cyBhbmQgYmVlbiBraWNrZWQgYmFjayB0byB0aGUgV0cuIFNvLCBJIHRoaW5r IHRoZSBXRyB3YW50cyB0byBnbyBzbG93bHkgYW5kIG5vdCBkZXZlbG9wDQogYSBzb2x1dGlvbiB1 bnRpbCBzZURIQ1B2NiBpcyBsaWtlbHkgdG8gYWR2YW5jZSBpbiB0aGUgSUVTRyAoZW5jcnlwdGlv biB3YXMgb25seSBhZGRlZCBmYWlybHkg4oCccmVjZW50bHnigJ0pLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ QW5kLCBpdCBpc27igJl0IGxpa2UgdGhlIGRheSBhZnRlciBzZURIQ1B2NiBpcyDigJxhcHByb3Zl ZOKAnSB0aGF0IGV2ZXJ5IGNsaWVudCAoYW5kIHNlcnZlcikgd2lsbCBzdXBwb3J0IHRoaXMuIEl0 IHdpbGwgdGFrZSB0aW1lIHRvIHJvbGwgb3V0LiBBbmQsIGhvcGVmdWxseSB3ZSBjYW4NCiBnZXQg dGhlIFJBQU4gd29yayBvdXQgaW4gYSBmYWlybHkgc2hvcnQgdGltZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkluIHlvdXIgbmV0d29ya3MsIGlmIHlvdSBjYW7igJl0IHN1cHBvcnQgc2VESENQdjYgdW50aWwg eW91IGhhdmUgc29tZXRoaW5nIHRvIHNvIHNvbHZlIHRoZSBSQUFOIGlzc3VlcywgeW91IG9idmlv dXNseSBjYW7igJl0IGRlcGxveSBzZURIQ1B2Ni4gQnV0IHRoZXJlIG1heSBiZSBwbGVudHkNCiBv ZiBvdGhlciBuZXR3b3JrcyB3aGVyZSB0aGlzIGlzbuKAmXQgYW4gaXNzdWUgYW5kIGl0IGNvdWxk IHN0YXJ0IHRvIGJlIGRlcGxveWVkIChjb2ZmZWUgc2hvcHMgYW5kIGVudGVycHJpc2VzKS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0ibTc2OTAzNzY1OTQxMzgxMTE5NTNtc29saXN0cGFyYWdyYXBo Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJl cm5pZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRlbXBsaW4sDQogRnJlZCBMIFs8YSBocmVmPSJt YWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9zcGFu PjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5GcmlkYXksIEZlYnJ1YXJ5IDE3LCAyMDE3IDU6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkJlcm5pZSBW b2x6ICh2b2x6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZvbHpAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dm9sekBjaXNjby5jb208L3NwYW4+PC9h PiZndDs7IFRlZCBMZW1vbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tZWxsb25AZnVndWUuY29t PC9zcGFuPjwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1laUB3aWRlLmFkLmpwIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+amlubWVpQHdpZGUuYWQuanA8L3NwYW4+PC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPmRoY3dnICZsdDs8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5kaGN3Z0BpZXRmLm9yZzwvc3Bh bj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTogW2RoY3dnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMjAudHh0PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5pZSw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBkaXNjdXNzaW9uIGdy YXZpdGF0ZWQgdG93YXJkcyBub3QgcmVzdXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2Njwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5JLUQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVhdGUgdGhpcyBv bmNlIHNlZGhjcHY2IGlzIGRvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGRvZXMgbm90IG1ha2Ug c2Vuc2UgdG8gbWU7IHNlZGhjcHY2IGlzIHRoZSB2ZXJ5IHJlYXNvbiB0aGF0IFJBQU4gaXMgaW1w b3J0YW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KdXN0IGxpa2UgUkZDMzk3 MSBkaWQgd2l0aCBJUHY2IE5EIFRpbWVzdGFtcCBhbmQgTm9uY2Ugb3B0aW9ucywgc2VkaGNwdjYg Y291bGQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZGVmaW5lIHRoZSBSQUFOIG9w ZXJhdGlvbiBhbmQgaGF2ZSBldmVyeXRoaW5nIG92ZXIgYW5kIGRvbmUgd2l0aCBpbiBvbmUgcGFz cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kLCBJIGhhdmUgYWxyZWFkeSBp ZGVudGlmaWVkIGEgdXNlIGNhc2Ugd2hlcmUgUkFBTiBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWxzbywgSSB3YXMgdW5hYmxlIHRvIGF0 dGVuZCAmbmJzcDtJRVRGOTcsIHdoZXJlIEkgY2VydGFpbmx5IHdvdWxkIGhhdmUgc3Rvb2QgdXAg YW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnZvaWNlZCBteSBwb3NpdGlvbi48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5kaGN3Zw0KIFs8YSBocmVmPSJtYWlsdG86ZGhj d2ctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPm1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+QmVybmll IFZvbHogKHZvbHopPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyAyOjM5IFBN PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5UZWQgTGVtb24gJmx0OzxhIGhyZWY9Im1haWx0bzptZWxsb25AZnVndWUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWVsbG9uQGZ1Z3VlLmNv bTwvc3Bhbj48L2E+Jmd0Ozs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O01TIEdvdGhpYyZxdW90OyI+56We5piO6YGU5ZOJPC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDs8YSBocmVmPSJtYWlsdG86amlubWVpQHdpZGUuYWQuanAi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qaW5tZWlAd2lkZS5h ZC5qcDwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZGhjd2cgJmx0OzxhIGhyZWY9Im1haWx0bzpkaGN3 Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmRo Y3dnQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbZGhjd2ddIEZ3ZDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMC50 eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBw cmVzZW50ZWQgYWJvdXQgcmVzdXJyZWN0aW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1hZ2VudG9w dC1kZWxlZ2F0ZSBhdCBJRVRGLTk3IChzZWU8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LWRoYy1yZXN1cnJlY3QtZHJhZnQtaWV0Zi1k aGMtZGhjcHY2LWFnZW50b3B0LWRlbGVnYXRlLTAwLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3 L3NsaWRlcy9zbGlkZXMtOTctZGhjLXJlc3VycmVjdC1kcmFmdC1pZXRmLWRoYy1kaGNwdjYtYWdl bnRvcHQtZGVsZWdhdGUtMDAucGRmPC9zcGFuPjwvYT4pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kIHRo ZSBjb25jbHVzaW9uIHRoZW4gd2FzIChzZWU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvOTcvbWludXRlcy9taW51dGVzLTk3LWRoYy0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 Ny9taW51dGVzL21pbnV0ZXMtOTctZGhjLTAwLnR4dDwvc3Bhbj48L2E+KTo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBkaXNjdXNzaW9uIGdy YXZpdGF0ZWQgdG93YXJkcyBub3QgcmVzdXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2Njwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5JLUQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBXZSB3aWxsIHJlZXZhbHVhdGUgdGhpcyBv bmNlIHNlZGhjcHY2IGlzIGRvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Im03NjkwMzc2NTk0 MTM4MTExOTUzbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXJuaWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5kaGN3 Zw0KIFs8YSBocmVmPSJtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYu b3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L2I+VGVkIExlbW9uPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgRmVicnVhcnkg MTUsIDIwMTcgMTo0OSBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+56We5piO6YGU5ZOJPC9zcGFu PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDs8YSBocmVmPSJtYWlsdG86amlu bWVpQHdpZGUuYWQuanAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5qaW5tZWlAd2lkZS5hZC5qcDwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZGhjd2cgJmx0OzxhIGhy ZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmRoY3dnQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJl OiBbZGhjd2ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRo Yy1zZWRoY3B2Ni0yMC50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgMTUsIDIwMTcsIGF0 IDE6MzIgUE0sPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuelnuaYjumB lOWTiTwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+Jmx0OzxhIGhyZWY9Im1haWx0bzpqaW5tZWlAd2lkZS5hZC5qcCIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmppbm1laUB3aWRlLmFkLmpwPC9zcGFuPjwvYT4m Z3Q7DQogd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+SSBwZXJzb25hbGx5IGRv bid0IHRoaW5rIGl0IGEgYmxvY2tpbmcgaXNzdWUgZm9yIHNlZGhjcHY2LCBidXQsIG9mPGJyPg0K Y291cnNlLCB0aGUgd2cgc2hvdWxkIGRlY2lkZSBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SXQgZGVmaW5pdGVseSBpc24ndCBhIGJsb2NraW5nIGlzc3VlLCBi dXQgRnJlZCBpcyByaWdodCB0aGF0IGlmIHdlIGFyZSBnb2luZyBhaGVhZCB3aXRoIGVuY3J5cHRp b24tb25seSwgd2hpY2ggSSBhZ3JlZSBpcyB0aGUgcmlnaHQgbW92ZSwgd2UgbmVlZCB0byBkbyB0 aGlzIHdvcmsgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxh ciZxdW90OyxzZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpkaGN3ZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGhjd2dA aWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2ciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGhjd2c8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_b26b403617954e2d82e7e946cda86385XCH150608nwnosboeingcom_-- From nobody Tue Feb 28 11:33:29 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C045D129698 for ; Tue, 28 Feb 2017 11:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jzSpyMoSvDpl for ; Tue, 28 Feb 2017 11:33:25 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109F7120724 for ; Tue, 28 Feb 2017 11:33:25 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id s186so34788045qkb.1 for ; Tue, 28 Feb 2017 11:33:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=spkMbut7Zz6GjjE6EdChR1IBlmT3Ww38JsZ1cUMegJA=; b=Illk/nW6A4yENreJqVEvQZBagyvhPOiM8XNeibhRROFoqFvQBmW2UAWKpraXL4fomy 4kyVWZHsvrsiiLnLMCXOn/d+7kwCJlclSmV0D9UmKFwlaavLJZwDxBQl7nUSyZdNrCQq /qjMjp9A+JdaBGYeJdaHQugUs3705Kko4W2mY7Ef0pnEQhukLeMQJSl/MAHfshVOfLXa fB/X+jpSBXyjRLOw1qetCYMv7GOTjP3gt/TdY5HVA1MzBbJfbO68dlLwMKXL75+1Sz9v rKX6WjWxwA+0Oo0ctAjRWM8B+Fsaf1wtKaWQUUvZSTSk5ZngKdygEX9hiiQEZtFG1Atx osUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=spkMbut7Zz6GjjE6EdChR1IBlmT3Ww38JsZ1cUMegJA=; b=qa1Bm/L2fex9jJ9p9Y3UA47UbxFk3pNpjWw1POykoXUoamyA8+5lre9/JFNBy6cnrE OrolKa9zk6Q++dOJRX7Vv62Akw84NyXdME+Pg+i9jdoYhb3aWEGL6yt6H8KM1F1d3dxj C2ytj2tpzvqAJaTYMNFIvpc12b62NxRj+M7w3hn1oOj2wX/0ZEzAV2CrEGnTasQg/tIl 8QqjVVBS6DB0fNYq93cN7SKHSVz9bBOJc9DUnFFIk7ZWucu3BAHZFSXA364cye2m6oxR +M+n6I7EwUAPrHPdqTYe11iuXqoV//nj7lo8LSP1k5lSF4aoBpgzm1cPXGkMpVFlp9eq Y5kg== X-Gm-Message-State: AMke39nODWP0CXrLfaD0vNwkjOPhp7a9CY0KoZP3nEaj8cutcbgzo9XFsqBq9iJ7A7SnKA== X-Received: by 10.200.58.167 with SMTP id x36mr5011299qte.217.1488310404057; Tue, 28 Feb 2017 11:33:24 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:4d44:3b4e:b9f9:f6a4? ([2601:18f:801:600:4d44:3b4e:b9f9:f6a4]) by smtp.gmail.com with ESMTPSA id f35sm1593431qtb.49.2017.02.28.11.33.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Feb 2017 11:33:23 -0800 (PST) From: Ralph Droms Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_79BEE41A-1267-495B-B54C-7290C98D2697" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 28 Feb 2017 14:33:21 -0500 In-Reply-To: To: "Bernie Volz (volz)" References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <9d9d50b20005459aafffcd8f64bfb281@XCH-ALN-003.cisco.com> <21bd317edc764fc89dc4a13aa541b1c1@XCH15-06-08.nw.nos.boeing.com> <3e5776023c0d447aaccb81dc8ec8724a@XCH-ALN-003.cisco.com> <49129cb6c19c4be3bd483ceb3312bd72@XCH15-06-08.nw.nos.boeing.com> <5109024ddba44de9a3270e58a4c3270a@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dhcwg , Ted Lemon Subject: Re: [dhcwg] New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 19:33:27 -0000 --Apple-Mail=_79BEE41A-1267-495B-B54C-7290C98D2697 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Bernie - thanks for the status update on doc WG interest in RAAN. Converting the existing document to XML is probably a good place to = start. A discussion on the list about restarting as an individual = document or picking back up again as a WG document would likely also = give you a sense of who might be interested in seeing the standard = developed and published. I don't have a sense of the intersection of = deployments of seDHCP with really agent snooping, so I don't have a good = way to judge potential interest. I'll be happy to stay on as a co-author. - Ralph > On Feb 27, 2017, at 3:33 PM, Bernie Volz (volz) = wrote: >=20 > Hi: > =20 > I would think we would start with the current RAAN document (I think = we can easily create the XML from the TXT; would have been easier not to = have to do that if XML was available). > =20 > We haven=E2=80=99t discussed it seriously in the WG yet, and no one = has requested time to discuss further at IETF-98 (Chicago). Though of = course we can do it here on the ML. > =20 > My hope would be that we can restart this work perhaps between Chicago = and Prague, as hopefully seDHCPv6 will go to WGLC sometime soon. But of = course, seDHCPv6 has been there before and it was in the IESG that it = was bounced back to the WG =E2=80=93 though hopefully third time will be = the charm? > =20 > When it is time, I was just planning to do the conversion and resubmit = it as the next version of the RAAN document (perhaps with minor edits). = I guess though there is the question of whether we should =E2=80=9Crestart= =E2=80=9D as an individual submission or whether the WG just agrees to = resume work on this document as a WG document. Anyway, we can debate = that on the list before publication. > =20 > Of course, also need to also check with the co-authors (you and Ole) = to see how best to proceed. I had assumed you both would stay on =E2=80=A6= > =20 > At present, the only one really pushing for this to start now is Fred = T. > =20 > - Bernie > =20 > From: Ralph Droms [mailto:rdroms.ietf@gmail.com = ]=20 > Sent: Monday, February 27, 2017 3:22 PM > To: Bernie Volz (volz) > > Cc: Ted Lemon >; dhcwg = >; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89>; Templin, Fred L = > > Subject: Re: [dhcwg] New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > Bernie - a long time ago, if I recall correctly, you asked me if I had = XML source for the earlier RAAN document. I searched around, but can't = seem to find that file. Is the text in that earlier doc at all useful = for this instantiation of RAAN? > =20 > - Ralph > =20 > On Feb 27, 2017, at 3:17 PM, Templin, Fred L = > wrote: > =20 > Hi Ted, > =20 > Just getting back to this after being away for the past week: > =20 > =C3=98 Fred, I think we all agree that this problem needs to be = solved. > =20 > I still think it would be cleanest and most consistent with past works = if the base > sedhcpv6 specification were to include the RAAN option itself. But, if = that would > not be possible and if (as you say) there is agreement that this = problem needs > to be solved, then we should adopt the RAAN draft as a dhcwg working = group > item now. > =20 > =C3=98 We don't agree that work on the security draft must stop until = the raan draft is done. > =20 > I never said or meant to imply that the security draft must stop until = RAAN is done. > To the contrary, the two documents could run in parallel with both = being dhcwg WG > items now and with no interdependencies. By adopting RAAN as a WG item = now, > implementers would be more likely to implement RAAN in parallel with = sedhcpv6 > rather than defer it to some (much) later time. > =20 > =C3=98 It's just not that hard. > =20 > Definitely agree. > =20 > Thanks - Fred > =20 > From: Ted Lemon [mailto:mellon@fugue.com ]=20 > Sent: Saturday, February 18, 2017 9:17 AM > To: Templin, Fred L > > Cc: dhcwg >; =E7=A5=9E=E6=98=8E=E9= =81=94=E5=93=89 >; Bernie = Volz (volz) > > Subject: RE: [dhcwg] Fwd: New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > Fred, I think we all agree that this problem needs to be solved. We = don't agree that work on the security draft must stop until the raan = draft is done. It's just not that hard.=20 > =20 > On Feb 18, 2017 11:28 AM, "Templin, Fred L" > wrote: > Hi Bernie, > =20 > My understanding is that sedhcpv6 is intended to be a product of the = IETF, > so I therefore assume that it is intended to be a product of = engineering. It > has been shown that sedhcpv6 has an omission that will limit its = applicability, > and that that omission can be rather easily remedied prior to = publication. It > therefore makes good engineering sense to fix the omission now. > =20 > The proposal again is to have sedhcpv6 specify the RAAN option as part = of > the base document. > =20 > Thanks - Fred > =20 > From: Bernie Volz (volz) [mailto:volz@cisco.com = ]=20 > Sent: Friday, February 17, 2017 3:00 PM > To: Templin, Fred L >; Ted Lemon >;=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = > >=20 > Cc: dhcwg > > Subject: RE: [dhcwg] Fwd: New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > I think the plan here makes some sense =E2=80=A6 seDHCPv6 has had = several attempts and been kicked back to the WG. So, I think the WG = wants to go slowly and not develop a solution until seDHCPv6 is likely = to advance in the IESG (encryption was only added fairly = =E2=80=9Crecently=E2=80=9D). > =20 > And, it isn=E2=80=99t like the day after seDHCPv6 is =E2=80=9Capproved=E2= =80=9D that every client (and server) will support this. It will take = time to roll out. And, hopefully we can get the RAAN work out in a = fairly short time. > =20 > In your networks, if you can=E2=80=99t support seDHCPv6 until you have = something to so solve the RAAN issues, you obviously can=E2=80=99t = deploy seDHCPv6. But there may be plenty of other networks where this = isn=E2=80=99t an issue and it could start to be deployed (coffee shops = and enterprises). > =20 > - Bernie >=20 > =20 > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com = ]=20 > Sent: Friday, February 17, 2017 5:35 PM > To: Bernie Volz (volz) >; Ted = Lemon >; = =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89> > Cc: dhcwg > > Subject: RE: [dhcwg] Fwd: New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > Bernie, > =20 > The discussion gravitated towards not resurrecting until the sedhcpv6 > I-D progresses further. We will reevaluate this once sedhcpv6 is done. > =20 > This does not make sense to me; sedhcpv6 is the very reason that RAAN = is important. > Just like RFC3971 did with IPv6 ND Timestamp and Nonce options, = sedhcpv6 could > define the RAAN operation and have everything over and done with in = one pass. > And, I have already identified a use case where RAAN is absolutely = necessary. > Also, I was unable to attend IETF97, where I certainly would have = stood up and > voiced my position. > =20 > Thanks - Fred > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org = ] On Behalf Of Bernie Volz (volz) > Sent: Thursday, February 16, 2017 2:39 PM > To: Ted Lemon >; = =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > > Cc: dhcwg > > Subject: Re: [dhcwg] Fwd: New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > I presented about resurrecting draft-ietf-dhc-dhcpv6-agentopt-delegate = at IETF-97 = (seehttps://www.ietf.org/proceedings/97/slides/slides-97-dhc-resurrect-dra= ft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf = ). > =20 > And the conclusion then was (see = https://www.ietf.org/proceedings/97/minutes/minutes-97-dhc-00.txt = ): > =20 > The discussion gravitated towards not resurrecting until the sedhcpv6 > I-D progresses further. We will reevaluate this once sedhcpv6 is done. > =20 > - Bernie >=20 > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org = ] On Behalf Of Ted Lemon > Sent: Wednesday, February 15, 2017 1:49 PM > To: =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > > Cc: dhcwg > > Subject: Re: [dhcwg] Fwd: New Version Notification for = draft-ietf-dhc-sedhcpv6-20.txt > =20 > On Feb 15, 2017, at 1:32 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = > wrote: > I personally don't think it a blocking issue for sedhcpv6, but, of > course, the wg should decide it. > =20 > It definitely isn't a blocking issue, but Fred is right that if we are = going ahead with encryption-only, which I agree is the right move, we = need to do this work as well. > =20 > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg = --Apple-Mail=_79BEE41A-1267-495B-B54C-7290C98D2697 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Bernie - thanks for the status update on doc WG interest in = RAAN.

Converting the = existing document to XML is probably a good place to start.  A = discussion on the list about restarting as an individual document or = picking back up again as a WG document would likely also give you a = sense of who might be interested in seeing the standard developed and = published.  I don't have a sense of the intersection of deployments = of seDHCP with really agent snooping, so I don't have a good way to = judge potential interest.

I'll be happy to stay on as a co-author.

- Ralph

On Feb 27, 2017, at 3:33 PM, Bernie Volz (volz) <volz@cisco.com> = wrote:

Hi:
 
I would think we would = start with the current RAAN document (I think we can easily create the = XML from the TXT; would have been easier not to have to do that if XML = was available).
 
We haven=E2=80=99t = discussed it seriously in the WG yet, and no one has requested time to = discuss further at IETF-98 (Chicago). Though of course we can do it here = on the ML.
 
My hope would be that = we can restart this work perhaps between Chicago and Prague, as = hopefully seDHCPv6 will go to WGLC sometime soon. But of course, = seDHCPv6 has been there before and it was in the IESG that it was = bounced back to the WG =E2=80=93 though hopefully third time will be the = charm?
 
When it is time, I was = just planning to do the conversion and resubmit it as the next version = of the RAAN document (perhaps with minor edits). I guess though there is = the question of whether we should =E2=80=9Crestart=E2=80=9D as an = individual submission or whether the WG just agrees to resume work on = this document as a WG document. Anyway, we can debate that on the list = before publication.
 
Of course, also need to = also check with the co-authors (you and Ole) to see how best to proceed. = I had assumed you both would stay on =E2=80=A6
 
At present, the only = one really pushing for this to start now is Fred T.
 
-          Bernie
 
From: Ralph = Droms [mailto:rdroms.ietf@gmail.com] 
Sent: Monday, February 27, 2017 = 3:22 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: Ted = Lemon <mellon@fugue.com>; dhcwg = <dhcwg@ietf.org>; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89<jinmei@wide.ad.jp>;= Templin, Fred L <Fred.L.Templin@boeing.com>
Subject: Re: [dhcwg] New Version = Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
Bernie - a long time ago, if I recall correctly, you asked me = if I had XML source for the earlier RAAN document.  I searched = around, but can't seem to find that file.  Is the text in that = earlier doc at all useful for this instantiation of RAAN?
 
- Ralph
 
On Feb 27, 2017, at = 3:17 PM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
 
Hi = Ted,
 
Just getting back to this after being away = for the past week:
 
=C3=98  Fred, I think we all = agree that this problem needs to be solved.
 
I still think it would = be cleanest and most consistent with past works if the base
sedhcpv6 specification = were to include the RAAN option itself. But, if that would
not be possible and if = (as you say) there is agreement that this problem needs
to be solved, then we = should adopt the RAAN draft as a dhcwg working group
item now.
 
=C3=98  We don't agree that = work on the security draft must stop until the raan draft is done.
 
I never said or meant = to imply that the security draft must stop until RAAN is = done.
To = the contrary, the two documents could run in parallel with both being = dhcwg WG
items now and with no interdependencies. By adopting RAAN as = a WG item now,
implementers would be more likely to = implement RAAN in parallel with sedhcpv6
rather than defer it to = some (much) later time.
 
=C3=98  It's just not that = hard.
 
Definitely agree.
 
Thanks - = Fred
 
From: Ted Lemon [mailto:mellon@fugue.com] 
Sent: Saturday, February 18, 2017 = 9:17 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: dhcwg= <dhcwg@ietf.org>; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>;= Bernie Volz (volz) <volz@cisco.com>
Subject: RE: [dhcwg] Fwd: New = Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
Fred, I think we all agree that this = problem needs to be solved. We don't agree that work on the security = draft must stop until the raan draft is done. It's just not that = hard. 
 
On Feb 18, 2017 11:28 AM, "Templin, Fred = L" <Fred.L.Templin@boeing.com> wrote:
Hi = Bernie,
 
My understanding  is that sedhcpv6 is = intended to be a product of the IETF,
so I therefore assume = that it is intended to be a product of engineering. It
has been shown that = sedhcpv6 has an omission that will limit its applicability,
and that that omission = can be rather easily remedied prior to publication. It
therefore makes good = engineering sense to fix the omission now.
 
The proposal again is = to have sedhcpv6 specify the RAAN option as part of
the base = document.
 
Thanks - Fred
 
From: Bernie Volz (volz) [mailto:volz@cisco.com] 
Sent: Friday, February 17, 2017 = 3:00 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; Ted Lemon <mellon@fugue.com>;=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>

Cc: dhcwg= <dhcwg@ietf.org>
Subject: RE: [dhcwg] Fwd: New = Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
I think the plan here = makes some sense =E2=80=A6 seDHCPv6 has had several attempts and been = kicked back to the WG. So, I think the WG wants to go slowly and not = develop a solution until seDHCPv6 is likely to advance in the IESG = (encryption was only added fairly =E2=80=9Crecently=E2=80=9D).
 
And, it isn=E2=80=99t = like the day after seDHCPv6 is =E2=80=9Capproved=E2=80=9D that every = client (and server) will support this. It will take time to roll out. = And, hopefully we can get the RAAN work out in a fairly short = time.
 
In your networks, if you can=E2=80=99t = support seDHCPv6 until you have something to so solve the RAAN issues, = you obviously can=E2=80=99t deploy seDHCPv6. But there may be plenty of = other networks where this isn=E2=80=99t an issue and it could start to = be deployed (coffee shops and enterprises).
 

-          Bernie

 
From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] 
Sent: Friday, February 17, 2017 = 5:35 PM
To: Bernie Volz (volz) <volz@cisco.com>; Ted Lemon <mellon@fugue.com>; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89<jinmei@wide.ad.jp>
Cc: dhcwg <dhcwg@ietf.org>
Subject: RE: [dhcwg] Fwd: New = Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
Bernie,
 
The discussion gravitated towards not resurrecting until the = sedhcpv6
I-D progresses further. We will = reevaluate this once sedhcpv6 is done.
 
This does not make = sense to me; sedhcpv6 is the very reason that RAAN is = important.
Just like RFC3971 did with IPv6 ND Timestamp and Nonce = options, sedhcpv6 could
define the RAAN operation and have = everything over and done with in one pass.
And, I have already = identified a use case where RAAN is absolutely necessary.
Also, I was unable to = attend  IETF97, where I certainly would have stood up = and
voiced my position.
 
Thanks - = Fred
 
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Bernie Volz = (volz)
Sent: Thursday, February 16, 2017 = 2:39 PM
To: Ted Lemon <mellon@fugue.com>; =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] Fwd: New = Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
I presented about = resurrecting draft-ietf-dhc-dhcpv6-agentopt-delegate at IETF-97 (seehttps://www.ietf.org/proceedings/97/slides/slides-97-dhc-resurr= ect-draft-ietf-dhc-dhcpv6-agentopt-delegate-00.pdf).
 
 
The discussion gravitated towards not resurrecting until the = sedhcpv6
I-D progresses further. We will = reevaluate this once sedhcpv6 is done.
 

-          Bernie

 
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ted Lemon
Sent: Wednesday, February 15, = 2017 1:49 PM
To: =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] Fwd: New = Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
 
On Feb 15, 2017, at 1:32 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp> wrote:
I = personally don't think it a blocking issue for sedhcpv6, but, of
course, the wg should decide it.
 
It definitely isn't a blocking issue, but = Fred is right that if we are going ahead with encryption-only, which I = agree is the right move, we need to do this work as well.
 
 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

= --Apple-Mail=_79BEE41A-1267-495B-B54C-7290C98D2697-- From nobody Tue Feb 28 15:01:53 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD5F1297A8; Tue, 28 Feb 2017 15:01:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148832290489.29564.4713037491458509234.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2017 15:01:44 -0800 Archived-At: Cc: Bernie Volz , dhc-chairs@ietf.org, The IESG , draft-ietf-dhc-dhcpv6-failover-protocol@ietf.org, dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] Protocol Action: 'DHCPv6 Failover Protocol' to Proposed Standard (draft-ietf-dhc-dhcpv6-failover-protocol-06.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:01:45 -0000 The IESG has approved the following document: - 'DHCPv6 Failover Protocol' (draft-ietf-dhc-dhcpv6-failover-protocol-06.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-failover-protocol/ Technical Summary This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC7031). Working Group Summary There is a strong consensus behind this document in the working group and in particular from very active participants of the dhc WG. Document Quality This document has had thorough reviews by many interested and knowledgeable folks, and is based on the DHCPv4 failover design which had many years of review but never made it to the IESG. There were no significant points of difficulty or controversy with the contents of the document. There is a commercial product (Cisco Prime Network Registrar) that has implemented a protocol that is very similar to the draft protocol and it has been deployed in large service provider's networks (as well as many other deployments). Personnel Bernie Volz is the document shepherd. Suresh Krishnan is the responsible AD. From nobody Tue Feb 28 15:08:26 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00507129435 for ; Tue, 28 Feb 2017 15:08:25 -0800 (PST) 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 autolearn_force=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 dihgxZS3IpXR for ; Tue, 28 Feb 2017 15:08:23 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A0212940E for ; Tue, 28 Feb 2017 15:08:23 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6AE5B80A00; Wed, 1 Mar 2017 00:08:20 +0100 (CET) References: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> To: "dhcwg@ietf.org" From: Fernando Gont X-Forwarded-Message-Id: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> Message-ID: Date: Tue, 28 Feb 2017 20:08:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <7dcf6972-d09f-d559-2f84-592adb01b5ff@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dhcwg] Fwd: New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:08:25 -0000 Folks, FYI. Discussion is taking place on the v6ops wg mailing-list. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt) Date: Tue, 28 Feb 2017 05:13:25 -0300 From: Fernando Gont To: IPv6 Operations Folks, Based on a recent discussion regarding the problem of conveying DNS information in IPv6 networks, we have submitted this short I-D, in the hopes of getting the aforementioned problem solved. Your feedback will be appreciated. Thanks! Fernando (and co-autors) -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-host-configuration-00.txt Date: Mon, 27 Feb 2017 23:51:03 -0800 From: internet-drafts@ietf.org To: Fernando Gont , Gert Doering , Madelen Garcia Corbo , Madelen Corbo , Guillermo Gont A new version of I-D, draft-gont-v6ops-host-configuration-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-host-configuration Revision: 00 Title: On the Dynamic/Automatic Configuration of IPv6 Hosts Document date: 2017-02-27 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-host-configuration-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-host-configuration/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-host-configuration-00 Abstract: IPv6 has two different mechanisms for dynamic/automatic host configuration: SLAAC and DHCPv6. These two mechanisms allow for the configuration of IPv6 addresses and a number of network parameters. While there is overlap in the parameters that can be configured via these two protocols, different implementations support only subsets of such parameters with either mechanism, or have no support for DHCPv6 at all. This document analyzes a problem that arises from this situation, and mandates that all host implementations support RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6 functionality in RFC 3315. 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 From nobody Tue Feb 28 19:05:25 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 536E012944D; Tue, 28 Feb 2017 19:05:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148833752033.29490.14641154545142318798.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2017 19:05:20 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-port-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 03:05:20 -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 of the IETF. Title : Generalized UDP Source Port for DHCP Relay Authors : Naiming Shen Enke Chen Filename : draft-ietf-dhc-relay-port-02.txt Pages : 10 Date : 2017-02-28 Abstract: This document proposes an extension to the DHCP and DHCPv6 protocols that allows any valid number to be used as the relay agent UDP source port for DHCP packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-relay-port-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 Feb 28 19:10:40 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17422129490 for ; Tue, 28 Feb 2017 19:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 9Nnqy3iURsb8 for ; Tue, 28 Feb 2017 19:10:37 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2279D129485 for ; Tue, 28 Feb 2017 19:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9274; q=dns/txt; s=iport; t=1488337835; x=1489547435; h=from:to:subject:date:message-id:references:mime-version; bh=KRi0V8eRYmelIAIkNt32PeYMpN6GVdrNH15RP/IiWh8=; b=P0IuEyQVsc4l3+viAlt/p7h1dDe8jYeVDYDKQ7RKxUFE38fSEdNgdqXd ICTVt1SyYO0gvf51oF9AUQId3PUDEleVNMZ//hEPDKb2PeDwideSFv6X2 ne1hfXLSz2b2qScXXMrhd76v4K9vubUbpJm+IPQJSAvO7jEnCvhoU3Des 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQBqOrZY/4MNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHjVyRY5AJhSyCDR8BCoV4AoIuPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQYBAWwbAgEZAwECKAcnCxQHAggCBBMJiW0Os3uLJgEBAQEBAQQBAQEBAQEBA?= =?us-ascii?q?QEBAR2IUYJqgxeBXRaCFmiCMQWVc4Y0AYZzizyBe1OETYhFgTqKbYhEAR84gQF?= =?us-ascii?q?UFRgmEQGGO3UBiGIBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,223,1484006400"; d="scan'208,217";a="391696886" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Mar 2017 03:10:34 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v213AYv2029116 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 Mar 2017 03:10:34 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Feb 2017 21:10:33 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Tue, 28 Feb 2017 21:10:33 -0600 From: "Naiming Shen (naiming)" To: dhcwg Thread-Topic: I-D Action: draft-ietf-dhc-relay-port-02.txt Thread-Index: AQHSkjiz6IDG/6PhnUq3bL8ha9sY2A== Date: Wed, 1 Mar 2017 03:10:32 +0000 Message-ID: References: <148833752033.29490.14641154545142318798.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.155.84] Content-Type: multipart/alternative; boundary="_000_D4FA44D32F8E4B68815C2402D821E4BDciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-relay-port-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 03:10:39 -0000 --_000_D4FA44D32F8E4B68815C2402D821E4BDciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dhcwg, We have updated the dhc-relay-port draft. The changes: o Added the Terminology section. o Defined the Sub-option and Option names for DHCPv4 and DHCPv6. o Added the DHCPv6 cascaded relay agents example. Please review and comment. thanks. - Naiming Begin forwarded message: From: internet-drafts@ietf.org Subject: I-D Action: draft-ietf-dhc-relay-port-02.txt Date: February 28, 2017 at 7:05:20 PM PST To: > Cc: dhcwg@ietf.org Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : Generalized UDP Source Port for DHCP Relay Authors : Naiming Shen Enke Chen Filename : draft-ietf-dhc-relay-port-02.txt Pages : 10 Date : 2017-02-28 Abstract: This document proposes an extension to the DHCP and DHCPv6 protocols that allows any valid number to be used as the relay agent UDP source port for DHCP packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-port-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_D4FA44D32F8E4B68815C2402D821E4BDciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi dhcwg,

We have updated the dhc-relay-port draft. The changes: 
   o  Added the Terminology section.

   o  Defined the Sub-option and Option names for DHCPv4 and DHCPv6.

   o  Added the DHCPv6 cascaded relay agents example.

Please review and comment.

thanks.
- Naiming

Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-ietf-dh= c-relay-port-02.txt
Date: February 28, 2017 at 7:05:20 PM PST
To: <i-d-announce@ietf.org>
Cc: dhcwg@ietf.org
Reply-To: internet-drafts@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Dynamic Host Configuration of the IETF.
       Title     &nb= sp;     : Generalized UDP Source Port for DHCP Rel= ay
       Authors     &= nbsp;   : Naiming Shen
            &nb= sp;            = Enke Chen
Filename &n= bsp;      : draft-ietf-dhc-relay-port-02.txt<= br class=3D""> Pages  = ;         : 10
Date  =           : 2017-02-28
Abstract:
  This document proposes an extension to the DHCP and DHCPv6 prot= ocols
  that allows any valid number to be used as the relay agent UDP = source
  port for DHCP packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dhc-relay-port-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-port-02


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

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--_000_D4FA44D32F8E4B68815C2402D821E4BDciscocom_--