From nobody Fri Sep 2 04:44:48 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB4C12D776 for ; Fri, 2 Sep 2016 04:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Smajs0eJ1qSW for ; Fri, 2 Sep 2016 04:44:42 -0700 (PDT) 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 7B45612D81D for ; Fri, 2 Sep 2016 04:44:33 -0700 (PDT) Received: (qmail 5796 invoked from network); 2 Sep 2016 13:44:29 +0200 Received: from p5dec2984.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.41.132) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Sep 2016 13:44:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 2 Sep 2016 13:44:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30E44B2B-C7B2-4E4D-8B6C-70B0D95E317E@kuehlewind.net> References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> <74f2750c-10f3-402c-d771-2d93cef76ced@gmail.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "radext@ietf.org" , "" , Jouni Korhonen , draft-ietf-radext-ip-port-radius-ext@ietf.org, The IESG , Brian Trammell , radext-chairs@ietf.org Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 11:44:43 -0000 Did finally send someone the review to the right people or should I ping = Brian (again)? Mirja > Am 17.08.2016 um 19:18 schrieb Kathleen Moriarty = : >=20 > Apparently, Brian did the review. I'm adding him to this thread so he > can send the review to the draft distribution list. >=20 > Thank you, > Kathleen >=20 > On Wed, Aug 17, 2016 at 1:13 PM, Jouni Korhonen = wrote: >> Hi, >>=20 >> Would it be possible to see the IE doctor's feedback? The authors = might find >> it useful as well. If it has been distributed already, my apologies = if I >> missed it. >>=20 >> regards, >> Jouni >>=20 >> 8/17/2016, 7:04 AM, Mirja Kuehlewind kirjoitti: >>>=20 >>> Mirja K=C3=BChlewind has entered the following ballot position for >>> draft-ietf-radext-ip-port-radius-ext-11: Discuss >>>=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-radext-ip-port-radius-ext/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> I fully support Alissa's discussion points and have two more to >>> = add:https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/= >>>=20 >>> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very >>> future-proof: there are other transport protocols that have ports or >>> identifiers that may want to be supported in future. Also it is not = clear >>> to me from the document why this information is needed at all in the >>> described use cases. Therefore I see two possible ways forward: = Either >>> remove the IP-Port-Type TLV or extend it to also cover other cases. >>>=20 >>> Related to this point I would like to mention that RFC6887 is not >>> restricted to UDP/TCP and therefore the following sentence in = section 2 >>> is not correct: >>> "Note that the definitions of [...] "internal port", [...] "external >>> port" [...] are the same as defined in Port Control Protocol (PCP) >>> [RFC6887]" >>>=20 >>> 2) The IE doctors have provide feedback to IANA that the Information >>> Elements in this doc are underspecified (not confirm with rules in = RFC >>> 7013) and should therefore be not registered. Addressing this = feedback >>> could lead to a mayor rewrite of this doc, especially in the = relation to >>> the use and definition of transportType and receptively IP-Port-Type = TLV, >>> and should therefore be done before a final IESG decision. >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 From nobody Fri Sep 2 09:41:47 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1169012D190; Fri, 2 Sep 2016 09:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 gflWwEWXoaJA; Fri, 2 Sep 2016 09:41:44 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 5E1C612D0EA; Fri, 2 Sep 2016 09:41:44 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id l94so182724120ual.0; Fri, 02 Sep 2016 09:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5BuwixBKWIKkgsS9ROml55ZE6GpFnNNy3SxGgc744gY=; b=aWyXXswkmaBiDHjT8i62ZIcq0jbD1i//xyTKPReKjj8JjQBqA7ngytm6698oKSH+ZY yNWPtnuuFcRzDbtIJrIE2oE9lz1uTlSwfg1TMbTo2NsPwBsO4bY3Pyu/izzuQigJ+f8F +1RNaWagmbDLsC4uGXQN1Ymq07KiNS+9vaWTxvUepRZ1NvzVBq7uS9M+E7qxEcQ2cdky O5RWOkA7koUYr8UKdRGRjhUq4RP2J5BTSGqsIfLfwM7Rr3ggv07YvfMCyGFsCn0LW74I k+RyFyr/oFqz/i4NgdqTvHQ7cgXZ/AytQ8G8Qg+xbgTe1HHdW6goSISfBIxxiLLCyORN JBtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5BuwixBKWIKkgsS9ROml55ZE6GpFnNNy3SxGgc744gY=; b=Z+yd3+IRXvcOVbXKKdMPToVjZrZsMAiydsxylOIhSaKioTqvZOWL3U5d1oStRjrGQ8 8HBFIFSyhExmKZrxhhLQNBC81h80eGF9jivso8osr4hFLykHhwHfd0XKpSi7aAxdlrAu 59OCi36TAAJpmR67Eowz1bGp91Dgx78HqJH1X+cLX72tzcwqKSVL0somlzV3noE/FnEd FAxB0yjIyiGaoM6I60rCxtGQlW9ETTbHu9rzC+oM7eiQzdC5hFSvMONG7SZ51Mywzvbr dC/pJB9ai5cL1jlhrzyDYDbtPf2yZ37byCPUWaAsjiJ79yG11ZAIPXtf2gLBctHA5uuD oorw== X-Gm-Message-State: AE9vXwMhYg78dzC6dQSm1OcAKlSpVir6rSiYQ+Nz5K+fI09LoeUe+CYvfPncyBlp4pfao5cyAG7o+yAJWfxPWA== X-Received: by 10.159.53.1 with SMTP id o1mr13737261uao.15.1472834503455; Fri, 02 Sep 2016 09:41:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.226 with HTTP; Fri, 2 Sep 2016 09:41:42 -0700 (PDT) In-Reply-To: <30E44B2B-C7B2-4E4D-8B6C-70B0D95E317E@kuehlewind.net> References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> <74f2750c-10f3-402c-d771-2d93cef76ced@gmail.com> <30E44B2B-C7B2-4E4D-8B6C-70B0D95E317E@kuehlewind.net> From: Kathleen Moriarty Date: Fri, 2 Sep 2016 12:41:42 -0400 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "radext@ietf.org" , "" , Jouni Korhonen , draft-ietf-radext-ip-port-radius-ext@ietf.org, The IESG , Brian Trammell , radext-chairs@ietf.org Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 16:41:46 -0000 On Fri, Sep 2, 2016 at 7:44 AM, Mirja Kuehlewind (IETF) wrote: > Did finally send someone the review to the right people or should I ping = Brian (again)? That would be helpful, I believe we are still waiting for the review. Thanks, Kathleen > > Mirja > > >> Am 17.08.2016 um 19:18 schrieb Kathleen Moriarty : >> >> Apparently, Brian did the review. I'm adding him to this thread so he >> can send the review to the draft distribution list. >> >> Thank you, >> Kathleen >> >> On Wed, Aug 17, 2016 at 1:13 PM, Jouni Korhonen = wrote: >>> Hi, >>> >>> Would it be possible to see the IE doctor's feedback? The authors might= find >>> it useful as well. If it has been distributed already, my apologies if = I >>> missed it. >>> >>> regards, >>> Jouni >>> >>> 8/17/2016, 7:04 AM, Mirja Kuehlewind kirjoitti: >>>> >>>> Mirja K=C3=BChlewind has entered the following ballot position for >>>> draft-ietf-radext-ip-port-radius-ext-11: 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 thi= s >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >>>> 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-radext-ip-port-radius-ext/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> I fully support Alissa's discussion points and have two more to >>>> add:https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-= ext/ >>>> >>>> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not very >>>> future-proof: there are other transport protocols that have ports or >>>> identifiers that may want to be supported in future. Also it is not cl= ear >>>> to me from the document why this information is needed at all in the >>>> described use cases. Therefore I see two possible ways forward: Either >>>> remove the IP-Port-Type TLV or extend it to also cover other cases. >>>> >>>> Related to this point I would like to mention that RFC6887 is not >>>> restricted to UDP/TCP and therefore the following sentence in section = 2 >>>> is not correct: >>>> "Note that the definitions of [...] "internal port", [...] "external >>>> port" [...] are the same as defined in Port Control Protocol (PCP) >>>> [RFC6887]" >>>> >>>> 2) The IE doctors have provide feedback to IANA that the Information >>>> Elements in this doc are underspecified (not confirm with rules in RFC >>>> 7013) and should therefore be not registered. Addressing this feedbac= k >>>> could lead to a mayor rewrite of this doc, especially in the relation = to >>>> the use and definition of transportType and receptively IP-Port-Type T= LV, >>>> and should therefore be done before a final IESG decision. >>>> >>>> >>>> >>>> >>> >> >> >> >> -- >> >> Best regards, >> Kathleen >> > --=20 Best regards, Kathleen From nobody Fri Sep 2 10:07:26 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202B912D8D6; Fri, 2 Sep 2016 10:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 9WhsKVEqxICS; Fri, 2 Sep 2016 10:07:12 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 357D612D8B6; Fri, 2 Sep 2016 10:07:11 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 6E3611A114D; Fri, 2 Sep 2016 19:07:10 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A89C8C37-393F-4E70-9535-DD501CAA60BC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Fri, 2 Sep 2016 19:07:09 +0200 Message-Id: <99B00097-B852-4A46-8CEB-6265DCBEA85D@trammell.ch> References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> <74f2750c-10f3-402c-d771-2d93cef76ced@gmail.com> <30E44B2B-C7B2-4E4D-8B6C-70B0D95E317E@kuehlewind.net> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, "" , Jouni Korhonen , "Mirja Kuehlewind \(IETF\)" , The IESG , "radext@ietf.org" , radext-chairs@ietf.org Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 17:07:20 -0000 --Apple-Mail=_A89C8C37-393F-4E70-9535-DD501CAA60BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Kathleen, all, Sorry, this fell off my radar, due to the present emergency. Review text below: In general, the Information Elements in = draft-ietf-radext-ip-port-radius-ext are so underspecified as to be = unimplementable. They should not be added to the registry in their = present form. The authors are advised to read RFC 7013, especially = Section 4, which provides useful information on defining Information = Elements. Specifically: The Information Element transportType is underspecified: (a) I presume = this is in reference to sourceTransportPort and = destinationTransportPort, but the description must say this if it is the = case; (b) It's not clear at all from the description in what context = this distinction is useful; (c) What's an ICMP identifier? In addition, the description of transportType appears to create a table = which should probably be handled as a subregistry. See See RFC7013 = section 4.7. for advice on the creation of tables without subregistries = (in short, "don't".) The Information Element natTransportLimit has an inappropriate name; it = does not describe that which it (presumably) is supposed to represent = (see RFC 7013 section 4.1). In addition, it is underspecified. It is = impossible to implement from the description. Is the field IPv4 = specific, or is IPv6 supported as well? (If not, why not?) The Information Element localID has an inappropriate name; it is far too = general (see RFC 7013 section 4.1). It uses an inappropriate abstract = data type (addresses should never be represented as UTF-8 strings in = IPFIX, see RFC 7013 section 4.2). It is underspecified as well as poorly = designed. Without the ability to disambiguate the type of information in = the field, this is not a useful Information Element. Without a complete = enumeration of possible types (n.b. 'etc.' in the description), it is = not a useful Information Element. Its purpose is unclear from its = description; further, it appears to violate the following guidance in = RFC 7013 section 4: "The Information Element must be unique within the = registry, and its description must represent a substantially different = meaning from that of any existing Information Element. An existing = Information Element that can be reused for a given purpose should be = reused." Best regards, Brian Trammell (for the IE-Doctors) > On 02 Sep 2016, at 18:41, Kathleen Moriarty = wrote: >=20 > On Fri, Sep 2, 2016 at 7:44 AM, Mirja Kuehlewind (IETF) > wrote: >> Did finally send someone the review to the right people or should I = ping Brian (again)? >=20 > That would be helpful, I believe we are still waiting for the review. >=20 > Thanks, > Kathleen >=20 >>=20 >> Mirja >>=20 >>=20 >>> Am 17.08.2016 um 19:18 schrieb Kathleen Moriarty = : >>>=20 >>> Apparently, Brian did the review. I'm adding him to this thread so = he >>> can send the review to the draft distribution list. >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>> On Wed, Aug 17, 2016 at 1:13 PM, Jouni Korhonen = wrote: >>>> Hi, >>>>=20 >>>> Would it be possible to see the IE doctor's feedback? The authors = might find >>>> it useful as well. If it has been distributed already, my apologies = if I >>>> missed it. >>>>=20 >>>> regards, >>>> Jouni >>>>=20 >>>> 8/17/2016, 7:04 AM, Mirja Kuehlewind kirjoitti: >>>>>=20 >>>>> Mirja K=C3=BChlewind has entered the following ballot position for >>>>> draft-ietf-radext-ip-port-radius-ext-11: Discuss >>>>>=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-radext-ip-port-radius-ext/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> I fully support Alissa's discussion points and have two more to >>>>> = add:https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/= >>>>>=20 >>>>> 1) IP-Port-Type TLV only covers UDP, TCP and ICMP. This is not = very >>>>> future-proof: there are other transport protocols that have ports = or >>>>> identifiers that may want to be supported in future. Also it is = not clear >>>>> to me from the document why this information is needed at all in = the >>>>> described use cases. Therefore I see two possible ways forward: = Either >>>>> remove the IP-Port-Type TLV or extend it to also cover other = cases. >>>>>=20 >>>>> Related to this point I would like to mention that RFC6887 is not >>>>> restricted to UDP/TCP and therefore the following sentence in = section 2 >>>>> is not correct: >>>>> "Note that the definitions of [...] "internal port", [...] = "external >>>>> port" [...] are the same as defined in Port Control Protocol (PCP) >>>>> [RFC6887]" >>>>>=20 >>>>> 2) The IE doctors have provide feedback to IANA that the = Information >>>>> Elements in this doc are underspecified (not confirm with rules in = RFC >>>>> 7013) and should therefore be not registered. Addressing this = feedback >>>>> could lead to a mayor rewrite of this doc, especially in the = relation to >>>>> the use and definition of transportType and receptively = IP-Port-Type TLV, >>>>> and should therefore be done before a final IESG decision. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>=20 >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen --Apple-Mail=_A89C8C37-393F-4E70-9535-DD501CAA60BC 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 iQIcBAEBCgAGBQJXybG+AAoJEIoSt78L6kajF4kP/jGQ36woEmWgYEaUOBwB8tGT UHkfwRze0hZ0wYMtzgvSktf1XDOd0/slgKnrC71m1Mt2dWZywNstNnNN7vCX+4mc KCeZw1LUt4MrPW1hOaVPK01GU/QV6o6T0Ej0tJxwNeynic0D5eil7N2F6k0q4U2o IIKzz6AwPYzRQBUWhoowng5nlPr2MzmMlxjF+RftcQSoBPJVYhgbH8UzgZ5NdHtO lt6dFAzWk4aDePRdYpU76UzBLBb4laJj4JdFxbEBNXI8K+ebMuJnAJ6IIRBOPQfb DXl1VVy7QiT1oQtsRlvkmSJY+kLQFg7TbXmwn0YQOqWKsjD9Gxke88W4Xsbu6ycP W45Tjlk7lpDmNTA0bJ4tJJtHkm4t4Rl5F4i0ckSHluib+L+2YseIRaCzn+sSia49 XOxDvLSAuiromEUIa5eFkprVEyzdoLjQYe/qLOXkKmHeibTIoTRg6AiJeg5CfcOX hDnZc2M2yh/Ctw9EQLhUrqEevZgY90iNVaawu2SEULeBCYCfNy8DKHiDU7ns89hq z8RGSiIc6muAlFvzK976Jx7t9XUQP8oHuBYiEeIxEzRtL3V4D28OoDKiaavYZKnl 5AnrAOW5Gf3HG6gKnrq+lUyLf+Q+DTmsRVl0EfcigAe+fIiVR5Y86Yqv53Zm1v1C Zul8Vu0AjLaR6lcHfUYP =HtsL -----END PGP SIGNATURE----- --Apple-Mail=_A89C8C37-393F-4E70-9535-DD501CAA60BC-- From nobody Tue Sep 6 02:03:45 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C84512B17A; Tue, 6 Sep 2016 02:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 4RUs3SM0T61j; Tue, 6 Sep 2016 02:03:33 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D13512B0AF; Tue, 6 Sep 2016 02:03:33 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 5766420355; Tue, 6 Sep 2016 11:03:31 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 0FBB21C00A5; Tue, 6 Sep 2016 11:03:31 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0301.000; Tue, 6 Sep 2016 11:03:30 +0200 From: To: "kathleen.moriarty.ietf@gmail.com" , Alissa Cooper Thread-Topic: Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHR9/Cwu6n7TFEfE0aWCTw3JOS72qBL68EAgAADpYCAAAXuAIAfD2Bw Date: Tue, 6 Sep 2016 09:03:29 +0000 Message-ID: <17466_1473152611_57CE8663_17466_5602_1_6B7134B31289DC4FAF731D844122B36E01F9ECE4@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 09:03:37 -0000 SGkgQWxpc3NhLA0KDQp0aGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCBzb3JyeSBmb3IgdGhp cyAibGF0ZSIgZmVlZGJhY2suDQoNCkhlcmUgaXMgbXkgZmVlZGJhY2sgYXMgc2hlcGhlcmQgb2Yg dGhlIGRvY3VtZW50LiBUaGlzIG5lZWRzIHRvIGJlIGNvbXBsZXRlZCBieSBkcmFmdCBhdXRob3Jz IGFuZCB0aGUgQUQuDQoNClJlZ2FyZHMsDQoNCkxpb25lbA0KDQo+ID4+PiAoMSkgSSBmaW5kIHRo ZSBhYnNlbmNlIG9mIGFueSBkZWZpbml0aW9uIG9mIGVycm9yIGhhbmRsaW5nIGJlaGF2aW9yDQo+ ID4+PiBpbiB0aGlzIGRvY3VtZW50IHRvIGJlIGEgcHJvYmxlbS4gSSByZWFsaXplIHRoYXQgdGhl IGF0dHJpYnV0ZXMNCj4gPj4+IHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBtZWFudCB0 byBiZSB0cmFuc21pdHRlZCBiZXR3ZWVuDQo+ID4+PiBjb21wb25lbnRzIHRoYXQgYXJlIGFsbCBv cGVyYXRlZCBieSB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBlbnRpdHksDQo+ID4+PiBidXQgaW1w bGVtZW50b3JzIGNhbiBzdGlsbCBtYWtlIG1pc3Rha2VzLCBhbmQgZm9yIHRob3NlIGNhc2VzIGl0 DQo+ID4+PiBzZWVtcyBsaWtlIGVycm9yIGhhbmRsaW5nIHNob3VsZCBiZSBkZWZpbmVkLg0KDQpN eSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQsIHdoZW4gZGVmaW5pbmcgYXV0aG9yaXphdGlvbiB0eXBl IGF0dHJpYnV0ZXMgdGhhdCBhcmUgdXNlIG92ZXIgUkFESVVTLCBpdCBpcyBub3QgZGVlbWVkIHJl cXVpcmVkIHRvIGRlZmluZSB0aGUgc3BlY2lmaWMgdXNlIG9mIHRoZXNlIGF0dHJpYnV0ZXMgbm9y IHRoZSBlcnJvciBoYW5kbGluZy4NCkFzIGZvciBvdGhlciBBQUEgZG9jdW1lbnRzLCB0aGlzIGRy YWZ0IGlzIG5vdCBzcGVjaWZ5aW5nIGEgc3BlY2lmaWMgcHJvY2VkdXJlIG9yIGEgbmV3IHByb3Rv Y29sIGFwcGxpY2F0aW9uLiBJdCBpcyBqdXN0IGFib3V0IGRlZmluaW5nIGF0dHJpYnV0ZXMgdGhh dCBjYW4gYmUgdXNlZCBpbiB0aGUgdXNlIGNhc2UgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQg YnV0IGFsc28gaW4gYW55IG90aGVyIHNvbHV0aW9uIHRoYXQgd291bGQgc2VlIGFkdmFudGFnZSB0 byByZXVzZSB0aGVzZSBhdHRyaWJ1dGVzLiBUaGUgbWFpbiBwb2ludCBvZiB0aGlzIGRvY3VtZW50 IGlzIHRvIGVuc3VyZSB0aGF0IHRoZSBkZWZpbml0aW9ucyBvZiB0aGVzZSBhdHRyaWJ1dGVzIGFy ZSBjb3JyZWN0ICh0eXBlLCBsZW5ndGgsIHZhbHVlKSwgdW5hbWJpZ3VvdXMgYW5kIGRlc2NyaWJl IGluIHdoaWNoIG1lc3NhZ2VzIHRoZXkgY2FuIGFwcGVhci4NClRoZSBleGFjdCBiZWhhdmlvciBv ZiB0aGUgY2xpZW50L3NlcnZlciB1c2luZyB0aGVzZSBhdHRyaWJ1dGVzIGlzIG9mdGVuIGxlZnQg b3V0IG9mIHRoaXMga2luZCBvZiBkb2N1bWVudC4gSXQgaXMgdXAgdG8gdGhlIHNwZWNpZmljYXRp b24gZGVzY3JpYmluZyB0aGUgaW1wbGVtZW50YXRpb24gdGhlIGNsaWVudHMgYW5kL29yIHNlcnZl cnMgdXNpbmcgdGhlc2UgYXR0cmlidXRlcyB0byBkZWZpbmUgdGhpcyBlcnJvciBoYW5kbGluZy4N Cg0KDQo+ID4+PiAoMikgU2VjdGlvbiAzLjEuMiBzYXlzOg0KPiA+Pj4NCj4gPj4+ICJGb3IgcG9y dCBhbGxvY2F0aW9uLCBib3RoIElQLVBvcnQtUmFuZ2UtU3RhcnQgVExWIGFuZCBJUC0NCj4gPj4+ IFBvcnQtUmFuZ2UtRW5kIFRMViBtdXN0IGJlIGluY2x1ZGVkOyBmb3IgcG9ydCBkZWFsbG9jYXRp b24sIHRoZQ0KPiA+Pj4gaW5jbHVzaW9uIG9mIHRoZXNlIHR3byBUTFZzIGlzIG9wdGlvbmFsIGFu ZCBpZiBub3QgaW5jbHVkZWQsIGl0DQo+ID4+PiBpbXBsaWVzIHRoYXQgYWxsIHBvcnRzIHRoYXQg YXJlIHByZXZpb3VzbHkgYWxsb2NhdGVkIGFyZSBub3cNCj4gPj4+IGRlYWxsb2NhdGVkLiINCj4g Pj4+DQo+ID4+PiBIb3cgZG9lcyBhbiBBQUEgc2VydmVyIGRpc3Rpbmd1aXNoIGJldHdlZW4gcG9y dCBhbGxvY2F0aW9uIGFuZA0KPiA+Pj4gZGVhbGxvY2F0aW9uIHJlcXVlc3RzIGlmIGEgZGVhbGxv Y2F0aW9uIHJlcXVlc3QgaW5jbHVkZXMgYSByYW5nZQ0KPiA+Pj4gc3RhcnQgYW5kIHJhbmdlIGVu ZD8NCg0KSWYgSSdtIGNvcnJlY3QsIHRoZSBhbnN3ZXIgaXMgYmVsb3c6DQoNCjMuMi44LiAgSVAt UG9ydC1BbGxvYyBUTFYNCg0KICAgVGhlIGZvcm1hdCBvZiBJUC1Qb3J0LUFsbG9jIFRMViBpcyBz aG93biBpbiBGaWd1cmUgMTEuICBUaGlzDQogICBhdHRyaWJ1dGUgY2FycmllcyBJUEZJWCBJbmZv cm1hdGlvbiBFbGVtZW50IDIzMCwgIm5hdEV2ZW50Iiwgd2hpY2ggaXMNCiAgIGEgZmxhZyB0byBp bmRpY2F0ZSBhbiBhY3Rpb24gb2YgTkFUIG9wZXJhdGlvbiAocmVmZXIgdG8gW0lQRklYXSkuDQoN CiAgIFdoZW4gdGhlIHZhbHVlIG9mIG5hdEV2ZW50IGlzICIxIiAoQ3JlYXRlIGV2ZW50KSwgaXQg bWVhbnMgdG8NCiAgIGFsbG9jYXRlIGEgcmFuZ2Ugb2YgdHJhbnNwb3J0IHBvcnRzOyB3aGVuIHRo ZSB2YWx1ZSBpcyAiMiIsIGl0IG1lYW5zDQogICB0byBkZWFsbG9jYXRlIGEgcmFuZ2Ugb2YgdHJh bnNwb3J0cyBwb3J0cy4gIEZvciB0aGUgcHVycG9zZSBvZiB0aGlzDQogICBUTFYsIG5vIG90aGVy IHZhbHVlIGlzIHVzZWQuDQoNCj4gPj4+ICgzKSBUaGUgc3BlY2lmaWNhdGlvbiBvZiBJUC1Qb3J0 LUxvY2FsLUlkIHNlZW1zIHRvIGFsbG93IGZvcg0KPiA+Pj4gdW5uZWNlc3NhcnkgZXhwb3N1cmUg b2YgcG90ZW50aWFsbHkgc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiBUaGVyZSBpcw0KPiA+Pj4gbm8g ZXhwbGFuYXRpb24gZ2l2ZW4gZm9yIHdoeSB0aGUgY29tYmluYXRpb24gb2YgdGhlIG90aGVyDQo+ ID4+PiBpZGVudGlmaWVycyBpbmNsdWRlZCBpbiBJUC1Qb3J0LVJhbmdlIGFuZCBJUC1Qb3J0LUZv cndhcmRpbmcNCj4gPj4+IGF0dHJpYnV0ZXMgaXMgaW5zdWZmaWNpZW50IHRvIGlkZW50aWZ5IHRo ZSBob3N0IGluIERTLUV4dHJhLUxpdGUgYW5kDQo+ID4+PiBMaWdodHdlaWdodCA0b3ZlcjYgY2Fz ZXMuIEFzIGRlZmluZWQsIGl0IHNvdW5kcyBsaWtlIGltcGxlbWVudGF0aW9ucw0KPiA+Pj4gY291 bGQgcHV0IGJhc2ljYWxseSBhbnkgdXNlciwgZGV2aWNlLCBvciBpbnRlcmZhY2UgaWRlbnRpZmll ciBpbg0KPiA+Pj4gdGhlcmUuIElmIHRoaXMgVExWIGlzIGFjdHVhbGx5IG5lY2Vzc2FyeSB0byBj b21tdW5pY2F0ZSB3aGF0IHRoZXNlDQo+ID4+PiBhdHRyaWJ1dGVzIGFyZSB0cnlpbmcgdG8gYWNj b21wbGlzaCwgdGhlIGp1c3RpZmljYXRpb24gZm9yIGl0IHNob3VsZA0KPiA+Pj4gYmUgcHJvdmlk ZWQgYW5kIHRoZSBsaW1pdGF0aW9ucyBvbiB3aGVuIHRoaXMgZmllbGQgbWF5IGJlIHVzZWQgYW5k DQo+ID4+PiB3aGF0IGtpbmQgb2YgaWRlbnRpZmllcnMgY2FuIGFwcGVhciBoZXJlIHNob3VsZCBi ZSBzdGF0ZWQuDQoNCk15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgdGhlIElQLVBvcnQtTG9jYWwt SWQgaXMgcmVxdWlyZWQgd2hlbiBpdCBpcyBub3QgcG9zc2libGUgdG8gcmVseSBvbiAgYW4gaW50 ZXJuYWwgSVB2NCBvciBJUHY2IGFkZHJlc3MgdG8gaWRlbnRpZnkgYW4gb25nb2luZyBzZXNzaW9u Lg0KYnV0IGF1dGhvcnMgY2FuIGNsYXJpZnkgdGhlIHVzZSBvZiB0aGlzIGF0dHJpYnV0ZSBhbmQg YWRkcmVzcyB0aGUgcHJpdmFjeSBjb25jZXJucy4NCg0KYnkgdGhlIHdheSwgaWYgbm90IGFscmVh ZHkgc3BvdHRlZDoNCg0KICAgICAgSVAtUG9ydC1JbnQtSVB2Ni1BZGRyIFRMVg0KDQogICAgICAg ICBUaGlzIFRMViBjb250YWlucyBhbiBJUHY0IGFkZHJlc3MgdGhhdCBpcyBhc3NvY2lhdGVkIHdp dGggdGhlDQoNCnMvIFRoaXMgVExWIGNvbnRhaW5zIGFuIElQdjQgYWRkcmVzcy8gVGhpcyBUTFYg Y29udGFpbnMgYW4gSVB2NiBhZGRyZXNzDQoNCk9uIHRoZSA0KSwgSSB3aWxsIGFuc3dlciBpbiBh IHNlcGFyYXRlIGVtYWlsLg0KDQpMaW9uZWwNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gRGXCoDoga2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20NCj4gW21haWx0bzpr YXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBtYXJkaSAxNiBh b8O7dCAyMDE2IDIzOjE2DQo+IMOAwqA6IEFsaXNzYSBDb29wZXINCj4gQ2PCoDogSUVTRzsgZHJh ZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0QGlldGYub3JnOyBNT1JBTkQgTGlvbmVs DQo+IElNVC9PTE47IHJhZGV4dC1jaGFpcnNAaWV0Zi5vcmc7IHJhZGV4dEBpZXRmLm9yZw0KPiBP YmpldMKgOiBSZTogQWxpc3NhIENvb3BlcidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1yYWRleHQt aXAtcG9ydC1yYWRpdXMtZXh0LTExOg0KPiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiAN Cj4gDQo+IA0KPiBTZW50IGZyb20gbXkgaVBob25lDQo+IA0KPiA+IE9uIEF1ZyAxNiwgMjAxNiwg YXQgNDo1NCBQTSwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+IHdyb3RlOg0KPiA+ DQo+ID4NCj4gPj4gT24gQXVnIDE2LCAyMDE2LCBhdCA0OjQxIFBNLCBLYXRobGVlbiBNb3JpYXJ0 eQ0KPiA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+ PiBBbGlzc2EsDQo+ID4+DQo+ID4+IFRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcsIHRo aXMgaXMgaGVscGZ1bC4gIEhvcGVmdWxseSB3ZSB3aWxsDQo+ID4+IGJlIGFibGUgdG8gcmVzb2x2 ZSB0aGlzIHdpdGggdGhlIGVkaXRvcnMgYW5kIHNoZXBoZXJkIGJlZm9yZSBUaHVyc2RheS4NCj4g Pj4gSSBoYXZlIG9uZSBxdWVzdGlvbiBpbiBsaW5lIHRoYXQgbWF5IGhlbHAgd2l0aCB0aGUgcmVz b2x1dGlvbiBmb3IgYXQNCj4gPj4gbGVhc3QgIzEgJiAjNi4NCj4gPj4NCj4gPj4+IE9uIFR1ZSwg QXVnIDE2LCAyMDE2IGF0IDM6MDIgUE0sIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3Lmlu Pg0KPiB3cm90ZToNCj4gPj4+IEFsaXNzYSBDb29wZXIgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2lu ZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ID4+PiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJh ZGl1cy1leHQtMTE6IERpc2N1c3MNCj4gPj4+DQo+ID4+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KPiA+Pj4gYWxsIGVt YWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVl IHRvDQo+ID4+PiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4gUGxlYXNlIHJlZmVyIHRvDQo+ID4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gPj4+IGZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4DQo+ID4+PiB0 Lw0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IC0tDQo+ID4+ PiBESVNDVVNTOg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IC0tDQo+ID4+Pg0KPiA+Pj4gKDEp IEkgZmluZCB0aGUgYWJzZW5jZSBvZiBhbnkgZGVmaW5pdGlvbiBvZiBlcnJvciBoYW5kbGluZyBi ZWhhdmlvcg0KPiA+Pj4gaW4gdGhpcyBkb2N1bWVudCB0byBiZSBhIHByb2JsZW0uIEkgcmVhbGl6 ZSB0aGF0IHRoZSBhdHRyaWJ1dGVzDQo+ID4+PiBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBh cmUgbWVhbnQgdG8gYmUgdHJhbnNtaXR0ZWQgYmV0d2Vlbg0KPiA+Pj4gY29tcG9uZW50cyB0aGF0 IGFyZSBhbGwgb3BlcmF0ZWQgYnkgdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZW50aXR5LA0KPiA+ Pj4gYnV0IGltcGxlbWVudG9ycyBjYW4gc3RpbGwgbWFrZSBtaXN0YWtlcywgYW5kIGZvciB0aG9z ZSBjYXNlcyBpdA0KPiA+Pj4gc2VlbXMgbGlrZSBlcnJvciBoYW5kbGluZyBzaG91bGQgYmUgZGVm aW5lZC4gRm9yIGV4YW1wbGU6DQo+ID4+Pg0KPiA+Pj4gLSBXaGF0IGhhcHBlbnMgaWYgdGhlIEFB QSBzZXJ2ZXIgc2VuZHMgYW4gSVAtUG9ydC1MaW1pdC1JbmZvDQo+ID4+PiBhdHRyaWJ1dGUgd2l0 aCBhIGxhcmdlciBsaW1pdCB0aGFuIHRoZSBDR04gaXMgYWJsZSB0byBhbGxvY2F0ZSB0bw0KPiA+ Pj4gdGhhdCBwYXJ0aWN1bGFyIHVzZXI/IFdoYXQgaXMgdGhlIENHTiBzdXBwb3NlZCB0byBkbyBh bmQgaG93IGlzIHRoYXQNCj4gPj4+IGNvbW11bmljYXRlZCBiYWNrIHRvIHRoZSBBQUEgc2VydmVy Pw0KPiA+Pj4NCj4gPj4+IC0gV2hhdCBoYXBwZW5zIGlmIHRoZSBDR04gc2VuZHMgYW4gSVAtUG9y dC1SYW5nZSBhdHRyaWJ1dGUgdGhhdA0KPiA+Pj4gZW5jb21wYXNzZXMgYSBsYXJnZXIgcmFuZ2Ug dGhhbiBhIHByZXZpb3VzbHkgc2VudCBJUC1Qb3J0LUxpbWl0LUluZm8/DQo+ID4+PiBXaGF0IGlz IHRoZSBBQUEgc2VydmVyIHN1cHBvc2VkIHRvIGRvPw0KPiA+Pj4NCj4gPj4+IC0gV2hhdCBoYXBw ZW5zIGlmIHRoZSBBQUEgc2VydmVyIHNlbmRzIGFuIElQLVBvcnQtRm9yd2FyZGluZy1NYXANCj4g Pj4+IGF0dHJpYnV0ZSB0byBtYXAgYSBwb3J0IHRoYXQgaXMgbm90IHdpdGhpbiB0aGUgcmVxdWVz dGluZyBob3N0J3MNCj4gPj4+IGFsbG9jYXRlZCByYW5nZT8gSXMgdGhlIENHTiBleHBlY3RlZCB0 byBjaGFuZ2UgdGhlIG1hcHBpbmcgYW5kIHNlbmQNCj4gPj4+IGEgQ29BIHdpdGggYSBkaWZmZXJl bnQgSVAtUG9ydC1Gb3J3YXJkaW5nLU1hcCwgb3IgY29tbXVuaWNhdGUgc29tZQ0KPiA+Pj4gc29y dCBvZiBlcnJvciwgb3Igc29tZXRoaW5nIGVsc2U/DQo+ID4+Pg0KPiA+Pj4gVGhlcmUgYXJlIHN1 cmVseSBvdGhlciBlcnJvciBjYXNlcy4gSSB0aGluayBpdCdzIHdvcnRoIGdvaW5nIHRocm91Z2gN Cj4gPj4+IHRoZSB1c2VzIG9mIGVhY2ggYXR0cmlidXRlIGFuZCBzcGVjaWZ5aW5nIGFsbCB0aGUg ZXJyb3IgaGFuZGxpbmcgYmVoYXZpb3IuDQo+ID4+PiBUaGlzIHNlZW1zIGVzcGVjaWFsbHkgaW1w b3J0YW50IHNpbmNlIHBhcnQgb2YgdGhlIG1vdGl2YXRpb24gZm9yDQo+ID4+PiB0aGVzZSBhdHRy aWJ1dGVzIGlzIGZvciBpZGVudGlmaWNhdGlvbiBhbmQgdGhlIGNvbnNlcXVlbmNlcyBvZg0KPiA+ Pj4gZXJyb25lb3VzIGlkZW50aWZpY2F0aW9uIGNvdWxkIGJlIHNldmVyZSBmb3IgdGhlIHVzZXIu IERpc2N1c3Npb24gb2YNCj4gPj4+IHRob3NlIGNvbnNlcXVlbmNlcyBpcyBhbHNvIG1pc3Npbmcg ZnJvbSBTZWN0aW9uIDYuDQo+ID4+DQo+ID4+IEFzIGFuIGFsdGVybmF0aXZlLCBJIHVzdWFsbHkg YXBwcm9hY2ggdGhpcyB0eXBlIG9mIHByb2JsZW0gYXMNCj4gPj4gZGVmaW5pbmcgd2hhdCBpcyBh Y2NlcHRhYmxlIGFuZCBtYWtpbmcgZXZlcnl0aGluZyBlbHNlIGxlc3MNCj4gPj4gYWNjZXB0YWJs ZS4gIFdoaXRlIGxpc3RzIGFyZSBtdWNoIGVhc2llciB0byBtYWludGFpbiBhbmQgZWxpbWluYXRl DQo+ID4+IHRoZSBwb3NzaWJpbGl0eSBvZiBtaXNzaW5nIHNvbWV0aGluZy4gIElmIHlvdSBhbmQg dGhlIFdHIGFncmVlLCBjb3VsZA0KPiA+PiB3ZSBnbyBmb3J3YXJkIHdpdGggdGhhdCBhcHByb2Fj aCBpbnN0ZWFkIG9mIGRlZmluaW5nIGFsbCBwb3NzaWJsZQ0KPiA+PiBwcm9ibGVtcywganVzdCBs aW1pdGluZyB3aGF0IGlzIGFjY2VwdGFibGUgYW5kIG1ha2luZyBldmVyeXRoaW5nIGVsc2UgYW4N Cj4gZXJyb3I/DQo+ID4NCj4gPiBJIHRoaW5rIGl04oCZcyBmaW5lIHRvIHNheSDigJx0aGUgb25s eSBjb3JyZWN0IGJlaGF2aW9yIGlzIFjigJ0gYnV0IHlvdSBzdGlsbCBuZWVkIHRvIHNheQ0KPiB3 aGF0IGltcGxlbWVudGF0aW9ucyBhcmUgZXhwZWN0ZWQgdG8gZG8gd2hlbiBub3QtWCBoYXBwZW5z LiBBbmQgWCB3aWxsIGhhdmUNCj4gZGlmZmVyZW50IHZhbHVlcyBmb3IgdGhlIGRpZmZlcmVudCB1 c2FnZXMgb2YgZWFjaCBvZiB0aGVzZSBhdHRyaWJ1dGVzLg0KPiA+DQo+IEFncmVlZCwgdGhhbmtz Lg0KPiANCj4gS2F0aGxlZW4NCj4gPiBBbGlzc2ENCj4gPg0KPiA+PiBUaGlzIGFwcHJvYWNoDQo+ ID4+IGFwcGxpZXMgdG8gYSBmZXcgb2YgeW91ciBvdGhlciBkaXNjdXNzIHBvaW50cyBhcyB3ZWxs LCBuYW1lbHkgIzIsICM1LA0KPiA+PiBhbmQgdG8gc29tZSBkZWdyZWUgIzMuDQo+ID4+DQo+ID4+ Pg0KPiA+Pj4gKDIpIFNlY3Rpb24gMy4xLjIgc2F5czoNCj4gPj4+DQo+ID4+PiAiRm9yIHBvcnQg YWxsb2NhdGlvbiwgYm90aCBJUC1Qb3J0LVJhbmdlLVN0YXJ0IFRMViBhbmQgSVAtDQo+ID4+PiBQ b3J0LVJhbmdlLUVuZCBUTFYgbXVzdCBiZSBpbmNsdWRlZDsgZm9yIHBvcnQgZGVhbGxvY2F0aW9u LCB0aGUNCj4gPj4+IGluY2x1c2lvbiBvZiB0aGVzZSB0d28gVExWcyBpcyBvcHRpb25hbCBhbmQg aWYgbm90IGluY2x1ZGVkLCBpdA0KPiA+Pj4gaW1wbGllcyB0aGF0IGFsbCBwb3J0cyB0aGF0IGFy ZSBwcmV2aW91c2x5IGFsbG9jYXRlZCBhcmUgbm93DQo+ID4+PiBkZWFsbG9jYXRlZC4iDQo+ID4+ Pg0KPiA+Pj4gSG93IGRvZXMgYW4gQUFBIHNlcnZlciBkaXN0aW5ndWlzaCBiZXR3ZWVuIHBvcnQg YWxsb2NhdGlvbiBhbmQNCj4gPj4+IGRlYWxsb2NhdGlvbiByZXF1ZXN0cyBpZiBhIGRlYWxsb2Nh dGlvbiByZXF1ZXN0IGluY2x1ZGVzIGEgcmFuZ2UNCj4gPj4+IHN0YXJ0IGFuZCByYW5nZSBlbmQ/ IElzIHRoZSBzZXJ2ZXIgc3VwcG9zZWQgdG8gYXNzdW1lIHRoYXQgd2hhdGV2ZXINCj4gPj4+IHJh bmdlIGlzIHNwZWNpZmllZCBieSB0aGUgbW9zdCByZWNlbnRseSByZWNlaXZlZCBJUC1Qb3J0LVJh bmdlDQo+ID4+PiBhdHRyaWJ1dGUgcmVwcmVzZW50cyB0aGUgb25seSByYW5nZSBvZiBhbGxvY2F0 ZWQgcG9ydHMgZm9yIHRoZSBob3N0Pw0KPiA+Pj4gV2hhdCBpcyB0aGUgbWVhbmluZyBvZiBzZW5k aW5nIGFuIElQLVBvcnQtUmFuZ2UgcmVxdWVzdCB3aXRoIG9ubHkgYQ0KPiA+Pj4gc3RhcnQgdmFs dWUgb3IgYW4gZW5kIHZhbHVlIGJ1dCBub3QgYm90aCAoYXMgc2VlbXMgdG8gYmUgYWxsb3dhYmxl IGJ5IHRoZQ0KPiBhYm92ZSk/DQo+ID4+Pg0KPiA+Pj4gKDMpIFRoZSBzcGVjaWZpY2F0aW9uIG9m IElQLVBvcnQtTG9jYWwtSWQgc2VlbXMgdG8gYWxsb3cgZm9yDQo+ID4+PiB1bm5lY2Vzc2FyeSBl eHBvc3VyZSBvZiBwb3RlbnRpYWxseSBzZW5zaXRpdmUgaW5mb3JtYXRpb24uIFRoZXJlIGlzDQo+ ID4+PiBubyBleHBsYW5hdGlvbiBnaXZlbiBmb3Igd2h5IHRoZSBjb21iaW5hdGlvbiBvZiB0aGUg b3RoZXINCj4gPj4+IGlkZW50aWZpZXJzIGluY2x1ZGVkIGluIElQLVBvcnQtUmFuZ2UgYW5kIElQ LVBvcnQtRm9yd2FyZGluZw0KPiA+Pj4gYXR0cmlidXRlcyBpcyBpbnN1ZmZpY2llbnQgdG8gaWRl bnRpZnkgdGhlIGhvc3QgaW4gRFMtRXh0cmEtTGl0ZSBhbmQNCj4gPj4+IExpZ2h0d2VpZ2h0IDRv dmVyNiBjYXNlcy4gQXMgZGVmaW5lZCwgaXQgc291bmRzIGxpa2UgaW1wbGVtZW50YXRpb25zDQo+ ID4+PiBjb3VsZCBwdXQgYmFzaWNhbGx5IGFueSB1c2VyLCBkZXZpY2UsIG9yIGludGVyZmFjZSBp ZGVudGlmaWVyIGluDQo+ID4+PiB0aGVyZS4gSWYgdGhpcyBUTFYgaXMgYWN0dWFsbHkgbmVjZXNz YXJ5IHRvIGNvbW11bmljYXRlIHdoYXQgdGhlc2UNCj4gPj4+IGF0dHJpYnV0ZXMgYXJlIHRyeWlu ZyB0byBhY2NvbXBsaXNoLCB0aGUganVzdGlmaWNhdGlvbiBmb3IgaXQgc2hvdWxkDQo+ID4+PiBi ZSBwcm92aWRlZCBhbmQgdGhlIGxpbWl0YXRpb25zIG9uIHdoZW4gdGhpcyBmaWVsZCBtYXkgYmUg dXNlZCBhbmQNCj4gPj4+IHdoYXQga2luZCBvZiBpZGVudGlmaWVycyBjYW4gYXBwZWFyIGhlcmUg c2hvdWxkIGJlIHN0YXRlZC4NCj4gPj4+DQo+ID4+PiAoNCkgVGhlIHNoZXBoZXJkIHdyaXRlLXVw IGRpc2N1c3NlcyB0d28gZGlmZmVyZW50IGFwcHJvYWNoZXMgdG8NCj4gPj4+IGRlZmluaW5nIHRo ZSBzdWItVExWIHR5cGVzIGFuZCB0aGVuIHNheXM6ICJCb3RoIGFwcHJvYWNoZXMgd2VyZQ0KPiA+ Pj4gY29uc2lkZXJlZCBhcyB2YWxpZCBhbmQgdGhlIFdHIGhhcyBkZWNpZGVkIHRvIGxldCBJQU5B IGRlY2lkZSB3aGF0DQo+ID4+PiB0aGUgYXBwcm9hY2ggaXMgcHJlZmVycmVkIHdoZW4gYWxsb2Nh dGluZyB0aGUgVExWLVR5cGUgZm9yIHRoZQ0KPiA+Pj4gc3ViLVRMVnMgZGVmaW5lZCBpbiB0aGlz IGRvY3VtZW50LiIgVGhpcyBpcyBub3QgYXBwcm9wcmlhdGUuIFRoZQ0KPiA+Pj4gZG9jdW1lbnQg bmVlZHMgdG8gZXhwbGljaXRseSBkZWZpbmUgaG93IHRoZSB0eXBlcyBzaG91bGQgYmUNCj4gPj4+ IGFsbG9jYXRlZCBhbmQgc2hvdWxkIG5vdCBsZWF2ZSB0aGUgZGVjaXNpb24gdG8gSUFOQS4gSSBz ZWUgdGhhdCBJQU5BDQo+ID4+PiBoYXMgYWxyZWFkeSBub3RlZCB0aGF0IFNlY3Rpb24gNy4zIGlz IGFtYmlndW91cyBhYm91dCB0aGlzOyB0aGUgV0cgbmVlZHMgdG8NCj4gbWFrZSBhIGNob2ljZS4N Cj4gPj4NCj4gPj4gVGhhbmsgeW91LCBhbmQgeWVzLCB0aGUgV0cgbmVlZHMgdG8gbWFrZSBhIGRl Y2lzaW9uLg0KPiA+Pg0KPiA+PiBLYXRobGVlbg0KPiA+Pg0KPiA+Pj4NCj4gPj4+ICg1KSBTZWN0 aW9uIDYgc2VlbXMgdG8gYmUgbWlzc2luZyBhIGRpc2N1c3Npb24gb2YgdGhlIGNvbnNlcXVlbmNl cw0KPiA+Pj4gb2YgY29tbXVuaWNhdGluZyBlcnJvbmVvdXMgcG9ydCByYW5nZSBhbmQgcG9ydCBt YXBwaW5nIGluZm9ybWF0aW9uLg0KPiA+Pj4gU2luY2UgcGFydCBvZiB0aGUgbW90aXZhdGlvbiBm b3IgdGhlc2UgYXR0cmlidXRlcyBpcyBpZGVudGlmaWNhdGlvbg0KPiA+Pj4gb2YgdGhlIGhvc3Qs IHRoaXMgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+Pj4gLS0NCj4gPj4+IENPTU1FTlQ6DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4g LS0NCj4gPj4+DQo+ID4+PiAoMSkgV2hhdCBkb2VzIGl0IG1lYW4gZm9yIGFuIElQLVBvcnQtUmFu Z2UgYXR0cmlidXRlIHRvIGhhdmUNCj4gPj4+IElQLVBvcnQtVHlwZQ0KPiA+Pj4gMSBvciAyPyBD YW4gbnVtYmVycyBpbiB0aGUgd2hvbGUgcmFuZ2UgYmUgdXNlZCBmb3IgYW55IG9mIHRoZSBwb3J0 DQo+ID4+PiBvciBpZGVudGlmaWVyIHR5cGVzPyBPciBpcyB0aGUgcmFuZ2UgZXhwZWN0ZWQgdG8g YmUgc3BsaXQgdXAgc29tZWhvdw0KPiA+Pj4gYW1vbmcgdGhlIG11bHRpcGxlIHR5cGVzPyBJIHRo aW5rIHRoaXMgbmVlZHMgdG8gYmUgZXhwbGFpbmVkLg0KPiA+Pj4NCj4gPj4+ICgyKSBJbiA0LjEu NCwgaG93IGRvZXMgdGhlIElTUCBrbm93IHRoYXQgSm9lIGlzIHRyYXZlbGluZz8NCj4gPj4NCj4g Pj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4NCj4gPj4gQmVzdCByZWdhcmRzLA0KPiA+PiBLYXRobGVl bg0KPiA+DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll ZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Sep 6 05:48:53 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B22912B685; Tue, 6 Sep 2016 05:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 0PadCW0ptxWR; Tue, 6 Sep 2016 05:48:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CFB12B801; Tue, 6 Sep 2016 05:31:22 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E1CF822C79A; Tue, 6 Sep 2016 14:31:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B22B92380ED; Tue, 6 Sep 2016 14:31:20 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0301.000; Tue, 6 Sep 2016 14:31:20 +0200 From: To: "kathleen.moriarty.ietf@gmail.com" , Alissa Cooper Thread-Topic: Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHR9/Cwu6n7TFEfE0aWCTw3JOS72qBL68EAgAADpYCAAAXuAIAgjYnQ Date: Tue, 6 Sep 2016 12:31:19 +0000 Message-ID: <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 12:48:46 -0000 SGksDQoNCk9uIHRoZSBzcGVjaWZpYyBkaXNjdXNzaW9uIG9uIElBTkEsIGhlcmUgaXMgbXkgc3Vt bWFyeSBmb3IgbW9yZSBkZXRhaWxzLg0KV2hlbiBkaXNjdXNzZWQgaW4gdGhlIGdyb3VwLCB0d28g dm9pY2VzIChBbGFuIGFuZCBteXNlbGYpIGhhZCB0d28gZGlmZmVyZW50IHN0cm9uZyBwb3NpdGlv bnMuDQpPdGhlciB2b2ljZXMgd2VyZSBuZXV0cmFsIHNheWluZyB0aGF0IGJvdGggY291bGQgd29y aywgd2l0aG91dCBhbnkgcHJlZmVyZW5jZS4gT3RoZXJzIGRpZG4ndCBjYXJlLg0KSW4gb3JkZXIg bm90IHRvIGJsb2NrIHRoZSBwcm9jZXNzLCBpdCB3YXMgY29uY2x1ZGVkIHRoYXQgSUFOQSB3b3Vs ZCBiZSBtYXliZSBtb3JlIGFwcHJvcHJpYXRlIHRvIGRlY2lkZSBpZiBteSBjb25jZXJucyBhYm91 dCB0aGUgcmVnaXN0cnkgbWFuYWdlbWVudCBhcmUgYWxzbyBhbiBpc3N1ZSBmb3IgdGhlbS4gQW5k IGJlY2F1c2UgSUFOQSBpcyBwYXJ0IG9mIHRoZSBJRVNHIHJldmlldyBwcm9jZXNzLCBpdCB3YXMg dGhvdWdodCB0aGF0IGl0IHdhcyBnb29kIHRvIHRoZWlyIGZlZWRiYWNrLCBldmVuIGlmIGl0IG1l YW5zIHRoYXQgd2UgaGF2ZSB0byB1cGRhdGUgdGhlIGRyYWZ0IGFmdGVyd2FyZC4gSUVURiBsYXN0 IGNhbGxzIGFyZSBhbHNvIGZvciB0aGF0IHB1cnBvc2UgSSB0aGluay4NCg0KTm93LCBpbiB0aGUg ZGV0YWlscyAodGV4dCBpcyBzaG9ydCBidXQgaWxsdXN0cmF0ZWQgd2l0aCB0YWJsZXMgZm9yIGNs YXJpZmljYXRpb24gb2YgdGhlIGNvbmNlcm5zKS4NCg0KVGhlIGN1cnJlbnQgcG9zaXRpb24gaW4g dGhlIGRyYWZ0IGlzIHRvIGFsbG9jYXRlIGEgdW5pcXVlIHZhbHVlIHBlciBUTFYsIHN1Y2ggYXM6 DQoNCiAgICAgIE5hbWUgICAgICAgICAgICAgICAgICAgIFZhbHVlICAgICAgTWVhbmluZw0KICAg ICAgLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0gICAgICAtLS0tLS0tDQogICAg ICBJUC1Qb3J0LVR5cGUgICAgICAgICAgICAxICAgICAgICAgc2VlIFNlY3Rpb24gMy4yLjENCiAg ICAgIElQLVBvcnQtTGltaXQgICAgICAgICAgIDIgICAgICAgICBzZWUgU2VjdGlvbiAzLjIuMg0K ICAgICAgSVAtUG9ydC1FeHQtSVB2NC1BZGRyICAgMyAgICAgICAgIHNlZSBTZWN0aW9uIDMuMi4z DQogICAgICBJUC1Qb3J0LUludC1JUHY0LUFkZHIgICA0ICAgICAgICAgc2VlIFNlY3Rpb24gMy4y LjQNCiAgICAgIElQLVBvcnQtSW50LUlQdjYtQWRkciAgIDUgICAgICAgICBzZWUgU2VjdGlvbiAz LjIuNQ0KICAgICAgSVAtUG9ydC1JbnQtUG9ydCAgICAgICAgNiAgICAgICAgIHNlZSBTZWN0aW9u IDMuMi42DQogICAgICBJUC1Qb3J0LUV4dC1Qb3J0ICAgICAgICA3ICAgICAgICAgc2VlIFNlY3Rp b24gMy4yLjcNCiAgICAgIElQLVBvcnQtQWxsb2MgICAgICAgICAgIDggICAgICAgICBzZWUgU2Vj dGlvbiAzLjIuOA0KICAgICAgSVAtUG9ydC1SYW5nZS1TdGFydCAgICAgOSAgICAgICAgIHNlZSBT ZWN0aW9uIDMuMi45DQogICAgICBJUC1Qb3J0LVJhbmdlLUVuZCAgICAgIDEwICAgICAgICAgc2Vl IFNlY3Rpb24gMy4yLjEwDQogICAgICBJUC1Qb3J0LUxvY2FsLUlkICAgICAgIDExICAgICAgICAg c2VlIFNlY3Rpb24gMy4yLjExDQoNCldoaWNoIG1lYW5zIHRoYXQgd2hhdGV2ZXIgdGhlIHBhcmVu dCBhdHRyaWJ1dGUsIHZhbHVlIDEgd2lsbCBoYXZlIHRvIGJlIHJlc2VydmVkIGZvciBJUC1Qb3J0 LCB2YWx1ZSAyIGZvciBJUC1Qb3J0LUxpbWl0LCBldGMuIGV2ZW4gaWYgdGhlc2UgVExWcyBhcmUg bmV2ZXIgdW51c2VkIGluIHRoZXNlIGF0dHJpYnV0ZXMuDQpUaGUgYXJndW1lbnQgZ2l2ZW4gYnkg QWxhbiBpcyB0aGF0ICJhIFRMViBjYWxsZWQgImZvbyIgc2hvdWxkIGhhdmUgdGhlIHNhbWUgVExW LVR5cGUgdmFsdWUgKGUuZy4gMSkgYWNyb3NzIG11bHRpcGxlIHBhcmVudCBUTFZzLiAgVGhlcmUg aXMgZW5vdWdoIHNwYWNlIHRvIGRvIHNwYXJzZSBhbGxvY2F0aW9uLiIgDQoNCkhvd2V2ZXIsIHRo ZSBhbGxvY2F0aW9uIHJ1bGUgZm9yIFRMViBpcyBkZWZpbmVkIGFzIGZvbGxvdyBpbiB0aGUgUkZD NjkyOToNCg0KMTAuMy42LiBBbGxvY2F0aW9uIHdpdGhpbiBhIFRMVg0KDQogICBTcGVjaWZpY2F0 aW9ucyBjYW4gcmVxdWVzdCBhbGxvY2F0aW9uIG9mIEF0dHJpYnV0ZSBUeXBlIHZhbHVlcyB3aXRo aW4NCiAgIGFuIEF0dHJpYnV0ZSBvZiBkYXRhIHR5cGUgVExWLiAgVGhlIGVuY2Fwc3VsYXRpbmcg VExWIGNhbiBiZQ0KICAgYWxsb2NhdGVkIGluIHRoZSBzYW1lIHNwZWNpZmljYXRpb24sIG9yIGl0 IGNhbiBoYXZlIGJlZW4gcHJldmlvdXNseQ0KICAgYWxsb2NhdGVkLg0KDQogICBTcGVjaWZpY2F0 aW9ucyBuZWVkIHRvIHJlcXVlc3QgYWxsb2NhdGlvbiB3aXRoaW4gYSBzcGVjaWZpYyBBdHRyaWJ1 dGUNCiAgIFR5cGUgdmFsdWUgKGUuZy4sICJUWVBFLlRMVi4qIikuICBBbGxvY2F0aW9ucyBhcmUg cGVyZm9ybWVkIGZyb20gdGhlDQogICBzbWFsbGVzdCBVbmFzc2lnbmVkIHZhbHVlLCBwcm9jZWVk aW5nIHRvIHRoZSBsYXJnZXN0IFVuYXNzaWduZWQNCiAgIHZhbHVlLg0KDQpNb3Jlb3ZlciwgaW4g c2VjdGlvbiAyLjMuICAiVExWIERhdGEgVHlwZSIgb2YgdGhlIHNhbWUgUkZDLCBpdCBpcyBzYWlk Og0KDQogICAgICBBcyB3aXRoIHRoZSBFeHRlbmRlZC1UeXBlIGZpZWxkIGRlZmluZWQgYWJvdmUs IHRoZSBUTFYtVHlwZSBpcw0KICAgICAgbWVhbmluZ2Z1bCBvbmx5IHdpdGhpbiB0aGUgY29udGV4 dCBkZWZpbmVkIGJ5ICJUeXBlIiBmaWVsZHMgb2YgdGhlDQogICAgICBlbmNhcHN1bGF0aW5nIEF0 dHJpYnV0ZXMuICBUaGF0IGlzLCB0aGUgZmllbGQgbWF5IGJlIHRob3VnaHQgb2YgYXMNCiAgICAg IGRlZmluaW5nIGEgbmV3IHR5cGUgc3BhY2Ugb2YgdGhlIGZvcm0NCiAgICAgICJUeXBlLkV4dGVu ZGVkLVR5cGUuVExWLVR5cGUiLiAgV2hlcmUgVExWcyBhcmUgbmVzdGVkLCB0aGUgdHlwZQ0KICAg ICAgc3BhY2UgaXMgb2YgdGhlIGZvcm0gIlR5cGUuRXh0ZW5kZWQtVHlwZS5UTFYtVHlwZS5UTFYt VHlwZSIsIGV0Yy4NCg0KRm9sbG93aW5nIHRoZXNlIHJlY29tbWVuZGF0aW9ucywgdGhlIHNlY3Rp b24gNy4zIHNob3VsZCBiZSByZXZpc2VkIGFzIGZvbGxvdywgd2l0aCBhIFRMVi1UeXBlIGRlZmlu ZWQgcGVyIHBhcmVudCBhdHRyaWJ1dGU6DQoNCjcuMy4gIElBTkEgQ29uc2lkZXJhdGlvbnMgb24g TmV3IFJBRElVUyBTdWItYXR0cmlidXRlcw0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gcmVxdWVz dHMgYWxsb2NhdGlvbiBvZiB0aGUgZm9sbG93aW5nIHN1Yi1hdHRyaWJ1dGVzIHdpdGhpbg0KICAg dGhlIGF0dHJpYnV0ZSBJUC1Qb3J0LUxpbWl0LUluZm8gMjQxLlRCRDE6DQoNCiAgICAgIElkZW50 aWZpZXIgICAgICAgICAgICAgICAgICAgICAgTmFtZSAgICAgICAgICAgICAgIA0KICAgICAgLS0t LS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tIA0KICAgICAgMjQxLlRC RDEuMSAgICAgICAgICAgICAgICAgSVAtUG9ydC1UeXBlICANCiAgICAgIDI0MS5UQkQxLjIgICAg ICAgICAgICAgICAgIElQLVBvcnQtTGltaXQgICANCiAgICAgIDI0MS5UQkQxLjMgICAgICAgICAg ICAgICAgIElQLVBvcnQtRXh0LUlQdjQtQWRkcg0KICAgICAyNDEuIFRCRDEuezQtMjUzfSAJVW5h c3NpZ25lZA0KICAgICAyNDUuIFRCRDEuezI1NC0yNTV9CVJlc2VydmVkDQoNCiAgIFRoaXMgc3Bl Y2lmaWNhdGlvbiByZXF1ZXN0cyBhbGxvY2F0aW9uIG9mIHRoZSBmb2xsb3dpbmcgc3ViLWF0dHJp YnV0ZXMgd2l0aGluDQogICB0aGUgYXR0cmlidXRlIElQLVBvcnQtUmFuZ2UgMjQxLlRCRDI6DQoN CiAgICAgIElkZW50aWZpZXIgICAgICAgICAgICAgICAgICAgICAgTmFtZSAgICAgICAgICAgICAg ICAgICANCiAgICAgIC0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLSAg ICAgICAgICAgICAgICANCiAgICAgIDI0MS5UQkQyLjEgICAgICAgICAgICAgICAgIElQLVBvcnQt VHlwZS0xICAgDQogICAgICAyNDEuVEJEMi4yICAgICAgICAgICAgICAgICBJUC1Qb3J0LUV4dC1J UHY0LUFkZHItMQ0KICAgICAgMjQxLlRCRDIuMyAgICAgICAgICAgICAgICAgSVAtUG9ydC1Mb2Nh bC1JZC0xICANCiAgICAgIDI0MS5UQkQyLjQgICAgICAgICAgICAgICAgIElQLVBvcnQtQWxsb2Mg ICANCiAgICAgIDI0MS5UQkQyLjUgICAgICAgICAgICAgICAgIElQLVBvcnQtUmFuZ2UtU3RhcnQN CiAgICAgIDI0MS5UQkQyLjYgICAgICAgICAgICAgICAgIElQLVBvcnQtUmFuZ2UtRW5kICANCiAg ICAgMjQxLiBUQkQyLns3LTI1M30JVW5hc3NpZ25lZA0KICAgICAyNDUuIFRCRDIuezI1NC0yNTV9 CVJlc2VydmVkDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiByZXF1ZXN0cyBhbGxvY2F0aW9uIG9m IHRoZSBmb2xsb3dpbmcgc3ViLWF0dHJpYnV0ZXMgd2l0aGluDQogICB0aGUgYXR0cmlidXRlIElQ LVBvcnQtRm9yd2FyZGluZy1NYXAgMjQxLlRCRDM6DQoNCiAgICAgIFR5cGUgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE5hbWUgICAgICAgICAgICAgICAgICAgDQogICAgICAtLS0tICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tICAgDQogICAgICAyNDEuVEJEMy4xICAgICAg ICAgICAgICAgICBJUC1Qb3J0LVR5cGUtMiANCiAgICAgIDI0MS5UQkQzLjIgICAgICAgICAgICAg ICAgIElQLVBvcnQtRXh0LUlQdjQtQWRkci0yDQogICAgICAyNDEuVEJEMy4zICAgICAgICAgICAg ICAgICBJUC1Qb3J0LUxvY2FsLUlkLTENCiAgICAgIDI0MS5UQkQzLjQgICAgICAgICAgICAgICAg IElQLVBvcnQtSW50LUlQdjQtQWRkciANCiAgICAgIDI0MS5UQkQzLjUgICAgICAgICAgICAgICAg IElQLVBvcnQtSW50LUlQdjYtQWRkciANCiAgICAgIDI0MS5UQkQzLjYgICAgICAgICAgICAgICAg IElQLVBvcnQtSW50LVBvcnQgDQogICAgICAyNDEuVEJEMy43ICAgICAgICAgICAgICAgICBJUC1Q b3J0LUV4dC1Qb3J0DQogICAgIDI0MS4gVEJEMy57OC0yNTN9CVVuYXNzaWduZWQNCiAgICAgMjQ1 LiBUQkQzLnsyNTQtMjU1fQlSZXNlcnZlZA0KDQpIZXJlIGlzIGFuICJleGFtcGxlIiBvZiB3aGF0 IHdvdWxkIGxvb2sgbGlrZSBhZnRlciB0aGUgUmFkaXVzIEF0dHJpYnV0ZSBUeXBlcyByZWdpc3Ry eSBhZnRlciBwdWJsaWNhdGlvbiBvZiB0aGUgbmV3IFJGQy4NCg0KMjQxCQkJRXh0ZW5kZWQtQXR0 cmlidXRlLTEJCVtSRkM2OTI5XQ0KMjQxLjEJCQlGcmFnLVN0YXR1cwkJCVtSRkM3NDk5XQ0KMjQx LjIJCQlQcm94eS1TdGF0ZS1MZW5ndGgJCVtSRkM3NDk5XQ0KDQoyNDEuMwkJCUlQLVBvcnQtTGlt aXQtSW5mbwkJTkVXIFJGQw0KMjQxLjMuMQkJCUlQLVBvcnQtVHlwZS0xCQkJTkVXIFJGQw0KMjQx LjMuMgkJCUlQLVBvcnQtRXh0LUlQdjQtQWRkci0xCSAgICAgICAgICAgICAgIE5FVyBSRkMNCjI0 MS4zLjMJCQlJUC1Qb3J0LUxpbWl0CQkJTkVXIFJGQw0KMjQxLjMuezQtMjUzfQkJVW5hc3NpZ25l ZAkJCU5FVyBSRkMNCjI0NS4zLnsyNTQtMjU1fQlSZXNlcnZlZAkJCU5FVyBSRkMNCg0KMjQxLjQJ CQlJUC1Qb3J0LVJhbmdlCQkJTkVXIFJGQw0KMjQxLjQuMQkJCUlQLVBvcnQtVHlwZS0yCQkJTkVX IFJGQw0KMjQxLjQuMgkJCUlQLVBvcnQtRXh0LUlQdjQtQWRkci0yIAlORVcgUkZDDQoyNDEuNC4z CQkJSVAtUG9ydC1Mb2NhbC1JZC0xCQlORVcgUkZDDQoyNDEuNC40CQkJSVAtUG9ydC1BbGxvYwkJ CU5FVyBSRkMNCjI0MS40LjUJCQlJUC1Qb3J0LVJhbmdlLVN0YXJ0CQlORVcgUkZDDQoyNDEuNC42 CQkJSVAtUG9ydC1SYW5nZS1FbmQJCU5FVyBSRkMNCjI0MS40Lns3LTI1M30JCVVuYXNzaWduZWQJ CQlORVcgUkZDDQoyNDUuNC57MjU0LTI1NX0JUmVzZXJ2ZWQJCQlORVcgUkZDDQoNCjI0MS41CQkJ SVAtUG9ydC1Gb3J3YXJkaW5nLU1hcAlORVcgUkZDDQoyNDEuNS4xCQkJSVAtUG9ydC1UeXBlLTMJ CQlORVcgUkZDDQoyNDEuNS4yCQkJSVBvcnQtRXh0LUlQdjQtQWRkci0zCQlORVcgUkZDDQoyNDEu NS4zCQkJSVAtUG9ydC1Mb2NhbC1JZC0yCQlORVcgUkZDDQoyNDEuNS40CQkJSVAtUG9ydC1JbnQt SVB2NC1BZGRyCQlORVcgUkZDDQoyNDEuNS41CQkJSVAtUG9ydC1JbnQtSVB2Ni1BZGRyCQlORVcg UkZDDQoyNDEuNS42CQkJSVAtUG9ydC1JbnQtUG9ydAkJICAgICAgICAgICAgICAgTkVXIFJGQw0K MjQxLjUuNwkJCUlQLVBvcnQtRXh0LVBvcnQJCU5FVyBSRkMNCjI0MS41Lns4LTI1M30JCVVuYXNz aWduZWQJCQlORVcgUkZDDQoyNDUuNS57MjU0LTI1NX0JUmVzZXJ2ZWQJCQlORVcgUkZDDQoNCjI0 MS57Ni0yNX0JCVVuYXNzaWduZWQJDQoyNDEuMjYJCQlFeHRlbmRlZC1WZW5kb3ItU3BlY2lmaWMt MQlbUkZDNjkyOV0NCjI0MS57MjctMjQwfQkJVW5hc3NpZ25lZAkNCjI0MS57MjQxLTI1NX0JCVJl c2VydmVkCQkJW1JGQzY5MjldDQoNClRoaXMgYXBwcm9hY2ggaXMgc3RyYWlnaHRmb3J3YXJkIGZv ciBJQU5BIGluIHRlcm1zIG9mIGFsbG9jYXRpb24gYW5kIEkgc3RpbGwgZG9uJ3Qgc2VlIHRoZSBy ZWFsIGlzc3VlIGZyb20gYSBkaWN0aW9uYXJ5IHBvaW50IG9mIHZpZXcuDQoNCkluIHRoZSBvdGhl ciBoYW5kLCBoZXJlIGlzIGFuICJleGFtcGxlIiBvZiB3aGF0IHdvdWxkIGxvb2sgbGlrZSB0aGUg cmVnaXN0cnkgaWYgQWxhbidzIHByb3Bvc2FsIGlzIGFjY2VwdGVkLg0KDQoyNDEJCQlFeHRlbmRl ZC1BdHRyaWJ1dGUtMQkJW1JGQzY5MjldDQoyNDEuMQkJCUZyYWctU3RhdHVzCQkJW1JGQzc0OTld DQoyNDEuMgkJCVByb3h5LVN0YXRlLUxlbmd0aAkJW1JGQzc0OTldDQoNCjI0MS4zCQkJSVAtUG9y dC1MaW1pdC1JbmZvCQlORVcgUkZDDQoyNDEuMy4xCQkJSVAtUG9ydC1UeXBlCQkJTkVXIFJGQw0K MjQxLjMuMgkJCUlQLVBvcnQtRXh0LUlQdjQtQWRkcgkgICAgICAgICAgICAgICBORVcgUkZDDQoy NDEuMy4zCQkJSVAtUG9ydC1MaW1pdAkJCU5FVyBSRkMNCjI0MS4zLns0LTExfQkJUmVzZXJ2ZWQJ CQlORVcgUkZDDQoyNDEuMy57MTItMjUzfQkJVW5hc3NpZ25lZAkJCU5FVyBSRkMNCjI0MS4zLnsy NTQtMjU1fQlSZXNlcnZlZAkJCU5FVyBSRkMNCg0KMjQxLjQJCQlJUC1Qb3J0LVJhbmdlCQkJTkVX IFJGQw0KMjQxLjQuMQkJCUlQLVBvcnQtVHlwZQkJCU5FVyBSRkMNCjI0MS40LjIJCQlJUC1Qb3J0 LUV4dC1JUHY0LUFkZHIJIAlORVcgUkZDDQoyNDEuNC4zCQkJUmVzZXJ2ZWQJCQlORVcgUkZDDQoy NDEuNC40CQkJSVAtUG9ydC1Mb2NhbC1JZAkJCU5FVyBSRkMNCjI0MS40LjUJCQlJUC1Qb3J0LUFs bG9jCQkJTkVXIFJGQw0KMjQxLjQuNgkJCUlQLVBvcnQtUmFuZ2UtU3RhcnQJCU5FVyBSRkMNCjI0 MS40LjcJCQlJUC1Qb3J0LVJhbmdlLUVuZAkJTkVXIFJGQw0KMjQxLjQuezgtMTF9CQlSZXNlcnZl ZAkJCU5FVyBSRkMNCjI0MS40LnsxMi0yNTN9CQlVbmFzc2lnbmVkCQkJTkVXIFJGQw0KMjQxLjQu ezI1NC0yNTV9CVJlc2VydmVkCQkJTkVXIFJGQw0KDQoyNDEuNQkJCUlQLVBvcnQtRm9yd2FyZGlu Zy1NYXAJTkVXIFJGQw0KMjQxLjUuMQkJCUlQLVBvcnQtVHlwZQkJCU5FVyBSRkMNCjI0MS41LjIJ CQlJUG9ydC1FeHQtSVB2NC1BZGRyCQlORVcgUkZDDQoyNDEuNS4zCQkJUmVzZXJ2ZWQJCQlORVcg UkZDDQoyNDEuNS40CQkJSVAtUG9ydC1Mb2NhbC1JZAkJCU5FVyBSRkMNCjI0MS41LjUJCQlSZXNl cnZlZAkJCU5FVyBSRkMNCjI0MS41LjYJCQlSZXNlcnZlZAkJCU5FVyBSRkMNCjI0MS41LjcJCQlS ZXNlcnZlZAkJCU5FVyBSRkMNCjI0MS41LjgJCQlJUC1Qb3J0LUludC1JUHY0LUFkZHIJCU5FVyBS RkMNCjI0MS41LjkJCQlJUC1Qb3J0LUludC1JUHY2LUFkZHIJCU5FVyBSRkMNCjI0MS41LjEwCQlJ UC1Qb3J0LUludC1Qb3J0CQkgICAgICAgICAgICAgICBORVcgUkZDDQoyNDEuNS4xMQkJSVAtUG9y dC1FeHQtUG9ydAkJTkVXIFJGQw0KMjQxLjUuezEyLTI1M30JCVVuYXNzaWduZWQJCQlORVcgUkZD DQoyNDEuNS57MjU0LTI1NX0JUmVzZXJ2ZWQJCQlORVcgUkZDDQoNCkFuZCB0aGUgdmFsdWVzIHgu eC57MS0xMX0gd2lsbCBoYXZlIHRvIGJlIHJlc2VydmVkIGZvciBhbnkgbmV3IGF0dHJpYnV0ZSBv ZiB0eXBlICJUTFYiIGRlZmluZWQgaW4gdGhlIHJhbmdlcyAyNDEuezYtMjQwfSwgMjQyLnsxLTI0 MH0sIDI0My57MS0yNDB9LCAyNDQuezEtMjQwfSwgMjQ1LnsxLTI0MH0gYW5kIDI0Ni57MS0yNDB9 Lg0KSXQgd291bGQgYmUgbGlrZSBkZWZpbmluZyBhIG5ldyByZWdpc3RyeSBmb3Igc3ViLVRMVnMu IFRoYXQgaXMsIGluIG15IG9waW5pb24sIGluIGNvbnRyYWRpY3Rpb24gd2l0aCB0aGUgZGVmaW5p dGlvbiBvZiB0aGUgVExWIGRhdGEgdHlwZSBnaXZlbiBpbiBzZWN0aW9uIDcuMyBvZiBSRkM2OTI5 IChzZWUgYWJvdmUpLg0KDQpJIGhvcGUgdGhhdCB0aGlzIGNsYXJpZmllcyBteSBwb2ludC4NCg0K cmVnYXJkcywNCg0KTGlvbmVsDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERl wqA6IGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tDQo+IFttYWlsdG86a2F0aGxlZW4u bW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQo+IEVudm95w6nCoDogbWFyZGkgMTYgYW/Du3QgMjAx NiAyMzoxNg0KPiDDgMKgOiBBbGlzc2EgQ29vcGVyDQo+IENjwqA6IElFU0c7IGRyYWZ0LWlldGYt cmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dEBpZXRmLm9yZzsgTU9SQU5EIExpb25lbA0KPiBJTVQv T0xOOyByYWRleHQtY2hhaXJzQGlldGYub3JnOyByYWRleHRAaWV0Zi5vcmcNCj4gT2JqZXTCoDog UmU6IEFsaXNzYSBDb29wZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQt cmFkaXVzLWV4dC0xMToNCj4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IA0KPiAN Cj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiANCj4gPiBPbiBBdWcgMTYsIDIwMTYsIGF0IDQ6NTQg UE0sIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPiB3cm90ZToNCj4gPg0KPiA+DQo+ ID4+IE9uIEF1ZyAxNiwgMjAxNiwgYXQgNDo0MSBQTSwgS2F0aGxlZW4gTW9yaWFydHkNCj4gPGth dGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gQWxpc3Nh LA0KPiA+Pg0KPiA+PiBUaGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3LCB0aGlzIGlzIGhl bHBmdWwuICBIb3BlZnVsbHkgd2Ugd2lsbA0KPiA+PiBiZSBhYmxlIHRvIHJlc29sdmUgdGhpcyB3 aXRoIHRoZSBlZGl0b3JzIGFuZCBzaGVwaGVyZCBiZWZvcmUgVGh1cnNkYXkuDQo+ID4+IEkgaGF2 ZSBvbmUgcXVlc3Rpb24gaW4gbGluZSB0aGF0IG1heSBoZWxwIHdpdGggdGhlIHJlc29sdXRpb24g Zm9yIGF0DQo+ID4+IGxlYXN0ICMxICYgIzYuDQo+ID4+DQo+ID4+PiBPbiBUdWUsIEF1ZyAxNiwg MjAxNiBhdCAzOjAyIFBNLCBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4NCj4gd3Jv dGU6DQo+ID4+PiBBbGlzc2EgQ29vcGVyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcg0KPiA+Pj4gZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0 LTExOiBEaXNjdXNzDQo+ID4+Pg0KPiA+Pj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0 aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8NCj4gPj4+IGFsbCBlbWFpbCBhZGRy ZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0bw0KPiA+ Pj4gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+IFBsZWFzZSByZWZlciB0bw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4+PiBmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiA+Pj4NCj4g Pj4+DQo+ID4+PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9u cywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ID4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leA0KPiA+Pj4gdC8NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+PiAtLQ0KPiA+Pj4gRElTQ1VT UzoNCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+PiAtLQ0KPiA+Pj4NCj4gPj4+ICgxKSBJIGZpbmQg dGhlIGFic2VuY2Ugb2YgYW55IGRlZmluaXRpb24gb2YgZXJyb3IgaGFuZGxpbmcgYmVoYXZpb3IN Cj4gPj4+IGluIHRoaXMgZG9jdW1lbnQgdG8gYmUgYSBwcm9ibGVtLiBJIHJlYWxpemUgdGhhdCB0 aGUgYXR0cmlidXRlcw0KPiA+Pj4gc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIG1lYW50 IHRvIGJlIHRyYW5zbWl0dGVkIGJldHdlZW4NCj4gPj4+IGNvbXBvbmVudHMgdGhhdCBhcmUgYWxs IG9wZXJhdGVkIGJ5IHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGVudGl0eSwNCj4gPj4+IGJ1dCBp bXBsZW1lbnRvcnMgY2FuIHN0aWxsIG1ha2UgbWlzdGFrZXMsIGFuZCBmb3IgdGhvc2UgY2FzZXMg aXQNCj4gPj4+IHNlZW1zIGxpa2UgZXJyb3IgaGFuZGxpbmcgc2hvdWxkIGJlIGRlZmluZWQuIEZv ciBleGFtcGxlOg0KPiA+Pj4NCj4gPj4+IC0gV2hhdCBoYXBwZW5zIGlmIHRoZSBBQUEgc2VydmVy IHNlbmRzIGFuIElQLVBvcnQtTGltaXQtSW5mbw0KPiA+Pj4gYXR0cmlidXRlIHdpdGggYSBsYXJn ZXIgbGltaXQgdGhhbiB0aGUgQ0dOIGlzIGFibGUgdG8gYWxsb2NhdGUgdG8NCj4gPj4+IHRoYXQg cGFydGljdWxhciB1c2VyPyBXaGF0IGlzIHRoZSBDR04gc3VwcG9zZWQgdG8gZG8gYW5kIGhvdyBp cyB0aGF0DQo+ID4+PiBjb21tdW5pY2F0ZWQgYmFjayB0byB0aGUgQUFBIHNlcnZlcj8NCj4gPj4+ DQo+ID4+PiAtIFdoYXQgaGFwcGVucyBpZiB0aGUgQ0dOIHNlbmRzIGFuIElQLVBvcnQtUmFuZ2Ug YXR0cmlidXRlIHRoYXQNCj4gPj4+IGVuY29tcGFzc2VzIGEgbGFyZ2VyIHJhbmdlIHRoYW4gYSBw cmV2aW91c2x5IHNlbnQgSVAtUG9ydC1MaW1pdC1JbmZvPw0KPiA+Pj4gV2hhdCBpcyB0aGUgQUFB IHNlcnZlciBzdXBwb3NlZCB0byBkbz8NCj4gPj4+DQo+ID4+PiAtIFdoYXQgaGFwcGVucyBpZiB0 aGUgQUFBIHNlcnZlciBzZW5kcyBhbiBJUC1Qb3J0LUZvcndhcmRpbmctTWFwDQo+ID4+PiBhdHRy aWJ1dGUgdG8gbWFwIGEgcG9ydCB0aGF0IGlzIG5vdCB3aXRoaW4gdGhlIHJlcXVlc3RpbmcgaG9z dCdzDQo+ID4+PiBhbGxvY2F0ZWQgcmFuZ2U/IElzIHRoZSBDR04gZXhwZWN0ZWQgdG8gY2hhbmdl IHRoZSBtYXBwaW5nIGFuZCBzZW5kDQo+ID4+PiBhIENvQSB3aXRoIGEgZGlmZmVyZW50IElQLVBv cnQtRm9yd2FyZGluZy1NYXAsIG9yIGNvbW11bmljYXRlIHNvbWUNCj4gPj4+IHNvcnQgb2YgZXJy b3IsIG9yIHNvbWV0aGluZyBlbHNlPw0KPiA+Pj4NCj4gPj4+IFRoZXJlIGFyZSBzdXJlbHkgb3Ro ZXIgZXJyb3IgY2FzZXMuIEkgdGhpbmsgaXQncyB3b3J0aCBnb2luZyB0aHJvdWdoDQo+ID4+PiB0 aGUgdXNlcyBvZiBlYWNoIGF0dHJpYnV0ZSBhbmQgc3BlY2lmeWluZyBhbGwgdGhlIGVycm9yIGhh bmRsaW5nIGJlaGF2aW9yLg0KPiA+Pj4gVGhpcyBzZWVtcyBlc3BlY2lhbGx5IGltcG9ydGFudCBz aW5jZSBwYXJ0IG9mIHRoZSBtb3RpdmF0aW9uIGZvcg0KPiA+Pj4gdGhlc2UgYXR0cmlidXRlcyBp cyBmb3IgaWRlbnRpZmljYXRpb24gYW5kIHRoZSBjb25zZXF1ZW5jZXMgb2YNCj4gPj4+IGVycm9u ZW91cyBpZGVudGlmaWNhdGlvbiBjb3VsZCBiZSBzZXZlcmUgZm9yIHRoZSB1c2VyLiBEaXNjdXNz aW9uIG9mDQo+ID4+PiB0aG9zZSBjb25zZXF1ZW5jZXMgaXMgYWxzbyBtaXNzaW5nIGZyb20gU2Vj dGlvbiA2Lg0KPiA+Pg0KPiA+PiBBcyBhbiBhbHRlcm5hdGl2ZSwgSSB1c3VhbGx5IGFwcHJvYWNo IHRoaXMgdHlwZSBvZiBwcm9ibGVtIGFzDQo+ID4+IGRlZmluaW5nIHdoYXQgaXMgYWNjZXB0YWJs ZSBhbmQgbWFraW5nIGV2ZXJ5dGhpbmcgZWxzZSBsZXNzDQo+ID4+IGFjY2VwdGFibGUuICBXaGl0 ZSBsaXN0cyBhcmUgbXVjaCBlYXNpZXIgdG8gbWFpbnRhaW4gYW5kIGVsaW1pbmF0ZQ0KPiA+PiB0 aGUgcG9zc2liaWxpdHkgb2YgbWlzc2luZyBzb21ldGhpbmcuICBJZiB5b3UgYW5kIHRoZSBXRyBh Z3JlZSwgY291bGQNCj4gPj4gd2UgZ28gZm9yd2FyZCB3aXRoIHRoYXQgYXBwcm9hY2ggaW5zdGVh ZCBvZiBkZWZpbmluZyBhbGwgcG9zc2libGUNCj4gPj4gcHJvYmxlbXMsIGp1c3QgbGltaXRpbmcg d2hhdCBpcyBhY2NlcHRhYmxlIGFuZCBtYWtpbmcgZXZlcnl0aGluZyBlbHNlIGFuDQo+IGVycm9y Pw0KPiA+DQo+ID4gSSB0aGluayBpdOKAmXMgZmluZSB0byBzYXkg4oCcdGhlIG9ubHkgY29ycmVj dCBiZWhhdmlvciBpcyBY4oCdIGJ1dCB5b3Ugc3RpbGwgbmVlZCB0byBzYXkNCj4gd2hhdCBpbXBs ZW1lbnRhdGlvbnMgYXJlIGV4cGVjdGVkIHRvIGRvIHdoZW4gbm90LVggaGFwcGVucy4gQW5kIFgg d2lsbCBoYXZlDQo+IGRpZmZlcmVudCB2YWx1ZXMgZm9yIHRoZSBkaWZmZXJlbnQgdXNhZ2VzIG9m IGVhY2ggb2YgdGhlc2UgYXR0cmlidXRlcy4NCj4gPg0KPiBBZ3JlZWQsIHRoYW5rcy4NCj4gDQo+ IEthdGhsZWVuDQo+ID4gQWxpc3NhDQo+ID4NCj4gPj4gVGhpcyBhcHByb2FjaA0KPiA+PiBhcHBs aWVzIHRvIGEgZmV3IG9mIHlvdXIgb3RoZXIgZGlzY3VzcyBwb2ludHMgYXMgd2VsbCwgbmFtZWx5 ICMyLCAjNSwNCj4gPj4gYW5kIHRvIHNvbWUgZGVncmVlICMzLg0KPiA+Pg0KPiA+Pj4NCj4gPj4+ ICgyKSBTZWN0aW9uIDMuMS4yIHNheXM6DQo+ID4+Pg0KPiA+Pj4gIkZvciBwb3J0IGFsbG9jYXRp b24sIGJvdGggSVAtUG9ydC1SYW5nZS1TdGFydCBUTFYgYW5kIElQLQ0KPiA+Pj4gUG9ydC1SYW5n ZS1FbmQgVExWIG11c3QgYmUgaW5jbHVkZWQ7IGZvciBwb3J0IGRlYWxsb2NhdGlvbiwgdGhlDQo+ ID4+PiBpbmNsdXNpb24gb2YgdGhlc2UgdHdvIFRMVnMgaXMgb3B0aW9uYWwgYW5kIGlmIG5vdCBp bmNsdWRlZCwgaXQNCj4gPj4+IGltcGxpZXMgdGhhdCBhbGwgcG9ydHMgdGhhdCBhcmUgcHJldmlv dXNseSBhbGxvY2F0ZWQgYXJlIG5vdw0KPiA+Pj4gZGVhbGxvY2F0ZWQuIg0KPiA+Pj4NCj4gPj4+ IEhvdyBkb2VzIGFuIEFBQSBzZXJ2ZXIgZGlzdGluZ3Vpc2ggYmV0d2VlbiBwb3J0IGFsbG9jYXRp b24gYW5kDQo+ID4+PiBkZWFsbG9jYXRpb24gcmVxdWVzdHMgaWYgYSBkZWFsbG9jYXRpb24gcmVx dWVzdCBpbmNsdWRlcyBhIHJhbmdlDQo+ID4+PiBzdGFydCBhbmQgcmFuZ2UgZW5kPyBJcyB0aGUg c2VydmVyIHN1cHBvc2VkIHRvIGFzc3VtZSB0aGF0IHdoYXRldmVyDQo+ID4+PiByYW5nZSBpcyBz cGVjaWZpZWQgYnkgdGhlIG1vc3QgcmVjZW50bHkgcmVjZWl2ZWQgSVAtUG9ydC1SYW5nZQ0KPiA+ Pj4gYXR0cmlidXRlIHJlcHJlc2VudHMgdGhlIG9ubHkgcmFuZ2Ugb2YgYWxsb2NhdGVkIHBvcnRz IGZvciB0aGUgaG9zdD8NCj4gPj4+IFdoYXQgaXMgdGhlIG1lYW5pbmcgb2Ygc2VuZGluZyBhbiBJ UC1Qb3J0LVJhbmdlIHJlcXVlc3Qgd2l0aCBvbmx5IGENCj4gPj4+IHN0YXJ0IHZhbHVlIG9yIGFu IGVuZCB2YWx1ZSBidXQgbm90IGJvdGggKGFzIHNlZW1zIHRvIGJlIGFsbG93YWJsZSBieSB0aGUN Cj4gYWJvdmUpPw0KPiA+Pj4NCj4gPj4+ICgzKSBUaGUgc3BlY2lmaWNhdGlvbiBvZiBJUC1Qb3J0 LUxvY2FsLUlkIHNlZW1zIHRvIGFsbG93IGZvcg0KPiA+Pj4gdW5uZWNlc3NhcnkgZXhwb3N1cmUg b2YgcG90ZW50aWFsbHkgc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiBUaGVyZSBpcw0KPiA+Pj4gbm8g ZXhwbGFuYXRpb24gZ2l2ZW4gZm9yIHdoeSB0aGUgY29tYmluYXRpb24gb2YgdGhlIG90aGVyDQo+ ID4+PiBpZGVudGlmaWVycyBpbmNsdWRlZCBpbiBJUC1Qb3J0LVJhbmdlIGFuZCBJUC1Qb3J0LUZv cndhcmRpbmcNCj4gPj4+IGF0dHJpYnV0ZXMgaXMgaW5zdWZmaWNpZW50IHRvIGlkZW50aWZ5IHRo ZSBob3N0IGluIERTLUV4dHJhLUxpdGUgYW5kDQo+ID4+PiBMaWdodHdlaWdodCA0b3ZlcjYgY2Fz ZXMuIEFzIGRlZmluZWQsIGl0IHNvdW5kcyBsaWtlIGltcGxlbWVudGF0aW9ucw0KPiA+Pj4gY291 bGQgcHV0IGJhc2ljYWxseSBhbnkgdXNlciwgZGV2aWNlLCBvciBpbnRlcmZhY2UgaWRlbnRpZmll ciBpbg0KPiA+Pj4gdGhlcmUuIElmIHRoaXMgVExWIGlzIGFjdHVhbGx5IG5lY2Vzc2FyeSB0byBj b21tdW5pY2F0ZSB3aGF0IHRoZXNlDQo+ID4+PiBhdHRyaWJ1dGVzIGFyZSB0cnlpbmcgdG8gYWNj b21wbGlzaCwgdGhlIGp1c3RpZmljYXRpb24gZm9yIGl0IHNob3VsZA0KPiA+Pj4gYmUgcHJvdmlk ZWQgYW5kIHRoZSBsaW1pdGF0aW9ucyBvbiB3aGVuIHRoaXMgZmllbGQgbWF5IGJlIHVzZWQgYW5k DQo+ID4+PiB3aGF0IGtpbmQgb2YgaWRlbnRpZmllcnMgY2FuIGFwcGVhciBoZXJlIHNob3VsZCBi ZSBzdGF0ZWQuDQo+ID4+Pg0KPiA+Pj4gKDQpIFRoZSBzaGVwaGVyZCB3cml0ZS11cCBkaXNjdXNz ZXMgdHdvIGRpZmZlcmVudCBhcHByb2FjaGVzIHRvDQo+ID4+PiBkZWZpbmluZyB0aGUgc3ViLVRM ViB0eXBlcyBhbmQgdGhlbiBzYXlzOiAiQm90aCBhcHByb2FjaGVzIHdlcmUNCj4gPj4+IGNvbnNp ZGVyZWQgYXMgdmFsaWQgYW5kIHRoZSBXRyBoYXMgZGVjaWRlZCB0byBsZXQgSUFOQSBkZWNpZGUg d2hhdA0KPiA+Pj4gdGhlIGFwcHJvYWNoIGlzIHByZWZlcnJlZCB3aGVuIGFsbG9jYXRpbmcgdGhl IFRMVi1UeXBlIGZvciB0aGUNCj4gPj4+IHN1Yi1UTFZzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dC4iIFRoaXMgaXMgbm90IGFwcHJvcHJpYXRlLiBUaGUNCj4gPj4+IGRvY3VtZW50IG5lZWRzIHRv IGV4cGxpY2l0bHkgZGVmaW5lIGhvdyB0aGUgdHlwZXMgc2hvdWxkIGJlDQo+ID4+PiBhbGxvY2F0 ZWQgYW5kIHNob3VsZCBub3QgbGVhdmUgdGhlIGRlY2lzaW9uIHRvIElBTkEuIEkgc2VlIHRoYXQg SUFOQQ0KPiA+Pj4gaGFzIGFscmVhZHkgbm90ZWQgdGhhdCBTZWN0aW9uIDcuMyBpcyBhbWJpZ3Vv dXMgYWJvdXQgdGhpczsgdGhlIFdHIG5lZWRzIHRvDQo+IG1ha2UgYSBjaG9pY2UuDQo+ID4+DQo+ ID4+IFRoYW5rIHlvdSwgYW5kIHllcywgdGhlIFdHIG5lZWRzIHRvIG1ha2UgYSBkZWNpc2lvbi4N Cj4gPj4NCj4gPj4gS2F0aGxlZW4NCj4gPj4NCj4gPj4+DQo+ID4+PiAoNSkgU2VjdGlvbiA2IHNl ZW1zIHRvIGJlIG1pc3NpbmcgYSBkaXNjdXNzaW9uIG9mIHRoZSBjb25zZXF1ZW5jZXMNCj4gPj4+ IG9mIGNvbW11bmljYXRpbmcgZXJyb25lb3VzIHBvcnQgcmFuZ2UgYW5kIHBvcnQgbWFwcGluZyBp bmZvcm1hdGlvbi4NCj4gPj4+IFNpbmNlIHBhcnQgb2YgdGhlIG1vdGl2YXRpb24gZm9yIHRoZXNl IGF0dHJpYnV0ZXMgaXMgaWRlbnRpZmljYXRpb24NCj4gPj4+IG9mIHRoZSBob3N0LCB0aGlzIG5l ZWRzIHRvIGJlIGRpc2N1c3NlZC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g Pj4+IC0tDQo+ID4+PiBDT01NRU5UOg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IC0tDQo+ID4+ Pg0KPiA+Pj4gKDEpIFdoYXQgZG9lcyBpdCBtZWFuIGZvciBhbiBJUC1Qb3J0LVJhbmdlIGF0dHJp YnV0ZSB0byBoYXZlDQo+ID4+PiBJUC1Qb3J0LVR5cGUNCj4gPj4+IDEgb3IgMj8gQ2FuIG51bWJl cnMgaW4gdGhlIHdob2xlIHJhbmdlIGJlIHVzZWQgZm9yIGFueSBvZiB0aGUgcG9ydA0KPiA+Pj4g b3IgaWRlbnRpZmllciB0eXBlcz8gT3IgaXMgdGhlIHJhbmdlIGV4cGVjdGVkIHRvIGJlIHNwbGl0 IHVwIHNvbWVob3cNCj4gPj4+IGFtb25nIHRoZSBtdWx0aXBsZSB0eXBlcz8gSSB0aGluayB0aGlz IG5lZWRzIHRvIGJlIGV4cGxhaW5lZC4NCj4gPj4+DQo+ID4+PiAoMikgSW4gNC4xLjQsIGhvdyBk b2VzIHRoZSBJU1Aga25vdyB0aGF0IEpvZSBpcyB0cmF2ZWxpbmc/DQo+ID4+DQo+ID4+DQo+ID4+ DQo+ID4+IC0tDQo+ID4+DQo+ID4+IEJlc3QgcmVnYXJkcywNCj4gPj4gS2F0aGxlZW4NCj4gPg0K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Sep 6 06:30:36 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B8C12B1D7; Tue, 6 Sep 2016 06:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 ACaiuyM8RfyI; Tue, 6 Sep 2016 06:30:26 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 957F412B1D2; Tue, 6 Sep 2016 06:16:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id B35241E9A; Tue, 6 Sep 2016 13:16:01 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU2fhIqfTCxN; Tue, 6 Sep 2016 13:16:01 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id A3E9E80C; Tue, 6 Sep 2016 13:16:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Tue, 6 Sep 2016 09:15:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , Alissa Cooper , "kathleen.moriarty.ietf@gmail.com" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 13:30:28 -0000 On Sep 6, 2016, at 8:31 AM, lionel.morand@orange.com wrote: > Which means that whatever the parent attribute, value 1 will have to = be reserved for IP-Port, value 2 for IP-Port-Limit, etc. even if these = TLVs are never unused in these attributes. > The argument given by Alan is that "a TLV called "foo" should have the = same TLV-Type value (e.g. 1) across multiple parent TLVs. There is = enough space to do sparse allocation."=20 In this draft, yes. Where the same sub-TLVs are used in multiple = different parent TLVs. It's not a hard & fast recommendation. It's just one of the little = things that would be nice, if it can be done. > Following these recommendations, the section 7.3 should be revised as = follow, with a TLV-Type defined per parent attribute: That needs to be done, as IANA requires very specific instructions. My $0.02 is that I'd like to see: IP-Port-Type-Parent-A have the same "TLV-Type" value as = IP-Port-Type-Parent-B. > And the values x.x.{1-11} will have to be reserved for any new = attribute of type "TLV" defined in the ranges 241.{6-240}, 242.{1-240}, = 243.{1-240}, 244.{1-240}, 245.{1-240} and 246.{1-240}. That's not what I'm saying. > It would be like defining a new registry for sub-TLVs. That is, in my = opinion, in contradiction with the definition of the TLV data type given = in section 7.3 of RFC6929 (see above). I would be in for of a new registry for sub-TLVs, but only where those = sub-TLVs are re-used a lot. As an example, let's say we had firewall rules defined in RADIUS TLVs. = Each firewall rule can specify a src/dst IP/port, for 4 different = fields. The firewall rules have an "input" set, for packets destined = locally, and an "output" set, for packets destined remotely. Let's say we have the following definitions for "input" attributes. = I'll omit numbers for clarity, but assume that order matters: INPUT SRC-IP-Input DST-IP-Input SRC-Port-Input DST-Port-Input We need to define something similar for the output rules. We could do = this: OUTPUT SRC-IP-Output DST-IP-Output SRC-Port-Output DST-Port-Output Which is nice. The sub-TLVs have the same order. Or, if numbering doesn't matter, we could do: OUTPUT SRC-Port-Output DST-Port-Output SRC-IP-Output DST-IP-Output Or: OUTPUT SRC-Port-Output SRC-IP-Output DST-IP-Output DST-Port-Output I think that either of these last two options is objectively worse = than the first one. Note that I'm not suggesting that *all* attributes have these 4 = sub-TLVs defined. Just the attributes which define firewall rules. In this case, there are multiple parent attributes which define = essentially the same sub-TLVs. It would be nice to be able to re-use = these these sub-TLVs, without having multiple different definitions for = them. I hope that clarifies things. Alan DeKok. From nobody Tue Sep 6 08:03:53 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2976C12B3C3; Tue, 6 Sep 2016 08:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Up3n-PuN60H0; Tue, 6 Sep 2016 08:03:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A1012B3A1; Tue, 6 Sep 2016 08:03:46 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5AAB33B426F; Tue, 6 Sep 2016 17:03:45 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.42]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2C5862380BD; Tue, 6 Sep 2016 17:03:45 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0301.000; Tue, 6 Sep 2016 17:03:44 +0200 From: To: Alan DeKok Thread-Topic: =?iso-8859-1?Q?RE=A0:_Re:_[radext]_Alissa_Cooper's_Discuss_on_draft-ietf-?= =?iso-8859-1?Q?radext-ip-port-radius-ext-11:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHSCE/cp8Isvqe0LUuPSPGEr4QoVw== Date: Tue, 6 Sep 2016 15:03:44 +0000 Message-ID: <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup>, <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> In-Reply-To: <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01F9F961OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , Alissa Cooper , "kathleen.moriarty.ietf@gmail.com" , IESG , "radext-chairs@ietf.org" Subject: [radext] =?iso-8859-1?q?RE=A0=3A_Re=3A__Alissa_Cooper=27s_Discuss?= =?iso-8859-1?q?_on_draft-ietf-radext-ip-port-radius-ext-11=3A_=28with_DIS?= =?iso-8859-1?q?CUSS_and_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 15:03:52 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01F9F961OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alan, " In this case, there are multiple parent attributes which define essential= ly the same sub-TLVs. It would be nice to be able to re-use these these su= b-TLVs, without having multiple different definitions for them." How do you know that a newly defined sub-TLV will/may be reused or not in o= ther (future) parent attributes? In the document describing the new attribute, you may have a clear idea abo= ut the use in multiple parent attributes for one sub-TLV (Foo) and you may = consider that another sub-TLV (Bar) will be used only once. But tomorrow, f= or another purpose, the sub-TLV Bar appears to be really useful and it is d= ecided to use it in multiple (new) attributes. How will you ensure that the same value can be reused for Bar if not reserv= ed? Regards, Lionel Le 6 sept. 2016 15:16, Alan DeKok a =E9crit : On Sep 6, 2016, at 8:31 AM, lionel.morand@orange.com wrote: > Which means that whatever the parent attribute, value 1 will have to be r= eserved for IP-Port, value 2 for IP-Port-Limit, etc. even if these TLVs are= never unused in these attributes. > The argument given by Alan is that "a TLV called "foo" should have the sa= me TLV-Type value (e.g. 1) across multiple parent TLVs. There is enough sp= ace to do sparse allocation." In this draft, yes. Where the same sub-TLVs are used in multiple differe= nt parent TLVs. It's not a hard & fast recommendation. It's just one of the little thing= s that would be nice, if it can be done. > Following these recommendations, the section 7.3 should be revised as fol= low, with a TLV-Type defined per parent attribute: That needs to be done, as IANA requires very specific instructions. My $0.02 is that I'd like to see: IP-Port-Type-Parent-A have the same "TLV-Type" value as IP-Port-Type-Parent= -B. > And the values x.x.{1-11} will have to be reserved for any new attribute = of type "TLV" defined in the ranges 241.{6-240}, 242.{1-240}, 243.{1-240}, = 244.{1-240}, 245.{1-240} and 246.{1-240}. That's not what I'm saying. > It would be like defining a new registry for sub-TLVs. That is, in my opi= nion, in contradiction with the definition of the TLV data type given in se= ction 7.3 of RFC6929 (see above). I would be in for of a new registry for sub-TLVs, but only where those su= b-TLVs are re-used a lot. As an example, let's say we had firewall rules defined in RADIUS TLVs. E= ach firewall rule can specify a src/dst IP/port, for 4 different fields. T= he firewall rules have an "input" set, for packets destined locally, and an= "output" set, for packets destined remotely. Let's say we have the following definitions for "input" attributes. I'll= omit numbers for clarity, but assume that order matters: INPUT SRC-IP-Input DST-IP-Input SRC-Port-Input DST-Port-Input We need to define something similar for the output rules. We could do th= is: OUTPUT SRC-IP-Output DST-IP-Output SRC-Port-Output DST-Port-Output Which is nice. The sub-TLVs have the same order. Or, if numbering doesn't matter, we could do: OUTPUT SRC-Port-Output DST-Port-Output SRC-IP-Output DST-IP-Output Or: OUTPUT SRC-Port-Output SRC-IP-Output DST-IP-Output DST-Port-Output I think that either of these last two options is objectively worse than t= he first one. Note that I'm not suggesting that *all* attributes have these 4 sub-TLVs = defined. Just the attributes which define firewall rules. In this case, there are multiple parent attributes which define essential= ly the same sub-TLVs. It would be nice to be able to re-use these these su= b-TLVs, without having multiple different definitions for them. I hope that clarifies things. Alan DeKok. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E01F9F961OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Alan,

" In this case, there are multiple parent attributes which define= essentially the same sub-TLVs.  It would be nice to be able to re-use= these these sub-TLVs, without having multiple different definitions for th= em."

How do you know that a newly defined sub-TLV will/may be reused or not in o= ther (future) parent attributes?

In the document describing the new attribute, you may have a clear idea abo= ut the use in multiple parent attributes for one sub-TLV (Foo) and you may = consider that another sub-TLV (Bar) will be used only once. But tomorrow, f= or another purpose, the sub-TLV Bar appears to be really useful and it is decided to use it in multiple (n= ew) attributes.

How will you ensure that the same value can be reused for Bar if not reserv= ed?

Regards,

Lionel

Le 6 sept. 2016 15:16, Alan DeKok <aland@deployin= gradius.com> a =E9crit :
On Sep 6, 2016, at 8:31 AM, lionel.morand@orange.c= om wrote:
> Which means that whatever the parent attribute, value 1 will have to b= e reserved for IP-Port, value 2 for IP-Port-Limit, etc. even if these TLVs = are never unused in these attributes.
> The argument given by Alan is that "a TLV called "foo" = should have the same TLV-Type value (e.g. 1) across multiple parent TLVs.&n= bsp; There is enough space to do sparse allocation."

  In this draft, yes.  Where the same sub-TLVs are used in multip= le different parent TLVs.

  It's not a hard & fast recommendation.  It's just one of th= e little things that would be nice, if it can be done.

> Following these recommendations, the section 7.3 should be revised as = follow, with a TLV-Type defined per parent attribute:

  That needs to be done, as IANA requires very specific instructions.<= br>
  My $0.02 is that I'd like to see:

IP-Port-Type-Parent-A have the same "TLV-Type" value as IP-Port-T= ype-Parent-B.

> And the values x.x.{1-11} will have to be reserved for any new attribu= te of type "TLV" defined in the ranges 241.{6-240}, 242.{1-240}, = 243.{1-240}, 244.{1-240}, 245.{1-240} and 246.{1-240}.

  That's not what I'm saying.

> It would be like defining a new registry for sub-TLVs. That is, in my = opinion, in contradiction with the definition of the TLV data type given in= section 7.3 of RFC6929 (see above).

  I would be in for of a new registry for sub-TLVs, but only where tho= se sub-TLVs are re-used a lot.

  As an example, let's say we had firewall rules defined in RADIUS TLV= s.  Each firewall rule can specify a src/dst IP/port, for 4 different = fields.  The firewall rules have an "input" set, for packets= destined locally, and an "output" set, for packets destined remotely.

  Let's say we have the following definitions for "input" at= tributes.  I'll omit numbers for clarity, but assume that order matter= s:

INPUT
        SRC-IP-Input
        DST-IP-Input
        SRC-Port-Input
        DST-Port-Input

  We need to define something similar for the output rules.  We c= ould do this:

OUTPUT
        SRC-IP-Output
        DST-IP-Output
        SRC-Port-Output
        DST-Port-Output

  Which is nice.  The sub-TLVs have the same order.

  Or, if numbering doesn't matter, we could do:

OUTPUT
        SRC-Port-Output
        DST-Port-Output
        SRC-IP-Output
        DST-IP-Output

  Or:

OUTPUT
        SRC-Port-Output
        SRC-IP-Output
        DST-IP-Output
        DST-Port-Output

  I think that either of these last two options is objectively worse t= han the first one.

  Note that I'm not suggesting that *all* attributes have these 4 sub-= TLVs defined.  Just the attributes which define firewall rules.

  In this case, there are multiple parent attributes which define esse= ntially the same sub-TLVs.  It would be nice to be able to re-use thes= e these sub-TLVs, without having multiple different definitions for them.
  I hope that clarifies things.

  Alan DeKok.

 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E01F9F961OPEXCLILM43corp_-- From nobody Tue Sep 6 08:16:01 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971E812B6E4; Tue, 6 Sep 2016 08:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 wtWnKRM4pbNi; Tue, 6 Sep 2016 08:15:46 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id AD27612B58B; Tue, 6 Sep 2016 08:11:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 11458C37; Tue, 6 Sep 2016 15:11:16 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VztpDJY8o3p6; Tue, 6 Sep 2016 15:11:15 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 23ECF91D; Tue, 6 Sep 2016 15:11:15 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Tue, 6 Sep 2016 11:11:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , Alissa Cooper , "kathleen.moriarty.ietf@gmail.com" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 15:15:53 -0000 On Sep 6, 2016, at 11:03 AM, = wrote: > " In this case, there are multiple parent attributes which define = essentially the same sub-TLVs. It would be nice to be able to re-use = these these sub-TLVs, without having multiple different definitions for = them."=20 >=20 > How do you know that a newly defined sub-TLV will/may be reused or not = in other (future) parent attributes?=20 You know that the sub-TLVs are re-used in the current spec. Future = attributes are largely a future problem. > In the document describing the new attribute, you may have a clear = idea about the use in multiple parent attributes for one sub-TLV (Foo) = and you may consider that another sub-TLV (Bar) will be used only once. = But tomorrow, for another purpose, the sub-TLV Bar appears to be really = useful and it is decided to use it in multiple (new) attributes.=20 >=20 > How will you ensure that the same value can be reused for Bar if not = reserved?=20 Which is why I agreed with the idea to create a registry for the = sub-TLVs. Alan DeKok. From nobody Tue Sep 6 08:42:38 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA38A12B7CE for ; Tue, 6 Sep 2016 08:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 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, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 FW7D2xrq_m5A for ; Tue, 6 Sep 2016 08:42:26 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 012CA12B657 for ; Tue, 6 Sep 2016 08:22:27 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-03v.sys.comcast.net with SMTP id hIBvb4TQu8GkChIChbNKjy; Tue, 06 Sep 2016 15:22:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1473175347; bh=q4lY2IaD/gH/2lNfHPp6cFHcPOEyU8+f+lNw+5D2HlQ=; h=Received:Received:Date:From:To:Message-ID:Subject:MIME-Version: Content-Type; b=fnI/mq7xC6d0E9zSfUkmffAmtX7kxORwdn49hkut+sgWdU6P/QBnntcTyAbt18ub2 q6HbgzlDOdCL4PWKyKc+EuJ7zYsFyqcFaji4fHANOKx6QCOiFCA4ALdPOhe4EI/E7H i/Qf6ubVHI/hngK5iHY894u9TjeIr5Dh/kpr0gcZQA1lN7dJAs3jMmvSfhriWeMUV9 7tu1FQczS2Xt6jJpotcW3SxFBN3rrBAWy0N23aQ888EKpbHWzcb2rNnzcW/efNX42M lHBLTVbQucNpEZtRsfYO9HsMFY+NN69wkkfq25cxazVzLUR1JecIO5L4UemgD29Ae/ eiNv9PQPlTMrA== Received: from resmail-ch2-375v.sys.comcast.net ([162.150.49.154]) by resomta-ch2-10v.sys.comcast.net with SMTP id hICgbDtZZqnakhICgbPVcu; Tue, 06 Sep 2016 15:22:27 +0000 Date: Tue, 6 Sep 2016 15:22:26 +0000 (UTC) From: "David B. Nelson" To: lionel morand Message-ID: <1665923093.11596755.1473175346518.JavaMail.zimbra@comcast.net> In-Reply-To: <17466_1473152611_57CE8663_17466_5602_1_6B7134B31289DC4FAF731D844122B36E01F9ECE4@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <17466_1473152611_57CE8663_17466_5602_1_6B7134B31289DC4FAF731D844122B36E01F9ECE4@OPEXCLILM43.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [::ffff:73.47.77.230] X-Mailer: Zimbra 8.0.7_GA_6031 (ZimbraWebClient - SAF9.1 (Mac)/8.0.7_GA_6031) Thread-Topic: Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHR9/Cwu6n7TFEfE0aWCTw3JOS72qBL68EAgAADpYCAAAXuAIAfD2BwqSufjMY= X-CMAE-Envelope: MS4wfKLiCNHNGmVug/TfrI6UlueUvhNJvCU97fWi9N3EC5mN6lJFEWOMIQf4fZd0fgraSGzQEpAoaAkZf9nIKqIscDv18gfRaaDX7sNWo2JTbt2qpYQ34k45 +fUYI48Dfy7Py3HLHMSD2uDSXjNv+dEE59InZawOGuMGpf3/JSab8vJ4WncV0IA9P9nKlqT+PtASFyK2dXaZsXWVGYR3u1eY/TMVyUfGedVoL2GO3CqB071l UfId9KXvzhn5DOt0gU1wjYQQr9KZHQKammmYXmeTmWB4cIya1ROgpPL8nlAFb0uDlKI6YxJAXN38d5k1rTPgVnluEWFcMwJvV5jPqCgdL4phTzbfMRJVIGNG HkfGPbFhwgzhC4dnKnUwD5qD/D3ZuR8T7daktZnvH+LNAruKCc+YXw+6n2e8+ziQF/A9jBlBUF7MEHAWWITrCr2thP82Kg== Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, radext@ietf.org, Alissa Cooper , kathleen moriarty ietf , IESG , radext-chairs@ietf.org Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 15:42:32 -0000 Lionel wrote: > My understanding is that, when defining authorization type attributes that > are use over RADIUS, it is not deemed required to define the specific use of > these attributes nor the error handling. Yes and no. While attributes can be re-used in multiple applications and use cases, the *semantics* of the authorization needs to be unambiguous. Remember, RADIUS doesn't have the notion of applications, so the meaning of attributes needs to be idempotent, if good interoperability to to be achieved. > As for other AAA documents, this draft is not specifying a specific procedure > or a new protocol application. It is just about defining attributes that can > be used in the use case described in this document but also in any other > solution that would see advantage to reuse these attributes. Yes, but see above. > The main point of this document is to ensure that the definitions of these > attributes are correct (type, length, value), unambiguous and describe in > which messages they can appear. The definition of RADIUS attributes also includes their semantics, not just their syntax. > The exact behavior of the client/server using these attributes is often left > out of this kind of document. It is up to the specification describing the > implementation the clients and/or servers using these attributes to define > this error handling. I disagree. Leaving out semantics and client/server behavior is not traditional for RADIUS and is likely to lead to poor interoperability. Regards, Dave Nelson From nobody Sun Sep 11 19:55:50 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939D712B118; Sun, 11 Sep 2016 19:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.508, SPF_PASS=-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 fwbHZ4GIeu-K; Sun, 11 Sep 2016 19:55:43 -0700 (PDT) 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 9C15C12B0E5; Sun, 11 Sep 2016 19:55:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWB01893; Mon, 12 Sep 2016 02:55:38 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 12 Sep 2016 03:55:37 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.53]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0235.001; Sun, 11 Sep 2016 19:55:34 -0700 From: Dean cheng To: "lionel.morand@orange.com" , "kathleen.moriarty.ietf@gmail.com" , Alissa Cooper Thread-Topic: Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHR9/Cwu6n7TFEfE0aWCTw3JOS72qBL68EAgAADpYCAAAXuAIAfD2BwgAZm7BA= Date: Mon, 12 Sep 2016 02:55:33 +0000 Message-ID: References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <17466_1473152611_57CE8663_17466_5602_1_6B7134B31289DC4FAF731D844122B36E01F9ECE4@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <17466_1473152611_57CE8663_17466_5602_1_6B7134B31289DC4FAF731D844122B36E01F9ECE4@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.245] Content-Type: multipart/alternative; boundary="_000_DC7880973D477648AC15A3BA66253F686E9578A5SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57D6192B.00B0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.53, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 073eb79259c815180137f4e4b30974be Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 02:55:47 -0000 --_000_DC7880973D477648AC15A3BA66253F686E9578A5SJCEML701CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBhbGwgdGhlIHJldmlldyBhbmQgY29tbWVudHMsIGJ1dCBhbHNvDQoNCmZlZWRi YWNrIGZyb20gTGlvbmVsLCBLYXRobGVlbiwgQWxhbiwgZXRjLiBIZXJlDQoNCmlzIG15IHJlc3Bv bnNlIHRvIHNvbWUgb2YgdGhlIGNvbW1lbnRzOg0KDQoNCg0KMSkgUmVnYXJkaW5nICJJUC1Qb3J0 LVR5cGUgVExWIiBhbmQgInRyYW5zcG9ydFR5cGUiDQoNCg0KDQogICAgQ29tbWVudDogU2hvdWxk IGluY2x1ZGUgYWxsL290aGVyIHBvcnQgdHlwZSwgb3INCg0KICAgIGp1c3QgZHJvcCB0aGlzLiAi dHJhbnNwb3J0VHlwZSIgdW5pbXBsZW1lbnRhYmxlLg0KDQoNCg0KICAgIFByb3Bvc2FsOiBLZWVw IHRoaXMgVExWLCBidXQgbGV0IGl0IGJlIGFuIG9wdGlvbmFsDQoNCiAgICBUTFYuIFdoZW4gaW5j bHVkZWQsIHRoZSBWYWx1ZSBwb3J0aW9uIGNvbnRhaW5zDQoNCiAgICBqdXN0IG9uZSBwb3J0LXR5 cGUgdGhhdCBpcyBkZWZpbmVkIGluIFBvcnQgTnVtYmVyPGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNz aWdubWVudHMvc2VydmljZS1uYW1lcy1wb3J0LW51bWh0dHA6L3d3dy5pYW5hLm9yZy9hc3NpZ25t ZW50cy9zZXJ2aWNlLW5hbWVzLXBvcnQtbnVtYmVycy9zZXJ2aWNlLW5hbWVzLXBvcnQtbnVtYmVy cy54aHRtbGJlcnMvc2VydmljZS1uYW1lcy1wb3J0LW51bWJlcnMueGh0bWw+Lg0KDQoNCg0KICAg IEFnYWluIHdlJ2xsIHVzZSA0LWJ5dGUgZGF0YSB0eXBlIGZvciB0aGlzIDE2LWJpdA0KDQogICAg dmFsdWUuDQoNCg0KDQogICAgV2hlbiBub3QgaW5jbHVkZWQsIGl0IGlzIGEgImRvbuKAmXQgY2Fy ZSIgb3IgYXBwbGllZA0KDQogICAgdG8gYWxsIHBvcnQgdHlwZXMuDQoNCg0KDQogICAgRG9pbmcg dGhpcyB3YXkgd291bGQgYWxzbyBsZWFkIHVzIHRvIGRyb3AgdGhlDQoNCiAgICAidHJhbnNwb3J0 VHlwZSIgcHJvcG9zZWQgdG8gYmUgYSBuZXcgSUUuDQoNCg0KDQoyKSBDb21tZW50OiBMYWNrIG9m IEVycm9yIGhhbmRsaW5nLg0KDQoNCg0KICAgIFByb3Bvc2FsOiBUaGUgY29tbWVudCBiYXNpY2Fs bHkgc2F5cyB0aGF0IGlmIHRoZQ0KDQogICAgQWNjZXNzLUFjY2VwdCBjb250YWlucyBzb21ldGhp bmcgdGhhdCBpcw0KDQogICAgZGlmZmVyZW50IHRoYW4gdGhhdCBpbiBBY2Nlc3MtUmVxdWVzdCwg d2UgbmVlZA0KDQogICAgdG8gaGFuZGxlIHRoZSBlcnJvci4gSSB0aGluayB0aGlzIHNob3VsZCBi ZSBhDQoNCiAgICBnZW5lcmFsIGlzc3VlIHdpdGhpbiBSYWRpdXMgcHJvdG9jb2wuIFJGQzI4NjUN Cg0KICAgIGRvZXMgbm90IHNheSB3aGF0IE5BUyBuZWVkcyB0byBkbyBhbnl0aGluZyBpZiB0aGUN Cg0KICAgIFNlcnZlciBzZW5kcyBhbiBBY2Nlc3MtQWNjZXB0IG1lc3NhZ2UgdGhhdCBjb250YWlu cw0KDQogICAgd3JvbmcvaW5jb25zaXN0ZW50IGNvbnRlbnRzIHJlc3BlY3RpdmUgdG8gdGhhdA0K DQogICAgaW4gQWNjZXNzLVJlcXVlc3QuDQoNCg0KDQogICAgV2UgY291bGQganVzdCBhZGQgYSBz dGF0ZW1lbnQgdG8gc2F5IHRoZSBOQVMNCg0KICAgIG5lZWRzIHRvIHZlcmlmeSB0aGUgY29udGVu dCBpbiB0aGUgQWNjZXNzLUFjY2Vzcw0KDQogICAgYW5kIGlmIHRoZSBjb250ZW50IGlzIGRpZmZl cmVudC9ub3QtZXhwZWN0ZWQgdGhhbg0KDQogICAgdGhhdCBpbiBBY2Nlc3MtUmVxdWVzdCwgc2hv dWxkIGRyb3AgdGhlIG1lc3NhZ2UNCg0KICAgIHdpdGggbm8gYWN0aW9uLg0KDQoNCg0KICAgIFNp bWlsYXJseSwgd2UgbmVlZCB0byBzYXkgdGhlIHNhbWUgdG8gQ29BLVJlcXVlc3QNCg0KICAgIGFu ZCBDb0EtUmVzcG9uc2UgaGFuZHNoYWtpbmcuDQoNCg0KDQozKSBDb21tZW50OiBQcml2YWN5IGNv bmNlcm5zLiBUaGlzIGlzIGJhc2ljYWxseQ0KDQogICByZWxhdGVkIHRvIHRoZSBpbmNsdXNpb24g b2YgIklQLVBvcnQtTG9jYWwtSWQgVExWIi4NCg0KICAgImxvY2FsSUQiIGFzIGEgbmV3IElQRklY IElFIGlzIHVuaW1wbGVtZW50YWJsZS4NCg0KDQoNCiAgIFByb3Bvc2FsLTE6IFJlbW92ZSB0aGlz IFRMViBhbmQgdGhlIHByb3Bvc2VkIElFLg0KDQogICBXZSdyZSBzdGlsbCBkaXNjdXNzaW5nIHRo ZSBpbXBsaWNhdGlvbiBhbW9uZyBhdXRob3JzLg0KDQogICBJZiB3ZSd2ZSBnb3QgdGhlIGNvbnNl bnN1cywgYm90aCBjb21tZW50cyB3b3VsZCBiZQ0KDQogICByZXNvbHZlZC4NCg0KDQoNCiAgIFBy b3Bvc2FsLTI6IEtlZXAgdGhpcyBUTFYgYnV0IHJlZmluZSAibG9jYWxJRCIgYXMNCg0KICAgYSBw cm9wb3NlZCBuZXcgSUUuIEZvciB0aGUgc2VjdXJpdHkvcHJpdmFjeSBjb25jZXJuLA0KDQogICBu b3RlIHRoYXQ6DQoNCg0KDQogICAgIGEpIFRoaXMgVExWIGlzIG9wdGlvbmFsIGluICJJUC1Qb3J0 LVJhbmdlIEF0dHJpYnV0ZSIsIGFzDQoNCiAgICAgc2FpZCBzbyBpbiB0aGUgZHJhZnQsIGl0IG5l ZWRzIG5vdCB0byBiZSBpbmNsdWRlZCBpZg0KDQogICAgIHNlY3VyaXR5IGlzIGEgY29uY2Vybi4N Cg0KDQoNCiAgICAgYikgVGhpcyBUTFYgaXMgYW4gYWx0ZXJuYXRpdmUgdG8gIklQLVBvcnQtSW50 LUlQdjQtQWRkcg0KDQogICAgIFRMViIgb3IgIklQLVBvcnQtSW50LUlQdjYtQWRkciBUTFYiIHRv IGJlIGluY2x1ZGVkIGluDQoNCiAgICAgIklQLVBvcnQtRm9yd2FyZGluZy1NYXAgQXR0cmlidXRl IiBhcyBjbGVhcmx5IHNhaWQgc28NCg0KICAgICBpbiB0aGUgZHJhZnQsIGFuZCBzbyBpZiB0aGUg c2VjdXJpdHkgaXMgYSBjb25jZXJuLCB0aGVuDQoNCiAgICAgZG9u4oCZdCB1c2UgaXQuDQoNCg0K DQo0KSBDb21tZW50OiBGZWVkYmFjayBmcm9tIElFIGV4cGVydHMuDQoNCg0KDQogICAgYSkgZm9y ICJ0cmFuc3BvcnRUeXBlIiwgaXQgaXMgbm8gbG9uZ2VyDQoNCiAgICBhbiBpc3N1ZSAoc2VlIDEg YWJvdmUpLiBXZSBqdXN0IGRyb3AgdGhpcy4NCg0KDQoNCiAgICBiKSBmb3IgIm5hdFRyYW5zcG9y dExpbWl0Ii4NCg0KICAgIFdlIGRvIG5lZWQgdGhpcyBJRS4gTGV0J3MgY2hhbmdlIHRoZSBuYW1l DQoNCiAgICB0byB0cmFuc3BvcnRMaW1pdCBzbyB0aGF0IGl0IGRvZXMgbm90IGxpbWl0DQoNCiAg ICB0byBiZSB1c2VkIGZvciBOQVQgb25seTsgYWxzbywgaW4gdGhlIHRleHQNCg0KICAgIChTZWN0 aW9uIDcuMSwgdGhlIHNlY29uZCBidWxsZXQpLCBzYXkgdGhhdA0KDQogICAgdGhpcyBJRSBpcyB1 c2VkIGZvciBib3RoIElQdjQgYW5kIElQdjYgY2FzZS4NCg0KDQoNCiAgICBjKSBmb3IgImxvY2Fs SUQiLCBpdCBpcyBubyBsb25nZXIgYW4gaXNzdWUNCg0KICAgIGlmIHdlIGRyb3AgIklQLVBvcnQt TG9jYWwtSWQgVExWIiwgYnV0IG90aGVyd2lzZQ0KDQogICAgd291bGQgbmVlZCB0byByZWZpbmUg dGhlIGRlZmluaXRpb24gKHNlZSAzIGFib3ZlKS4NCg0KDQoNCkNoZWVycywNCg0KRGVhbg0KDQoN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZyb206IGxpb25lbC5tb3JhbmRA b3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPiBbbWFpbHRvOmxpb25l bC5tb3JhbmRAb3JhbmdlLmNvbV0NCg0KPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDYsIDIw MTYgMjowMyBBTQ0KDQo+IFRvOiBrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTxtYWls dG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+OyBBbGlzc2EgQ29vcGVyDQoNCj4g Q2M6IElFU0c7IGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dEBpZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0QGlldGYub3JnPjsgcmFk ZXh0LQ0KDQo+IGNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Y2hhaXJzQGlldGYub3JnPjsgcmFkZXh0 QGlldGYub3JnPG1haWx0bzpyYWRleHRAaWV0Zi5vcmc+DQoNCj4gU3ViamVjdDogUkU6IEFsaXNz YSBDb29wZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtDQoNCj4gcmFk aXVzLWV4dC0xMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KPg0KDQo+IEhpIEFsaXNz YSwNCg0KPg0KDQo+IHRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIHNvcnJ5IGZvciB0aGlz ICJsYXRlIiBmZWVkYmFjay4NCg0KPg0KDQo+IEhlcmUgaXMgbXkgZmVlZGJhY2sgYXMgc2hlcGhl cmQgb2YgdGhlIGRvY3VtZW50LiBUaGlzIG5lZWRzIHRvIGJlDQoNCj4gY29tcGxldGVkIGJ5IGRy YWZ0IGF1dGhvcnMgYW5kIHRoZSBBRC4NCg0KPg0KDQo+IFJlZ2FyZHMsDQoNCj4NCg0KPiBMaW9u ZWwNCg0KPg0KDQo+ID4gPj4+ICgxKSBJIGZpbmQgdGhlIGFic2VuY2Ugb2YgYW55IGRlZmluaXRp b24gb2YgZXJyb3IgaGFuZGxpbmcNCg0KPiA+ID4+PiBiZWhhdmlvciBpbiB0aGlzIGRvY3VtZW50 IHRvIGJlIGEgcHJvYmxlbS4gSSByZWFsaXplIHRoYXQgdGhlDQoNCj4gPiA+Pj4gYXR0cmlidXRl cyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgbWVhbnQgdG8gYmUgdHJhbnNtaXR0ZWQN Cg0KPiA+ID4+PiBiZXR3ZWVuIGNvbXBvbmVudHMgdGhhdCBhcmUgYWxsIG9wZXJhdGVkIGJ5IHRo ZSBzYW1lDQoNCj4gPiA+Pj4gYWRtaW5pc3RyYXRpdmUgZW50aXR5LCBidXQgaW1wbGVtZW50b3Jz IGNhbiBzdGlsbCBtYWtlIG1pc3Rha2VzLA0KDQo+ID4gPj4+IGFuZCBmb3IgdGhvc2UgY2FzZXMg aXQgc2VlbXMgbGlrZSBlcnJvciBoYW5kbGluZyBzaG91bGQgYmUNCg0KPiBkZWZpbmVkLg0KDQo+ DQoNCj4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0LCB3aGVuIGRlZmluaW5nIGF1dGhvcml6YXRp b24gdHlwZSBhdHRyaWJ1dGVzDQoNCj4gdGhhdCBhcmUgdXNlIG92ZXIgUkFESVVTLCBpdCBpcyBu b3QgZGVlbWVkIHJlcXVpcmVkIHRvIGRlZmluZSB0aGUNCg0KPiBzcGVjaWZpYyB1c2Ugb2YgdGhl c2UgYXR0cmlidXRlcyBub3IgdGhlIGVycm9yIGhhbmRsaW5nLg0KDQo+IEFzIGZvciBvdGhlciBB QUEgZG9jdW1lbnRzLCB0aGlzIGRyYWZ0IGlzIG5vdCBzcGVjaWZ5aW5nIGEgc3BlY2lmaWMNCg0K PiBwcm9jZWR1cmUgb3IgYSBuZXcgcHJvdG9jb2wgYXBwbGljYXRpb24uIEl0IGlzIGp1c3QgYWJv dXQgZGVmaW5pbmcNCg0KPiBhdHRyaWJ1dGVzIHRoYXQgY2FuIGJlIHVzZWQgaW4gdGhlIHVzZSBj YXNlIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50DQoNCj4gYnV0IGFsc28gaW4gYW55IG90aGVy IHNvbHV0aW9uIHRoYXQgd291bGQgc2VlIGFkdmFudGFnZSB0byByZXVzZSB0aGVzZQ0KDQo+IGF0 dHJpYnV0ZXMuIFRoZSBtYWluIHBvaW50IG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gZW5zdXJlIHRo YXQgdGhlDQoNCj4gZGVmaW5pdGlvbnMgb2YgdGhlc2UgYXR0cmlidXRlcyBhcmUgY29ycmVjdCAo dHlwZSwgbGVuZ3RoLCB2YWx1ZSksDQoNCj4gdW5hbWJpZ3VvdXMgYW5kIGRlc2NyaWJlIGluIHdo aWNoIG1lc3NhZ2VzIHRoZXkgY2FuIGFwcGVhci4NCg0KPiBUaGUgZXhhY3QgYmVoYXZpb3Igb2Yg dGhlIGNsaWVudC9zZXJ2ZXIgdXNpbmcgdGhlc2UgYXR0cmlidXRlcyBpcyBvZnRlbg0KDQo+IGxl ZnQgb3V0IG9mIHRoaXMga2luZCBvZiBkb2N1bWVudC4gSXQgaXMgdXAgdG8gdGhlIHNwZWNpZmlj YXRpb24NCg0KPiBkZXNjcmliaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiB0aGUgY2xpZW50cyBhbmQv b3Igc2VydmVycyB1c2luZyB0aGVzZQ0KDQo+IGF0dHJpYnV0ZXMgdG8gZGVmaW5lIHRoaXMgZXJy b3IgaGFuZGxpbmcuDQoNCj4NCg0KPg0KDQo+ID4gPj4+ICgyKSBTZWN0aW9uIDMuMS4yIHNheXM6 DQoNCj4gPiA+Pj4NCg0KPiA+ID4+PiAiRm9yIHBvcnQgYWxsb2NhdGlvbiwgYm90aCBJUC1Qb3J0 LVJhbmdlLVN0YXJ0IFRMViBhbmQgSVAtDQoNCj4gPiA+Pj4gUG9ydC1SYW5nZS1FbmQgVExWIG11 c3QgYmUgaW5jbHVkZWQ7IGZvciBwb3J0IGRlYWxsb2NhdGlvbiwgdGhlDQoNCj4gPiA+Pj4gaW5j bHVzaW9uIG9mIHRoZXNlIHR3byBUTFZzIGlzIG9wdGlvbmFsIGFuZCBpZiBub3QgaW5jbHVkZWQs IGl0DQoNCj4gPiA+Pj4gaW1wbGllcyB0aGF0IGFsbCBwb3J0cyB0aGF0IGFyZSBwcmV2aW91c2x5 IGFsbG9jYXRlZCBhcmUgbm93DQoNCj4gPiA+Pj4gZGVhbGxvY2F0ZWQuIg0KDQo+ID4gPj4+DQoN Cj4gPiA+Pj4gSG93IGRvZXMgYW4gQUFBIHNlcnZlciBkaXN0aW5ndWlzaCBiZXR3ZWVuIHBvcnQg YWxsb2NhdGlvbiBhbmQNCg0KPiA+ID4+PiBkZWFsbG9jYXRpb24gcmVxdWVzdHMgaWYgYSBkZWFs bG9jYXRpb24gcmVxdWVzdCBpbmNsdWRlcyBhIHJhbmdlDQoNCj4gPiA+Pj4gc3RhcnQgYW5kIHJh bmdlIGVuZD8NCg0KPg0KDQo+IElmIEknbSBjb3JyZWN0LCB0aGUgYW5zd2VyIGlzIGJlbG93Og0K DQo+DQoNCj4gMy4yLjguICBJUC1Qb3J0LUFsbG9jIFRMVg0KDQo+DQoNCj4gICAgVGhlIGZvcm1h dCBvZiBJUC1Qb3J0LUFsbG9jIFRMViBpcyBzaG93biBpbiBGaWd1cmUgMTEuICBUaGlzDQoNCj4g ICAgYXR0cmlidXRlIGNhcnJpZXMgSVBGSVggSW5mb3JtYXRpb24gRWxlbWVudCAyMzAsICJuYXRF dmVudCIsIHdoaWNoDQoNCj4gaXMNCg0KPiAgICBhIGZsYWcgdG8gaW5kaWNhdGUgYW4gYWN0aW9u IG9mIE5BVCBvcGVyYXRpb24gKHJlZmVyIHRvIFtJUEZJWF0pLg0KDQo+DQoNCj4gICAgV2hlbiB0 aGUgdmFsdWUgb2YgbmF0RXZlbnQgaXMgIjEiIChDcmVhdGUgZXZlbnQpLCBpdCBtZWFucyB0bw0K DQo+ICAgIGFsbG9jYXRlIGEgcmFuZ2Ugb2YgdHJhbnNwb3J0IHBvcnRzOyB3aGVuIHRoZSB2YWx1 ZSBpcyAiMiIsIGl0IG1lYW5zDQoNCj4gICAgdG8gZGVhbGxvY2F0ZSBhIHJhbmdlIG9mIHRyYW5z cG9ydHMgcG9ydHMuICBGb3IgdGhlIHB1cnBvc2Ugb2YgdGhpcw0KDQo+ICAgIFRMViwgbm8gb3Ro ZXIgdmFsdWUgaXMgdXNlZC4NCg0KPg0KDQo+ID4gPj4+ICgzKSBUaGUgc3BlY2lmaWNhdGlvbiBv ZiBJUC1Qb3J0LUxvY2FsLUlkIHNlZW1zIHRvIGFsbG93IGZvcg0KDQo+ID4gPj4+IHVubmVjZXNz YXJ5IGV4cG9zdXJlIG9mIHBvdGVudGlhbGx5IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gVGhlcmUN Cg0KPiA+ID4+PiBpcyBubyBleHBsYW5hdGlvbiBnaXZlbiBmb3Igd2h5IHRoZSBjb21iaW5hdGlv biBvZiB0aGUgb3RoZXINCg0KPiA+ID4+PiBpZGVudGlmaWVycyBpbmNsdWRlZCBpbiBJUC1Qb3J0 LVJhbmdlIGFuZCBJUC1Qb3J0LUZvcndhcmRpbmcNCg0KPiA+ID4+PiBhdHRyaWJ1dGVzIGlzIGlu c3VmZmljaWVudCB0byBpZGVudGlmeSB0aGUgaG9zdCBpbiBEUy1FeHRyYS1MaXRlDQoNCj4gPiA+ Pj4gYW5kIExpZ2h0d2VpZ2h0IDRvdmVyNiBjYXNlcy4gQXMgZGVmaW5lZCwgaXQgc291bmRzIGxp a2UNCg0KPiA+ID4+PiBpbXBsZW1lbnRhdGlvbnMgY291bGQgcHV0IGJhc2ljYWxseSBhbnkgdXNl ciwgZGV2aWNlLCBvcg0KDQo+IGludGVyZmFjZQ0KDQo+ID4gPj4+IGlkZW50aWZpZXIgaW4gdGhl cmUuIElmIHRoaXMgVExWIGlzIGFjdHVhbGx5IG5lY2Vzc2FyeSB0bw0KDQo+ID4gPj4+IGNvbW11 bmljYXRlIHdoYXQgdGhlc2UgYXR0cmlidXRlcyBhcmUgdHJ5aW5nIHRvIGFjY29tcGxpc2gsIHRo ZQ0KDQo+ID4gPj4+IGp1c3RpZmljYXRpb24gZm9yIGl0IHNob3VsZCBiZSBwcm92aWRlZCBhbmQg dGhlIGxpbWl0YXRpb25zIG9uDQoNCj4gPiA+Pj4gd2hlbiB0aGlzIGZpZWxkIG1heSBiZSB1c2Vk IGFuZCB3aGF0IGtpbmQgb2YgaWRlbnRpZmllcnMgY2FuDQoNCj4gYXBwZWFyIGhlcmUgc2hvdWxk IGJlIHN0YXRlZC4NCg0KPg0KDQo+IE15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgdGhlIElQLVBv cnQtTG9jYWwtSWQgaXMgcmVxdWlyZWQgd2hlbiBpdCBpcw0KDQo+IG5vdCBwb3NzaWJsZSB0byBy ZWx5IG9uICBhbiBpbnRlcm5hbCBJUHY0IG9yIElQdjYgYWRkcmVzcyB0byBpZGVudGlmeQ0KDQo+ IGFuIG9uZ29pbmcgc2Vzc2lvbi4NCg0KPiBidXQgYXV0aG9ycyBjYW4gY2xhcmlmeSB0aGUgdXNl IG9mIHRoaXMgYXR0cmlidXRlIGFuZCBhZGRyZXNzIHRoZQ0KDQo+IHByaXZhY3kgY29uY2VybnMu DQoNCj4NCg0KPiBieSB0aGUgd2F5LCBpZiBub3QgYWxyZWFkeSBzcG90dGVkOg0KDQo+DQoNCj4g ICAgICAgSVAtUG9ydC1JbnQtSVB2Ni1BZGRyIFRMVg0KDQo+DQoNCj4gICAgICAgICAgVGhpcyBU TFYgY29udGFpbnMgYW4gSVB2NCBhZGRyZXNzIHRoYXQgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZQ0K DQo+DQoNCj4gcy8gVGhpcyBUTFYgY29udGFpbnMgYW4gSVB2NCBhZGRyZXNzLyBUaGlzIFRMViBj b250YWlucyBhbiBJUHY2IGFkZHJlc3MNCg0KPg0KDQo+IE9uIHRoZSA0KSwgSSB3aWxsIGFuc3dl ciBpbiBhIHNlcGFyYXRlIGVtYWlsLg0KDQo+DQoNCj4gTGlvbmVsDQoNCj4NCg0KPiA+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KDQo+ID4gRGUgOiBrYXRobGVlbi5tb3JpYXJ0eS5pZXRm QGdtYWlsLmNvbTxtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+DQoNCj4g PiBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KDQo+ID4gRW52b3nD qSA6IG1hcmRpIDE2IGFvw7t0IDIwMTYgMjM6MTYNCg0KPiA+IMOAIDogQWxpc3NhIENvb3Blcg0K DQo+ID4gQ2MgOiBJRVNHOyBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHRAaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dEBpZXRmLm9y Zz47IE1PUkFORA0KDQo+ID4gTGlvbmVsIElNVC9PTE47IHJhZGV4dC1jaGFpcnNAaWV0Zi5vcmc8 bWFpbHRvOnJhZGV4dC1jaGFpcnNAaWV0Zi5vcmc+OyByYWRleHRAaWV0Zi5vcmc8bWFpbHRvOnJh ZGV4dEBpZXRmLm9yZz4gT2JqZXQgOiBSZToNCg0KPiA+IEFsaXNzYSBDb29wZXIncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC0xMToNCg0KPiA+ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4gPiBTZW50IGZy b20gbXkgaVBob25lDQoNCj4gPg0KDQo+ID4gPiBPbiBBdWcgMTYsIDIwMTYsIGF0IDQ6NTQgUE0s IEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPG1haWx0bzphbGlzc2FAY29vcGVydy5p bj4+DQoNCj4gd3JvdGU6DQoNCj4gPiA+DQoNCj4gPiA+DQoNCj4gPiA+PiBPbiBBdWcgMTYsIDIw MTYsIGF0IDQ6NDEgUE0sIEthdGhsZWVuIE1vcmlhcnR5DQoNCj4gPiA8a2F0aGxlZW4ubW9yaWFy dHkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29t Pj4gd3JvdGU6DQoNCj4gPiA+Pg0KDQo+ID4gPj4gQWxpc3NhLA0KDQo+ID4gPj4NCg0KPiA+ID4+ IFRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcsIHRoaXMgaXMgaGVscGZ1bC4gIEhvcGVm dWxseSB3ZQ0KDQo+ID4gPj4gd2lsbCBiZSBhYmxlIHRvIHJlc29sdmUgdGhpcyB3aXRoIHRoZSBl ZGl0b3JzIGFuZCBzaGVwaGVyZCBiZWZvcmUNCg0KPiBUaHVyc2RheS4NCg0KPiA+ID4+IEkgaGF2 ZSBvbmUgcXVlc3Rpb24gaW4gbGluZSB0aGF0IG1heSBoZWxwIHdpdGggdGhlIHJlc29sdXRpb24g Zm9yDQoNCj4gPiA+PiBhdCBsZWFzdCAjMSAmICM2Lg0KDQo+ID4gPj4NCg0KPiA+ID4+PiBPbiBU dWUsIEF1ZyAxNiwgMjAxNiBhdCAzOjAyIFBNLCBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVy dy5pbjxtYWlsdG86YWxpc3NhQGNvb3BlcncuaW4+Pg0KDQo+ID4gd3JvdGU6DQoNCj4gPiA+Pj4g QWxpc3NhIENvb3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBm b3INCg0KPiA+ID4+PiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQtMTE6IERp c2N1c3MNCg0KPiA+ID4+Pg0KDQo+ID4gPj4+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvDQoNCj4gPiA+Pj4gYWxsIGVtYWls IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlDQoN Cj4gdG8NCg0KPiA+ID4+PiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVy LikNCg0KPiA+ID4+Pg0KDQo+ID4gPj4+DQoNCj4gPiA+Pj4gUGxlYXNlIHJlZmVyIHRvDQoNCj4g PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJp YS5odG1sDQoNCj4gPiA+Pj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNT IGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KPiA+ID4+Pg0KDQo+ID4gPj4+DQoNCj4gPiA+Pj4g VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZA0KDQo+IGhlcmU6DQoNCj4gPiA+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC08aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtPg0KDQo+IHJhZGl1cy08aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1y YWRpdXMtPg0KDQo+ID4gPj4+IGV4DQoNCj4gPiA+Pj4gdC8NCg0KPiA+ID4+Pg0KDQo+ID4gPj4+ DQoNCj4gPiA+Pj4NCg0KPiA+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+IC0NCg0KPiA+ID4+PiAtLQ0KDQo+ ID4gPj4+IC0tDQoNCj4gPiA+Pj4gRElTQ1VTUzoNCg0KPiA+ID4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+IC0N Cg0KPiA+ID4+PiAtLQ0KDQo+ID4gPj4+IC0tDQoNCj4gPiA+Pj4NCg0KPiA+ID4+PiAoMSkgSSBm aW5kIHRoZSBhYnNlbmNlIG9mIGFueSBkZWZpbml0aW9uIG9mIGVycm9yIGhhbmRsaW5nDQoNCj4g PiA+Pj4gYmVoYXZpb3IgaW4gdGhpcyBkb2N1bWVudCB0byBiZSBhIHByb2JsZW0uIEkgcmVhbGl6 ZSB0aGF0IHRoZQ0KDQo+ID4gPj4+IGF0dHJpYnV0ZXMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1l bnQgYXJlIG1lYW50IHRvIGJlIHRyYW5zbWl0dGVkDQoNCj4gPiA+Pj4gYmV0d2VlbiBjb21wb25l bnRzIHRoYXQgYXJlIGFsbCBvcGVyYXRlZCBieSB0aGUgc2FtZQ0KDQo+ID4gPj4+IGFkbWluaXN0 cmF0aXZlIGVudGl0eSwgYnV0IGltcGxlbWVudG9ycyBjYW4gc3RpbGwgbWFrZSBtaXN0YWtlcywN Cg0KPiA+ID4+PiBhbmQgZm9yIHRob3NlIGNhc2VzIGl0IHNlZW1zIGxpa2UgZXJyb3IgaGFuZGxp bmcgc2hvdWxkIGJlDQoNCj4gZGVmaW5lZC4gRm9yIGV4YW1wbGU6DQoNCj4gPiA+Pj4NCg0KPiA+ ID4+PiAtIFdoYXQgaGFwcGVucyBpZiB0aGUgQUFBIHNlcnZlciBzZW5kcyBhbiBJUC1Qb3J0LUxp bWl0LUluZm8NCg0KPiA+ID4+PiBhdHRyaWJ1dGUgd2l0aCBhIGxhcmdlciBsaW1pdCB0aGFuIHRo ZSBDR04gaXMgYWJsZSB0byBhbGxvY2F0ZSB0bw0KDQo+ID4gPj4+IHRoYXQgcGFydGljdWxhciB1 c2VyPyBXaGF0IGlzIHRoZSBDR04gc3VwcG9zZWQgdG8gZG8gYW5kIGhvdyBpcw0KDQo+ID4gPj4+ IHRoYXQgY29tbXVuaWNhdGVkIGJhY2sgdG8gdGhlIEFBQSBzZXJ2ZXI/DQoNCj4gPiA+Pj4NCg0K PiA+ID4+PiAtIFdoYXQgaGFwcGVucyBpZiB0aGUgQ0dOIHNlbmRzIGFuIElQLVBvcnQtUmFuZ2Ug YXR0cmlidXRlIHRoYXQNCg0KPiA+ID4+PiBlbmNvbXBhc3NlcyBhIGxhcmdlciByYW5nZSB0aGFu IGEgcHJldmlvdXNseSBzZW50IElQLVBvcnQtTGltaXQtDQoNCj4gSW5mbz8NCg0KPiA+ID4+PiBX aGF0IGlzIHRoZSBBQUEgc2VydmVyIHN1cHBvc2VkIHRvIGRvPw0KDQo+ID4gPj4+DQoNCj4gPiA+ Pj4gLSBXaGF0IGhhcHBlbnMgaWYgdGhlIEFBQSBzZXJ2ZXIgc2VuZHMgYW4gSVAtUG9ydC1Gb3J3 YXJkaW5nLU1hcA0KDQo+ID4gPj4+IGF0dHJpYnV0ZSB0byBtYXAgYSBwb3J0IHRoYXQgaXMgbm90 IHdpdGhpbiB0aGUgcmVxdWVzdGluZyBob3N0J3MNCg0KPiA+ID4+PiBhbGxvY2F0ZWQgcmFuZ2U/ IElzIHRoZSBDR04gZXhwZWN0ZWQgdG8gY2hhbmdlIHRoZSBtYXBwaW5nIGFuZA0KDQo+ID4gPj4+ IHNlbmQgYSBDb0Egd2l0aCBhIGRpZmZlcmVudCBJUC1Qb3J0LUZvcndhcmRpbmctTWFwLCBvcg0K DQo+IGNvbW11bmljYXRlDQoNCj4gPiA+Pj4gc29tZSBzb3J0IG9mIGVycm9yLCBvciBzb21ldGhp bmcgZWxzZT8NCg0KPiA+ID4+Pg0KDQo+ID4gPj4+IFRoZXJlIGFyZSBzdXJlbHkgb3RoZXIgZXJy b3IgY2FzZXMuIEkgdGhpbmsgaXQncyB3b3J0aCBnb2luZw0KDQo+ID4gPj4+IHRocm91Z2ggdGhl IHVzZXMgb2YgZWFjaCBhdHRyaWJ1dGUgYW5kIHNwZWNpZnlpbmcgYWxsIHRoZSBlcnJvcg0KDQo+ IGhhbmRsaW5nIGJlaGF2aW9yLg0KDQo+ID4gPj4+IFRoaXMgc2VlbXMgZXNwZWNpYWxseSBpbXBv cnRhbnQgc2luY2UgcGFydCBvZiB0aGUgbW90aXZhdGlvbiBmb3INCg0KPiA+ID4+PiB0aGVzZSBh dHRyaWJ1dGVzIGlzIGZvciBpZGVudGlmaWNhdGlvbiBhbmQgdGhlIGNvbnNlcXVlbmNlcyBvZg0K DQo+ID4gPj4+IGVycm9uZW91cyBpZGVudGlmaWNhdGlvbiBjb3VsZCBiZSBzZXZlcmUgZm9yIHRo ZSB1c2VyLiBEaXNjdXNzaW9uDQoNCj4gPiA+Pj4gb2YgdGhvc2UgY29uc2VxdWVuY2VzIGlzIGFs c28gbWlzc2luZyBmcm9tIFNlY3Rpb24gNi4NCg0KPiA+ID4+DQoNCj4gPiA+PiBBcyBhbiBhbHRl cm5hdGl2ZSwgSSB1c3VhbGx5IGFwcHJvYWNoIHRoaXMgdHlwZSBvZiBwcm9ibGVtIGFzDQoNCj4g PiA+PiBkZWZpbmluZyB3aGF0IGlzIGFjY2VwdGFibGUgYW5kIG1ha2luZyBldmVyeXRoaW5nIGVs c2UgbGVzcw0KDQo+ID4gPj4gYWNjZXB0YWJsZS4gIFdoaXRlIGxpc3RzIGFyZSBtdWNoIGVhc2ll ciB0byBtYWludGFpbiBhbmQgZWxpbWluYXRlDQoNCj4gPiA+PiB0aGUgcG9zc2liaWxpdHkgb2Yg bWlzc2luZyBzb21ldGhpbmcuICBJZiB5b3UgYW5kIHRoZSBXRyBhZ3JlZSwNCg0KPiA+ID4+IGNv dWxkIHdlIGdvIGZvcndhcmQgd2l0aCB0aGF0IGFwcHJvYWNoIGluc3RlYWQgb2YgZGVmaW5pbmcg YWxsDQoNCj4gPiA+PiBwb3NzaWJsZSBwcm9ibGVtcywganVzdCBsaW1pdGluZyB3aGF0IGlzIGFj Y2VwdGFibGUgYW5kIG1ha2luZw0KDQo+ID4gPj4gZXZlcnl0aGluZyBlbHNlIGFuDQoNCj4gPiBl cnJvcj8NCg0KPiA+ID4NCg0KPiA+ID4gSSB0aGluayBpdOKAmXMgZmluZSB0byBzYXkg4oCcdGhl IG9ubHkgY29ycmVjdCBiZWhhdmlvciBpcyBY4oCdIGJ1dCB5b3UNCg0KPiA+ID4gc3RpbGwgbmVl ZCB0byBzYXkNCg0KPiA+IHdoYXQgaW1wbGVtZW50YXRpb25zIGFyZSBleHBlY3RlZCB0byBkbyB3 aGVuIG5vdC1YIGhhcHBlbnMuIEFuZCBYDQoNCj4gd2lsbA0KDQo+ID4gaGF2ZSBkaWZmZXJlbnQg dmFsdWVzIGZvciB0aGUgZGlmZmVyZW50IHVzYWdlcyBvZiBlYWNoIG9mIHRoZXNlDQoNCj4gYXR0 cmlidXRlcy4NCg0KPiA+ID4NCg0KPiA+IEFncmVlZCwgdGhhbmtzLg0KDQo+ID4NCg0KPiA+IEth dGhsZWVuDQoNCj4gPiA+IEFsaXNzYQ0KDQo+ID4gPg0KDQo+ID4gPj4gVGhpcyBhcHByb2FjaA0K DQo+ID4gPj4gYXBwbGllcyB0byBhIGZldyBvZiB5b3VyIG90aGVyIGRpc2N1c3MgcG9pbnRzIGFz IHdlbGwsIG5hbWVseSAjMiwNCg0KPiA+ID4+ICM1LCBhbmQgdG8gc29tZSBkZWdyZWUgIzMuDQoN Cj4gPiA+Pg0KDQo+ID4gPj4+DQoNCj4gPiA+Pj4gKDIpIFNlY3Rpb24gMy4xLjIgc2F5czoNCg0K PiA+ID4+Pg0KDQo+ID4gPj4+ICJGb3IgcG9ydCBhbGxvY2F0aW9uLCBib3RoIElQLVBvcnQtUmFu Z2UtU3RhcnQgVExWIGFuZCBJUC0NCg0KPiA+ID4+PiBQb3J0LVJhbmdlLUVuZCBUTFYgbXVzdCBi ZSBpbmNsdWRlZDsgZm9yIHBvcnQgZGVhbGxvY2F0aW9uLCB0aGUNCg0KPiA+ID4+PiBpbmNsdXNp b24gb2YgdGhlc2UgdHdvIFRMVnMgaXMgb3B0aW9uYWwgYW5kIGlmIG5vdCBpbmNsdWRlZCwgaXQN Cg0KPiA+ID4+PiBpbXBsaWVzIHRoYXQgYWxsIHBvcnRzIHRoYXQgYXJlIHByZXZpb3VzbHkgYWxs b2NhdGVkIGFyZSBub3cNCg0KPiA+ID4+PiBkZWFsbG9jYXRlZC4iDQoNCj4gPiA+Pj4NCg0KPiA+ ID4+PiBIb3cgZG9lcyBhbiBBQUEgc2VydmVyIGRpc3Rpbmd1aXNoIGJldHdlZW4gcG9ydCBhbGxv Y2F0aW9uIGFuZA0KDQo+ID4gPj4+IGRlYWxsb2NhdGlvbiByZXF1ZXN0cyBpZiBhIGRlYWxsb2Nh dGlvbiByZXF1ZXN0IGluY2x1ZGVzIGEgcmFuZ2UNCg0KPiA+ID4+PiBzdGFydCBhbmQgcmFuZ2Ug ZW5kPyBJcyB0aGUgc2VydmVyIHN1cHBvc2VkIHRvIGFzc3VtZSB0aGF0DQoNCj4gPiA+Pj4gd2hh dGV2ZXIgcmFuZ2UgaXMgc3BlY2lmaWVkIGJ5IHRoZSBtb3N0IHJlY2VudGx5IHJlY2VpdmVkDQoN Cj4gPiA+Pj4gSVAtUG9ydC1SYW5nZSBhdHRyaWJ1dGUgcmVwcmVzZW50cyB0aGUgb25seSByYW5n ZSBvZiBhbGxvY2F0ZWQNCg0KPiBwb3J0cyBmb3IgdGhlIGhvc3Q/DQoNCj4gPiA+Pj4gV2hhdCBp cyB0aGUgbWVhbmluZyBvZiBzZW5kaW5nIGFuIElQLVBvcnQtUmFuZ2UgcmVxdWVzdCB3aXRoIG9u bHkNCg0KPiA+ID4+PiBhIHN0YXJ0IHZhbHVlIG9yIGFuIGVuZCB2YWx1ZSBidXQgbm90IGJvdGgg KGFzIHNlZW1zIHRvIGJlDQoNCj4gPiA+Pj4gYWxsb3dhYmxlIGJ5IHRoZQ0KDQo+ID4gYWJvdmUp Pw0KDQo+ID4gPj4+DQoNCj4gPiA+Pj4gKDMpIFRoZSBzcGVjaWZpY2F0aW9uIG9mIElQLVBvcnQt TG9jYWwtSWQgc2VlbXMgdG8gYWxsb3cgZm9yDQoNCj4gPiA+Pj4gdW5uZWNlc3NhcnkgZXhwb3N1 cmUgb2YgcG90ZW50aWFsbHkgc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiBUaGVyZQ0KDQo+ID4gPj4+ IGlzIG5vIGV4cGxhbmF0aW9uIGdpdmVuIGZvciB3aHkgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBv dGhlcg0KDQo+ID4gPj4+IGlkZW50aWZpZXJzIGluY2x1ZGVkIGluIElQLVBvcnQtUmFuZ2UgYW5k IElQLVBvcnQtRm9yd2FyZGluZw0KDQo+ID4gPj4+IGF0dHJpYnV0ZXMgaXMgaW5zdWZmaWNpZW50 IHRvIGlkZW50aWZ5IHRoZSBob3N0IGluIERTLUV4dHJhLUxpdGUNCg0KPiA+ID4+PiBhbmQgTGln aHR3ZWlnaHQgNG92ZXI2IGNhc2VzLiBBcyBkZWZpbmVkLCBpdCBzb3VuZHMgbGlrZQ0KDQo+ID4g Pj4+IGltcGxlbWVudGF0aW9ucyBjb3VsZCBwdXQgYmFzaWNhbGx5IGFueSB1c2VyLCBkZXZpY2Us IG9yDQoNCj4gaW50ZXJmYWNlDQoNCj4gPiA+Pj4gaWRlbnRpZmllciBpbiB0aGVyZS4gSWYgdGhp cyBUTFYgaXMgYWN0dWFsbHkgbmVjZXNzYXJ5IHRvDQoNCj4gPiA+Pj4gY29tbXVuaWNhdGUgd2hh dCB0aGVzZSBhdHRyaWJ1dGVzIGFyZSB0cnlpbmcgdG8gYWNjb21wbGlzaCwgdGhlDQoNCj4gPiA+ Pj4ganVzdGlmaWNhdGlvbiBmb3IgaXQgc2hvdWxkIGJlIHByb3ZpZGVkIGFuZCB0aGUgbGltaXRh dGlvbnMgb24NCg0KPiA+ID4+PiB3aGVuIHRoaXMgZmllbGQgbWF5IGJlIHVzZWQgYW5kIHdoYXQg a2luZCBvZiBpZGVudGlmaWVycyBjYW4NCg0KPiBhcHBlYXIgaGVyZSBzaG91bGQgYmUgc3RhdGVk Lg0KDQo+ID4gPj4+DQoNCj4gPiA+Pj4gKDQpIFRoZSBzaGVwaGVyZCB3cml0ZS11cCBkaXNjdXNz ZXMgdHdvIGRpZmZlcmVudCBhcHByb2FjaGVzIHRvDQoNCj4gPiA+Pj4gZGVmaW5pbmcgdGhlIHN1 Yi1UTFYgdHlwZXMgYW5kIHRoZW4gc2F5czogIkJvdGggYXBwcm9hY2hlcyB3ZXJlDQoNCj4gPiA+ Pj4gY29uc2lkZXJlZCBhcyB2YWxpZCBhbmQgdGhlIFdHIGhhcyBkZWNpZGVkIHRvIGxldCBJQU5B IGRlY2lkZQ0KDQo+IHdoYXQNCg0KPiA+ID4+PiB0aGUgYXBwcm9hY2ggaXMgcHJlZmVycmVkIHdo ZW4gYWxsb2NhdGluZyB0aGUgVExWLVR5cGUgZm9yIHRoZQ0KDQo+ID4gPj4+IHN1Yi1UTFZzIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudC4iIFRoaXMgaXMgbm90IGFwcHJvcHJpYXRlLiBUaGUNCg0K PiA+ID4+PiBkb2N1bWVudCBuZWVkcyB0byBleHBsaWNpdGx5IGRlZmluZSBob3cgdGhlIHR5cGVz IHNob3VsZCBiZQ0KDQo+ID4gPj4+IGFsbG9jYXRlZCBhbmQgc2hvdWxkIG5vdCBsZWF2ZSB0aGUg ZGVjaXNpb24gdG8gSUFOQS4gSSBzZWUgdGhhdA0KDQo+ID4gPj4+IElBTkEgaGFzIGFscmVhZHkg bm90ZWQgdGhhdCBTZWN0aW9uIDcuMyBpcyBhbWJpZ3VvdXMgYWJvdXQgdGhpczsNCg0KPiA+ID4+ PiB0aGUgV0cgbmVlZHMgdG8NCg0KPiA+IG1ha2UgYSBjaG9pY2UuDQoNCj4gPiA+Pg0KDQo+ID4g Pj4gVGhhbmsgeW91LCBhbmQgeWVzLCB0aGUgV0cgbmVlZHMgdG8gbWFrZSBhIGRlY2lzaW9uLg0K DQo+ID4gPj4NCg0KPiA+ID4+IEthdGhsZWVuDQoNCj4gPiA+Pg0KDQo+ID4gPj4+DQoNCj4gPiA+ Pj4gKDUpIFNlY3Rpb24gNiBzZWVtcyB0byBiZSBtaXNzaW5nIGEgZGlzY3Vzc2lvbiBvZiB0aGUN Cg0KPiBjb25zZXF1ZW5jZXMNCg0KPiA+ID4+PiBvZiBjb21tdW5pY2F0aW5nIGVycm9uZW91cyBw b3J0IHJhbmdlIGFuZCBwb3J0IG1hcHBpbmcNCg0KPiBpbmZvcm1hdGlvbi4NCg0KPiA+ID4+PiBT aW5jZSBwYXJ0IG9mIHRoZSBtb3RpdmF0aW9uIGZvciB0aGVzZSBhdHRyaWJ1dGVzIGlzDQoNCj4g PiA+Pj4gaWRlbnRpZmljYXRpb24gb2YgdGhlIGhvc3QsIHRoaXMgbmVlZHMgdG8gYmUgZGlzY3Vz c2VkLg0KDQo+ID4gPj4+DQoNCj4gPiA+Pj4NCg0KPiA+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+IC0NCg0K PiA+ID4+PiAtLQ0KDQo+ID4gPj4+IC0tDQoNCj4gPiA+Pj4gQ09NTUVOVDoNCg0KPiA+ID4+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQo+IC0NCg0KPiA+ID4+PiAtLQ0KDQo+ID4gPj4+IC0tDQoNCj4gPiA+Pj4NCg0K PiA+ID4+PiAoMSkgV2hhdCBkb2VzIGl0IG1lYW4gZm9yIGFuIElQLVBvcnQtUmFuZ2UgYXR0cmli dXRlIHRvIGhhdmUNCg0KPiA+ID4+PiBJUC1Qb3J0LVR5cGUNCg0KPiA+ID4+PiAxIG9yIDI/IENh biBudW1iZXJzIGluIHRoZSB3aG9sZSByYW5nZSBiZSB1c2VkIGZvciBhbnkgb2YgdGhlDQoNCj4g cG9ydA0KDQo+ID4gPj4+IG9yIGlkZW50aWZpZXIgdHlwZXM/IE9yIGlzIHRoZSByYW5nZSBleHBl Y3RlZCB0byBiZSBzcGxpdCB1cA0KDQo+ID4gPj4+IHNvbWVob3cgYW1vbmcgdGhlIG11bHRpcGxl IHR5cGVzPyBJIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUNCg0KPiBleHBsYWluZWQuDQoNCj4gPiA+ Pj4NCg0KPiA+ID4+PiAoMikgSW4gNC4xLjQsIGhvdyBkb2VzIHRoZSBJU1Aga25vdyB0aGF0IEpv ZSBpcyB0cmF2ZWxpbmc/DQoNCj4gPiA+Pg0KDQo+ID4gPj4NCg0KPiA+ID4+DQoNCj4gPiA+PiAt LQ0KDQo+ID4gPj4NCg0KPiA+ID4+IEJlc3QgcmVnYXJkcywNCg0KPiA+ID4+IEthdGhsZWVuDQoN Cj4gPiA+DQoNCj4NCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4NCg0KPiBDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCg0KPiBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRy ZSBkaWZmdXNlcywNCg0KPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhcg0KDQo+IGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlDQoNCj4gbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMNCg0KPiBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUNCg0KPiBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLg0KDQo+DQoNCj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCg0KPiBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUNCg0KPiBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQo+IElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQNCg0KPiBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCj4gQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlDQoNCj4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNCj4g VGhhbmsgeW91Lg0KDQoNCg== --_000_DC7880973D477648AC15A3BA66253F686E9578A5SJCEML701CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5N c29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ bGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcC5Nc29BY2V0YXRl LCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFsbG9v blRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiA5Mi40cHQgMS4waW4gOTIu NHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyBmb3Ig YWxsIHRoZSByZXZpZXcgYW5kIGNvbW1lbnRzLCBidXQgYWxzbzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+ZmVlZGJhY2sgZnJvbSBMaW9uZWwsIEthdGhsZWVuLCBBbGFu LCBldGMuIEhlcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmlzIG15 IHJlc3BvbnNlIHRvIHNvbWUgb2YgdGhlIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4xKSBSZWdhcmRpbmcgJnF1b3Q7SVAtUG9ydC1UeXBlIFRMViZxdW90OyBhbmQgJnF1 b3Q7dHJhbnNwb3J0VHlwZSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgQ29tbWVudDogU2hvdWxkIGluY2x1ZGUgYWxsL290aGVyIHBvcnQgdHlw ZSwgb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBqdXN0IGRyb3AgdGhpcy4gJnF1b3Q7dHJhbnNwb3J0VHlwZSZxdW90OyB1bmltcGxl bWVudGFibGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyBQcm9wb3NhbDogS2VlcCB0aGlzIFRMViwgYnV0IGxldCBpdCBiZSBhbiBvcHRpb25hbDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRM Vi4gV2hlbiBpbmNsdWRlZCwgdGhlIFZhbHVlIHBvcnRpb24gY29udGFpbnM8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBqdXN0IG9uZSBw b3J0LXR5cGUgdGhhdCBpcyBkZWZpbmVkIGluIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcv YXNzaWdubWVudHMvc2VydmljZS1uYW1lcy1wb3J0LW51bWh0dHA6L3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9zZXJ2aWNlLW5hbWVzLXBvcnQtbnVtYmVycy9zZXJ2aWNlLW5hbWVzLXBvcnQtbnVt YmVycy54aHRtbGJlcnMvc2VydmljZS1uYW1lcy1wb3J0LW51bWJlcnMueGh0bWwiPg0KUG9ydCBO dW1iZXI8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgQWdhaW4gd2UnbGwgdXNlIDQtYnl0ZSBkYXRhIHR5cGUgZm9yIHRoaXMgMTYtYml0IDxvOnA+ DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDt2YWx1ZS4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyBXaGVuIG5vdCBpbmNsdWRlZCwgaXQgaXMgYSAmcXVvdDtkb27igJl0IGNhcmUmcXVvdDsg b3IgYXBwbGllZCA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dG8gYWxsIHBvcnQgdHlwZXMuIDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtEb2luZyB0aGlzIHdh eSB3b3VsZCBhbHNvIGxlYWQgdXMgdG8gZHJvcCB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt0cmFuc3BvcnRUeXBlJnF1 b3Q7IHByb3Bvc2VkIHRvIGJlIGEgbmV3IElFLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+MikgQ29tbWVudDogTGFjayBvZiBFcnJvciBoYW5kbGluZy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByb3Bvc2FsOiBUaGUgY29tbWVu dCBiYXNpY2FsbHkgc2F5cyB0aGF0IGlmIHRoZSA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QWNjZXNzLUFjY2VwdCBjb250 YWlucyBzb21ldGhpbmcgdGhhdCBpcyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RpZmZlcmVudCB0aGFuIHRoYXQgaW4gQWNj ZXNzLVJlcXVlc3QsIHdlIG5lZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0byBoYW5kbGUgdGhlIGVycm9yLiBJIHRoaW5rIHRoaXMg c2hvdWxkIGJlIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyBnZW5lcmFsIGlzc3VlIHdpdGhpbiBSYWRpdXMgcHJvdG9jb2wuIFJGQzI4 NjU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyBkb2VzIG5vdCBzYXkgd2hhdCBOQVMgbmVlZHMgdG8gZG8gYW55dGhpbmcgaWYgdGhlIDxv OnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtTZXJ2ZXIgc2VuZHMgYW4gQWNjZXNzLUFjY2VwdCBtZXNzYWdlIHRoYXQgY29udGFp bnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyB3cm9uZy9pbmNvbnNpc3RlbnQgY29udGVudHMgcmVzcGVjdGl2ZSB0byB0aGF0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaW4g QWNjZXNzLVJlcXVlc3QuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgV2UgY291bGQganVz dCBhZGQgYSBzdGF0ZW1lbnQgdG8gc2F5IHRoZSBOQVM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBuZWVkcyB0byB2ZXJpZnkgdGhlIGNv bnRlbnQgaW4gdGhlIEFjY2Vzcy1BY2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgaWYgdGhlIGNvbnRlbnQgaXMgZGlmZmVy ZW50L25vdC1leHBlY3RlZCB0aGFuIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGF0IGluIEFjY2Vzcy1SZXF1ZXN0LCBz aG91bGQgZHJvcCB0aGUgbWVzc2FnZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGggbm8gYWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgU2ltaWxhcmx5LCB3ZSBuZWVkIHRvIHNh eSB0aGUgc2FtZSB0byBDb0EtUmVxdWVzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCBDb0EtUmVzcG9uc2UgaGFuZHNoYWtpbmcu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjMpIENvbW1lbnQ6IFByaXZhY3kgY29uY2Vy bnMuIFRoaXMgaXMgYmFzaWNhbGx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgcmVsYXRlZCB0byB0aGUgaW5jbHVzaW9uIG9mICZxdW90O0lQLVBv cnQtTG9jYWwtSWQgVExWJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7ICZxdW90O2xvY2FsSUQmcXVvdDsgYXMgYSBuZXcgSVBGSVggSUUg aXMgdW5pbXBsZW1lbnRhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsgUHJvcG9zYWwtMTogUmVtb3ZlIHRoaXMgVExWIGFuZCB0aGUgcHJvcG9zZWQgSUUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgV2UncmUg c3RpbGwgZGlzY3Vzc2luZyB0aGUgaW1wbGljYXRpb24gYW1vbmcgYXV0aG9ycy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBJZiB3ZSd2ZSBnb3Qg dGhlIGNvbnNlbnN1cywgYm90aCBjb21tZW50cyB3b3VsZCBiZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHJlc29sdmVkLiZuYnNwOyZuYnNwOyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFByb3Bvc2FsLTI6IEtl ZXAgdGhpcyBUTFYgYnV0IHJlZmluZSAmcXVvdDtsb2NhbElEJnF1b3Q7IGFzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYSBwcm9wb3NlZCBuZXcg SUUuIEZvciB0aGUgc2VjdXJpdHkvcHJpdmFjeSBjb25jZXJuLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG5vdGUgdGhhdDo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEpIFRoaXMgVExWIGlz IG9wdGlvbmFsIGluICZxdW90O0lQLVBvcnQtUmFuZ2UgQXR0cmlidXRlJnF1b3Q7LCBhczxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHNhaWQgc28gaW4gdGhlIGRyYWZ0LCBpdCBuZWVkcyBub3QgdG8gYmUgaW5jbHVkZWQgaWYN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7c2VjdXJpdHkgaXMgYSBjb25jZXJuLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYikgVGhpcyBUTFYgaXMgYW4gYWx0 ZXJuYXRpdmUgdG8gJnF1b3Q7SVAtUG9ydC1JbnQtSVB2NC1BZGRyDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RM ViZxdW90OyBvciAmcXVvdDtJUC1Qb3J0LUludC1JUHY2LUFkZHIgVExWJnF1b3Q7IHRvIGJlIGlu Y2x1ZGVkIGluDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O0lQLVBvcnQtRm9yd2FyZGluZy1NYXAgQXR0 cmlidXRlJnF1b3Q7IGFzIGNsZWFybHkgc2FpZCBzbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIHRoZSBkcmFmdCwgYW5k IHNvIGlmIHRoZSBzZWN1cml0eSBpcyBhIGNvbmNlcm4sIHRoZW4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZG9u 4oCZdCB1c2UgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjQpIENvbW1lbnQ6IEZl ZWRiYWNrIGZyb20gSUUgZXhwZXJ0cy4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBhKSBmb3IgJnF1b3Q7dHJhbnNwb3J0 VHlwZSZxdW90OywgaXQgaXMgbm8gbG9uZ2VyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYW4gaXNzdWUgKHNlZSAxIGFib3ZlKS4gV2Ug anVzdCBkcm9wIHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBiKSBmb3IgJnF1b3Q7bmF0VHJhbnNwb3J0TGltaXQmcXVvdDsuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgV2UgZG8gbmVl ZCB0aGlzIElFLiBMZXQncyBjaGFuZ2UgdGhlIG5hbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0byB0cmFuc3BvcnRMaW1pdCBzbyB0 aGF0IGl0IGRvZXMgbm90IGxpbWl0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdG8gYmUgdXNlZCBmb3IgTkFUIG9ubHk7IGFsc28sIGlu IHRoZSB0ZXh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgKFNlY3Rpb24gNy4xLCB0aGUgc2Vjb25kIGJ1bGxldCksIHNheSB0aGF0PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg dGhpcyBJRSBpcyB1c2VkIGZvciBib3RoIElQdjQgYW5kIElQdjYgY2FzZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGMpIGZvciAmcXVvdDtsb2NhbElE JnF1b3Q7LCBpdCBpcyBubyBsb25nZXIgYW4gaXNzdWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBpZiB3ZSBkcm9wICZxdW90O0lQLVBv cnQtTG9jYWwtSWQgVExWJnF1b3Q7LCBidXQgb3RoZXJ3aXNlPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgd291bGQgbmVlZCB0byByZWZp bmUgdGhlIGRlZmluaXRpb24gKHNlZSAzIGFib3ZlKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RGVh bjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEZyb206 IDxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRA b3JhbmdlLmNvbTwvYT4gWzxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20i Pm1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208L2E+XTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDYsIDIw MTYgMjowMyBBTTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBU bzogPGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tIj5rYXRo bGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTwvYT47IEFsaXNzYSBDb29wZXI8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2M6IElFU0c7IDxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHRAaWV0Zi5vcmciPg0KZHJh ZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0QGlldGYub3JnPC9hPjsgcmFkZXh0LTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8YSBocmVmPSJtYWls dG86Y2hhaXJzQGlldGYub3JnIj5jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 cmFkZXh0QGlldGYub3JnIj4NCnJhZGV4dEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU3ViamVjdDogUkU6IEFsaXNzYSBDb29wZXIncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHJhZGl1cy1leHQtMTE6ICh3aXRoIERJU0NVU1MgYW5k IENPTU1FTlQpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIaSBBbGlzc2EsPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3 IGFuZCBzb3JyeSBmb3IgdGhpcyAmcXVvdDtsYXRlJnF1b3Q7IGZlZWRiYWNrLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgSGVyZSBpcyBteSBmZWVkYmFjayBhcyBzaGVwaGVyZCBv ZiB0aGUgZG9jdW1lbnQuIFRoaXMgbmVlZHMgdG8gYmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgY29tcGxldGVkIGJ5IGRyYWZ0IGF1dGhvcnMgYW5kIHRoZSBB RC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFJlZ2FyZHMsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBMaW9uZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICgxKSBJIGZpbmQgdGhlIGFic2VuY2Ugb2YgYW55IGRl ZmluaXRpb24gb2YgZXJyb3IgaGFuZGxpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgYmVoYXZpb3IgaW4gdGhpcyBkb2N1bWVu dCB0byBiZSBhIHByb2JsZW0uIEkgcmVhbGl6ZSB0aGF0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhdHRyaWJ1dGVzIHNw ZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBtZWFudCB0byBiZSB0cmFuc21pdHRlZDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyBiZXR3ZWVuIGNvbXBvbmVudHMgdGhhdCBhcmUgYWxsIG9wZXJhdGVkIGJ5IHRoZSBzYW1lPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7IGFkbWluaXN0cmF0aXZlIGVudGl0eSwgYnV0IGltcGxlbWVudG9ycyBjYW4gc3RpbGwgbWFr ZSBtaXN0YWtlcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsgYW5kIGZvciB0aG9zZSBjYXNlcyBpdCBzZWVtcyBsaWtlIGVycm9y IGhhbmRsaW5nIHNob3VsZCBiZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBkZWZpbmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgTXkgdW5k ZXJzdGFuZGluZyBpcyB0aGF0LCB3aGVuIGRlZmluaW5nIGF1dGhvcml6YXRpb24gdHlwZSBhdHRy aWJ1dGVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoYXQg YXJlIHVzZSBvdmVyIFJBRElVUywgaXQgaXMgbm90IGRlZW1lZCByZXF1aXJlZCB0byBkZWZpbmUg dGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHNwZWNpZmlj IHVzZSBvZiB0aGVzZSBhdHRyaWJ1dGVzIG5vciB0aGUgZXJyb3IgaGFuZGxpbmcuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEFzIGZvciBvdGhlciBBQUEgZG9j dW1lbnRzLCB0aGlzIGRyYWZ0IGlzIG5vdCBzcGVjaWZ5aW5nIGEgc3BlY2lmaWM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcHJvY2VkdXJlIG9yIGEgbmV3IHBy b3RvY29sIGFwcGxpY2F0aW9uLiBJdCBpcyBqdXN0IGFib3V0IGRlZmluaW5nPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGF0dHJpYnV0ZXMgdGhhdCBjYW4gYmUg dXNlZCBpbiB0aGUgdXNlIGNhc2UgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYnV0IGFsc28gaW4gYW55IG90aGVy IHNvbHV0aW9uIHRoYXQgd291bGQgc2VlIGFkdmFudGFnZSB0byByZXVzZSB0aGVzZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhdHRyaWJ1dGVzLiBUaGUgbWFp biBwb2ludCBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGVuc3VyZSB0aGF0IHRoZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBkZWZpbml0aW9ucyBvZiB0aGVzZSBh dHRyaWJ1dGVzIGFyZSBjb3JyZWN0ICh0eXBlLCBsZW5ndGgsIHZhbHVlKSw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdW5hbWJpZ3VvdXMgYW5kIGRlc2NyaWJl IGluIHdoaWNoIG1lc3NhZ2VzIHRoZXkgY2FuIGFwcGVhci48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIGV4YWN0IGJlaGF2aW9yIG9mIHRoZSBjbGllbnQv c2VydmVyIHVzaW5nIHRoZXNlIGF0dHJpYnV0ZXMgaXMgb2Z0ZW48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbGVmdCBvdXQgb2YgdGhpcyBraW5kIG9mIGRvY3Vt ZW50LiBJdCBpcyB1cCB0byB0aGUgc3BlY2lmaWNhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBkZXNjcmliaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiB0aGUg Y2xpZW50cyBhbmQvb3Igc2VydmVycyB1c2luZyB0aGVzZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhdHRyaWJ1dGVzIHRvIGRlZmluZSB0aGlzIGVycm9yIGhh bmRsaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICgyKSBTZWN0 aW9uIDMuMS4yIHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZxdW90O0ZvciBwb3J0IGFsbG9jYXRpb24sIGJv dGggSVAtUG9ydC1SYW5nZS1TdGFydCBUTFYgYW5kIElQLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBQb3J0LVJhbmdlLUVuZCBU TFYgbXVzdCBiZSBpbmNsdWRlZDsgZm9yIHBvcnQgZGVhbGxvY2F0aW9uLCB0aGU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgaW5j bHVzaW9uIG9mIHRoZXNlIHR3byBUTFZzIGlzIG9wdGlvbmFsIGFuZCBpZiBub3QgaW5jbHVkZWQs IGl0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0 OyZndDsmZ3Q7IGltcGxpZXMgdGhhdCBhbGwgcG9ydHMgdGhhdCBhcmUgcHJldmlvdXNseSBhbGxv Y2F0ZWQgYXJlIG5vdzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBkZWFsbG9jYXRlZC4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgSG93IGRv ZXMgYW4gQUFBIHNlcnZlciBkaXN0aW5ndWlzaCBiZXR3ZWVuIHBvcnQgYWxsb2NhdGlvbiBhbmQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsgZGVhbGxvY2F0aW9uIHJlcXVlc3RzIGlmIGEgZGVhbGxvY2F0aW9uIHJlcXVlc3QgaW5j bHVkZXMgYSByYW5nZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBzdGFydCBhbmQgcmFuZ2UgZW5kPzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgSWYgSSdtIGNvcnJlY3QsIHRoZSBhbnN3ZXIgaXMgYmVsb3c6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAzLjIuOC4mbmJzcDsgSVAtUG9ydC1BbGxv YyBUTFY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZSBmb3JtYXQgb2YgSVAtUG9ydC1BbGxvYyBUTFYgaXMgc2hvd24gaW4gRmlndXJlIDExLiZu YnNwOyBUaGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGF0dHJpYnV0ZSBjYXJyaWVzIElQRklYIEluZm9ybWF0aW9uIEVsZW1l bnQgMjMwLCAmcXVvdDtuYXRFdmVudCZxdW90Oywgd2hpY2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBmbGFnIHRvIGluZGljYXRlIGFuIGFj dGlvbiBvZiBOQVQgb3BlcmF0aW9uIChyZWZlciB0byBbSVBGSVhdKS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoZW4gdGhlIHZhbHVlIG9mIG5h dEV2ZW50IGlzICZxdW90OzEmcXVvdDsgKENyZWF0ZSBldmVudCksIGl0IG1lYW5zIHRvPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGFsbG9jYXRlIGEgcmFuZ2Ugb2YgdHJhbnNwb3J0IHBvcnRzOyB3aGVuIHRoZSB2YWx1ZSBpcyAm cXVvdDsyJnF1b3Q7LCBpdCBtZWFuczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0byBkZWFsbG9jYXRlIGEgcmFuZ2Ugb2YgdHJh bnNwb3J0cyBwb3J0cy4mbmJzcDsgRm9yIHRoZSBwdXJwb3NlIG9mIHRoaXM8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVExWLCBu byBvdGhlciB2YWx1ZSBpcyB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsgKDMpIFRoZSBzcGVjaWZpY2F0aW9uIG9mIElQLVBvcnQtTG9jYWwt SWQgc2VlbXMgdG8gYWxsb3cgZm9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHVubmVjZXNzYXJ5IGV4cG9zdXJlIG9mIHBvdGVu dGlhbGx5IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gVGhlcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgaXMgbm8gZXhwbGFuYXRp b24gZ2l2ZW4gZm9yIHdoeSB0aGUgY29tYmluYXRpb24gb2YgdGhlIG90aGVyPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGlkZW50 aWZpZXJzIGluY2x1ZGVkIGluIElQLVBvcnQtUmFuZ2UgYW5kIElQLVBvcnQtRm9yd2FyZGluZzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0OyBhdHRyaWJ1dGVzIGlzIGluc3VmZmljaWVudCB0byBpZGVudGlmeSB0aGUgaG9zdCBpbiBE Uy1FeHRyYS1MaXRlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7IGFuZCBMaWdodHdlaWdodCA0b3ZlcjYgY2FzZXMuIEFzIGRlZmlu ZWQsIGl0IHNvdW5kcyBsaWtlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGltcGxlbWVudGF0aW9ucyBjb3VsZCBwdXQgYmFzaWNh bGx5IGFueSB1c2VyLCBkZXZpY2UsIG9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IGludGVyZmFjZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBpZGVudGlmaWVyIGluIHRoZXJlLiBJZiB0aGlz IFRMViBpcyBhY3R1YWxseSBuZWNlc3NhcnkgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgY29tbXVuaWNhdGUgd2hhdCB0aGVz ZSBhdHRyaWJ1dGVzIGFyZSB0cnlpbmcgdG8gYWNjb21wbGlzaCwgdGhlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGp1c3RpZmlj YXRpb24gZm9yIGl0IHNob3VsZCBiZSBwcm92aWRlZCBhbmQgdGhlIGxpbWl0YXRpb25zIG9uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7IHdoZW4gdGhpcyBmaWVsZCBtYXkgYmUgdXNlZCBhbmQgd2hhdCBraW5kIG9mIGlkZW50aWZp ZXJzIGNhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhcHBl YXIgaGVyZSBzaG91bGQgYmUgc3RhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgTXkgdW5kZXJzdGFuZGluZyB3YXMgdGhhdCB0aGUgSVAtUG9ydC1Mb2NhbC1JZCBpcyByZXF1 aXJlZCB3aGVuIGl0IGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IG5vdCBwb3NzaWJsZSB0byByZWx5IG9uJm5ic3A7IGFuIGludGVybmFsIElQdjQgb3IgSVB2 NiBhZGRyZXNzIHRvIGlkZW50aWZ5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IGFuIG9uZ29pbmcgc2Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgYnV0IGF1dGhvcnMgY2FuIGNsYXJpZnkgdGhlIHVzZSBvZiB0aGlz IGF0dHJpYnV0ZSBhbmQgYWRkcmVzcyB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgcHJpdmFjeSBjb25jZXJucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IGJ5IHRoZSB3YXksIGlmIG5vdCBhbHJlYWR5IHNwb3R0ZWQ6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBJUC1Qb3J0LUludC1JUHY2LUFkZHIgVExWPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaGlzIFRMViBjb250YWlucyBhbiBJUHY0IGFkZHJlc3MgdGhhdCBpcyBhc3NvY2lhdGVkIHdp dGggdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzLyBUaGlzIFRMViBjb250 YWlucyBhbiBJUHY0IGFkZHJlc3MvIFRoaXMgVExWIGNvbnRhaW5zIGFuIElQdjYgYWRkcmVzczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgT24gdGhlIDQpLCBJIHdpbGwgYW5zd2Vy IGluIGEgc2VwYXJhdGUgZW1haWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBM aW9uZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgRGUmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRm QGdtYWlsLmNvbSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZSI+a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFs8YSBocmVmPSJt YWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86a2F0aGxlZW4ubW9yaWFy dHkuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9hPl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyBFbnZvecOpJm5ic3A7OiBtYXJkaSAxNiBhb8O7dCAyMDE2 IDIzOjE2PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg w4AmbmJzcDs6IEFsaXNzYSBDb29wZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyBDYyZuYnNwOzogSUVTRzsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWll dGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dEBpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZHJhZnQtaWV0Zi1yYWRleHQtaXAt cG9ydC1yYWRpdXMtZXh0QGlldGYub3JnPC9zcGFuPjwvYT47IE1PUkFORDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IExpb25lbCBJTVQvT0xOOyA8YSBo cmVmPSJtYWlsdG86cmFkZXh0LWNoYWlyc0BpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+cmFkZXh0LWNoYWlyc0BpZXRmLm9yZzwv c3Bhbj48L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnJhZGV4dEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnJhZGV4dEBpZXRmLm9yZzwv c3Bhbj48L2E+IE9iamV0Jm5ic3A7OiBSZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyBBbGlzc2EgQ29vcGVyJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQtMTE6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyBTZW50IGZyb20gbXkgaVBob25lPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IE9uIEF1ZyAxNiwgMjAxNiwgYXQgNDo1 NCBQTSwgQWxpc3NhIENvb3BlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3Lmlu Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+YWxp c3NhQGNvb3BlcncuaW48L3NwYW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyBPbiBBdWcgMTYsIDIwMTYsIGF0IDQ6NDEgUE0sIEthdGhs ZWVuIE1vcmlhcnR5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNv bSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmth dGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsg QWxpc3NhLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsgJmd0OyZndDsgVGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIHJldmlldywgdGhpcyBpcyBoZWxw ZnVsLiZuYnNwOyBIb3BlZnVsbHkgd2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyB3aWxsIGJlIGFibGUgdG8gcmVzb2x2ZSB0aGlzIHdp dGggdGhlIGVkaXRvcnMgYW5kIHNoZXBoZXJkIGJlZm9yZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaHVyc2RheS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyBJIGhhdmUgb25lIHF1ZXN0aW9uIGlu IGxpbmUgdGhhdCBtYXkgaGVscCB3aXRoIHRoZSByZXNvbHV0aW9uIGZvcjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7IGF0IGxlYXN0ICMx ICZhbXA7ICM2LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7IE9uIFR1ZSwgQXVnIDE2LCAyMDE2IGF0IDM6MDIgUE0sIEFsaXNz YSBDb29wZXIgJmx0OzxhIGhyZWY9Im1haWx0bzphbGlzc2FAY29vcGVydy5pbiI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmFsaXNzYUBjb29wZXJ3 LmluPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IEFsaXNzYSBDb29wZXIgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBv cnQtcmFkaXVzLWV4dC0xMTogRGlzY3VzczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBXaGVuIHJlc3BvbmRpbmcsIHBs ZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhbGwg ZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdG88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsg Y3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7IFBsZWFzZSByZWZlciB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgaGVyZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LTwvc3Bhbj48L2E+PHNw YW4gY2xhc3M9Ik1zb0h5cGVybGluayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy0iPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj4mZ3Q7IHJhZGl1cy08L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0OyBleDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyB0LzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAtPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IC0tPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IC0t PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7IERJU0NVU1M6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IC08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgLS08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgKDEpIEkg ZmluZCB0aGUgYWJzZW5jZSBvZiBhbnkgZGVmaW5pdGlvbiBvZiBlcnJvciBoYW5kbGluZzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyBiZWhhdmlvciBpbiB0aGlzIGRvY3VtZW50IHRvIGJlIGEgcHJvYmxlbS4gSSByZWFsaXplIHRo YXQgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg Jmd0OyZndDsmZ3Q7IGF0dHJpYnV0ZXMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIG1l YW50IHRvIGJlIHRyYW5zbWl0dGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGJldHdlZW4gY29tcG9uZW50cyB0aGF0IGFyZSBh bGwgb3BlcmF0ZWQgYnkgdGhlIHNhbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgYWRtaW5pc3RyYXRpdmUgZW50aXR5LCBidXQg aW1wbGVtZW50b3JzIGNhbiBzdGlsbCBtYWtlIG1pc3Rha2VzLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhbmQgZm9yIHRob3Nl IGNhc2VzIGl0IHNlZW1zIGxpa2UgZXJyb3IgaGFuZGxpbmcgc2hvdWxkIGJlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGRlZmluZWQuIEZvciBleGFtcGxlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZn dDsmZ3Q7Jmd0OyAtIFdoYXQgaGFwcGVucyBpZiB0aGUgQUFBIHNlcnZlciBzZW5kcyBhbiBJUC1Q b3J0LUxpbWl0LUluZm88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyAmZ3Q7Jmd0OyZndDsgYXR0cmlidXRlIHdpdGggYSBsYXJnZXIgbGltaXQgdGhhbiB0 aGUgQ0dOIGlzIGFibGUgdG8gYWxsb2NhdGUgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdGhhdCBwYXJ0aWN1bGFyIHVzZXI/ IFdoYXQgaXMgdGhlIENHTiBzdXBwb3NlZCB0byBkbyBhbmQgaG93IGlzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHRoYXQgY29t bXVuaWNhdGVkIGJhY2sgdG8gdGhlIEFBQSBzZXJ2ZXI/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IC0gV2hhdCBoYXBw ZW5zIGlmIHRoZSBDR04gc2VuZHMgYW4gSVAtUG9ydC1SYW5nZSBhdHRyaWJ1dGUgdGhhdDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyBlbmNvbXBhc3NlcyBhIGxhcmdlciByYW5nZSB0aGFuIGEgcHJldmlvdXNseSBzZW50IElQLVBv cnQtTGltaXQtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IElu Zm8/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0 OyZndDsmZ3Q7IFdoYXQgaXMgdGhlIEFBQSBzZXJ2ZXIgc3VwcG9zZWQgdG8gZG8/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7IC0gV2hhdCBoYXBwZW5zIGlmIHRoZSBBQUEgc2VydmVyIHNlbmRzIGFuIElQLVBvcnQtRm9y d2FyZGluZy1NYXA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsgYXR0cmlidXRlIHRvIG1hcCBhIHBvcnQgdGhhdCBpcyBub3Qgd2l0 aGluIHRoZSByZXF1ZXN0aW5nIGhvc3QnczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhbGxvY2F0ZWQgcmFuZ2U/IElzIHRoZSBD R04gZXhwZWN0ZWQgdG8gY2hhbmdlIHRoZSBtYXBwaW5nIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBzZW5kIGEgQ29BIHdp dGggYSBkaWZmZXJlbnQgSVAtUG9ydC1Gb3J3YXJkaW5nLU1hcCwgb3I8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgY29tbXVuaWNhdGU8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgc29tZSBzb3J0 IG9mIGVycm9yLCBvciBzb21ldGhpbmcgZWxzZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgVGhlcmUgYXJlIHN1cmVs eSBvdGhlciBlcnJvciBjYXNlcy4gSSB0aGluayBpdCdzIHdvcnRoIGdvaW5nPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHRocm91 Z2ggdGhlIHVzZXMgb2YgZWFjaCBhdHRyaWJ1dGUgYW5kIHNwZWNpZnlpbmcgYWxsIHRoZSBlcnJv cjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBoYW5kbGluZyBi ZWhhdmlvci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyAmZ3Q7Jmd0OyZndDsgVGhpcyBzZWVtcyBlc3BlY2lhbGx5IGltcG9ydGFudCBzaW5jZSBwYXJ0 IG9mIHRoZSBtb3RpdmF0aW9uIGZvcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGVzZSBhdHRyaWJ1dGVzIGlzIGZvciBpZGVu dGlmaWNhdGlvbiBhbmQgdGhlIGNvbnNlcXVlbmNlcyBvZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBlcnJvbmVvdXMgaWRlbnRp ZmljYXRpb24gY291bGQgYmUgc2V2ZXJlIGZvciB0aGUgdXNlci4gRGlzY3Vzc2lvbjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBv ZiB0aG9zZSBjb25zZXF1ZW5jZXMgaXMgYWxzbyBtaXNzaW5nIGZyb20gU2VjdGlvbiA2LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsg QXMgYW4gYWx0ZXJuYXRpdmUsIEkgdXN1YWxseSBhcHByb2FjaCB0aGlzIHR5cGUgb2YgcHJvYmxl bSBhczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZn dDsmZ3Q7IGRlZmluaW5nIHdoYXQgaXMgYWNjZXB0YWJsZSBhbmQgbWFraW5nIGV2ZXJ5dGhpbmcg ZWxzZSBsZXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsgJmd0OyZndDsgYWNjZXB0YWJsZS4mbmJzcDsgV2hpdGUgbGlzdHMgYXJlIG11Y2ggZWFzaWVy IHRvIG1haW50YWluIGFuZCBlbGltaW5hdGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyB0aGUgcG9zc2liaWxpdHkgb2YgbWlzc2luZyBz b21ldGhpbmcuJm5ic3A7IElmIHlvdSBhbmQgdGhlIFdHIGFncmVlLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7IGNvdWxkIHdlIGdvIGZv cndhcmQgd2l0aCB0aGF0IGFwcHJvYWNoIGluc3RlYWQgb2YgZGVmaW5pbmcgYWxsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsgcG9zc2li bGUgcHJvYmxlbXMsIGp1c3QgbGltaXRpbmcgd2hhdCBpcyBhY2NlcHRhYmxlIGFuZCBtYWtpbmc8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0 OyBldmVyeXRoaW5nIGVsc2UgYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyBlcnJvcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIGl04oCZcyBmaW5lIHRvIHNheSDigJx0aGUgb25seSBj b3JyZWN0IGJlaGF2aW9yIGlzIFjigJ0gYnV0IHlvdTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgc3RpbGwgbmVlZCB0byBzYXk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyB3aGF0IGltcGxlbWVudGF0 aW9ucyBhcmUgZXhwZWN0ZWQgdG8gZG8gd2hlbiBub3QtWCBoYXBwZW5zLiBBbmQgWDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB3aWxsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgaGF2ZSBkaWZmZXJlbnQgdmFsdWVz IGZvciB0aGUgZGlmZmVyZW50IHVzYWdlcyBvZiBlYWNoIG9mIHRoZXNlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGF0dHJpYnV0ZXMuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IEFncmVlZCwgdGhhbmtzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgS2F0aGxlZW48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IEFsaXNzYTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyBUaGlzIGFw cHJvYWNoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg Jmd0OyZndDsgYXBwbGllcyB0byBhIGZldyBvZiB5b3VyIG90aGVyIGRpc2N1c3MgcG9pbnRzIGFz IHdlbGwsIG5hbWVseSAjMiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7Jmd0OyAjNSwgYW5kIHRvIHNvbWUgZGVncmVlICMzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7ICgyKSBTZWN0aW9uIDMuMS4yIHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZxdW90O0ZvciBwb3J0IGFs bG9jYXRpb24sIGJvdGggSVAtUG9ydC1SYW5nZS1TdGFydCBUTFYgYW5kIElQLTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBQb3J0 LVJhbmdlLUVuZCBUTFYgbXVzdCBiZSBpbmNsdWRlZDsgZm9yIHBvcnQgZGVhbGxvY2F0aW9uLCB0 aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDsgaW5jbHVzaW9uIG9mIHRoZXNlIHR3byBUTFZzIGlzIG9wdGlvbmFsIGFuZCBpZiBu b3QgaW5jbHVkZWQsIGl0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGltcGxpZXMgdGhhdCBhbGwgcG9ydHMgdGhhdCBhcmUgcHJl dmlvdXNseSBhbGxvY2F0ZWQgYXJlIG5vdzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBkZWFsbG9jYXRlZC4mcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsgSG93IGRvZXMgYW4gQUFBIHNlcnZlciBkaXN0aW5ndWlzaCBiZXR3ZWVuIHBvcnQgYWxs b2NhdGlvbiBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsgZGVhbGxvY2F0aW9uIHJlcXVlc3RzIGlmIGEgZGVhbGxvY2F0aW9u IHJlcXVlc3QgaW5jbHVkZXMgYSByYW5nZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBzdGFydCBhbmQgcmFuZ2UgZW5kPyBJcyB0 aGUgc2VydmVyIHN1cHBvc2VkIHRvIGFzc3VtZSB0aGF0PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHdoYXRldmVyIHJhbmdlIGlz IHNwZWNpZmllZCBieSB0aGUgbW9zdCByZWNlbnRseSByZWNlaXZlZDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBJUC1Qb3J0LVJh bmdlIGF0dHJpYnV0ZSByZXByZXNlbnRzIHRoZSBvbmx5IHJhbmdlIG9mIGFsbG9jYXRlZDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBwb3J0cyBmb3IgdGhlIGhv c3Q/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0 OyZndDsmZ3Q7IFdoYXQgaXMgdGhlIG1lYW5pbmcgb2Ygc2VuZGluZyBhbiBJUC1Qb3J0LVJhbmdl IHJlcXVlc3Qgd2l0aCBvbmx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGEgc3RhcnQgdmFsdWUgb3IgYW4gZW5kIHZhbHVlIGJ1 dCBub3QgYm90aCAoYXMgc2VlbXMgdG8gYmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgYWxsb3dhYmxlIGJ5IHRoZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGFib3ZlKT88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsgKDMpIFRoZSBzcGVjaWZpY2F0aW9uIG9mIElQLVBvcnQtTG9jYWwtSWQgc2VlbXMgdG8g YWxsb3cgZm9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsgJmd0OyZndDsmZ3Q7IHVubmVjZXNzYXJ5IGV4cG9zdXJlIG9mIHBvdGVudGlhbGx5IHNlbnNp dGl2ZSBpbmZvcm1hdGlvbi4gVGhlcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgaXMgbm8gZXhwbGFuYXRpb24gZ2l2ZW4gZm9y IHdoeSB0aGUgY29tYmluYXRpb24gb2YgdGhlIG90aGVyPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGlkZW50aWZpZXJzIGluY2x1 ZGVkIGluIElQLVBvcnQtUmFuZ2UgYW5kIElQLVBvcnQtRm9yd2FyZGluZzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhdHRyaWJ1 dGVzIGlzIGluc3VmZmljaWVudCB0byBpZGVudGlmeSB0aGUgaG9zdCBpbiBEUy1FeHRyYS1MaXRl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7IGFuZCBMaWdodHdlaWdodCA0b3ZlcjYgY2FzZXMuIEFzIGRlZmluZWQsIGl0IHNvdW5k cyBsaWtlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg Jmd0OyZndDsmZ3Q7IGltcGxlbWVudGF0aW9ucyBjb3VsZCBwdXQgYmFzaWNhbGx5IGFueSB1c2Vy LCBkZXZpY2UsIG9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IGludGVyZmFjZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyBpZGVudGlmaWVyIGluIHRoZXJlLiBJZiB0aGlzIFRMViBpcyBhY3R1 YWxseSBuZWNlc3NhcnkgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgY29tbXVuaWNhdGUgd2hhdCB0aGVzZSBhdHRyaWJ1dGVz IGFyZSB0cnlpbmcgdG8gYWNjb21wbGlzaCwgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGp1c3RpZmljYXRpb24gZm9yIGl0 IHNob3VsZCBiZSBwcm92aWRlZCBhbmQgdGhlIGxpbWl0YXRpb25zIG9uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHdoZW4gdGhp cyBmaWVsZCBtYXkgYmUgdXNlZCBhbmQgd2hhdCBraW5kIG9mIGlkZW50aWZpZXJzIGNhbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhcHBlYXIgaGVyZSBzaG91 bGQgYmUgc3RhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAoNCkgVGhlIHNoZXBoZXJkIHdyaXRlLXVwIGRpc2N1 c3NlcyB0d28gZGlmZmVyZW50IGFwcHJvYWNoZXMgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgZGVmaW5pbmcgdGhlIHN1Yi1U TFYgdHlwZXMgYW5kIHRoZW4gc2F5czogJnF1b3Q7Qm90aCBhcHByb2FjaGVzIHdlcmU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsg Y29uc2lkZXJlZCBhcyB2YWxpZCBhbmQgdGhlIFdHIGhhcyBkZWNpZGVkIHRvIGxldCBJQU5BIGRl Y2lkZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB3aGF0PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7IHRoZSBhcHByb2FjaCBpcyBwcmVmZXJyZWQgd2hlbiBhbGxvY2F0aW5nIHRoZSBUTFYtVHlw ZSBmb3IgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsgJmd0OyZndDsmZ3Q7IHN1Yi1UTFZzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4mcXVvdDsg VGhpcyBpcyBub3QgYXBwcm9wcmlhdGUuIFRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBkb2N1bWVudCBuZWVkcyB0byBleHBs aWNpdGx5IGRlZmluZSBob3cgdGhlIHR5cGVzIHNob3VsZCBiZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBhbGxvY2F0ZWQgYW5k IHNob3VsZCBub3QgbGVhdmUgdGhlIGRlY2lzaW9uIHRvIElBTkEuIEkgc2VlIHRoYXQ8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsg SUFOQSBoYXMgYWxyZWFkeSBub3RlZCB0aGF0IFNlY3Rpb24gNy4zIGlzIGFtYmlndW91cyBhYm91 dCB0aGlzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyB0aGUgV0cgbmVlZHMgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyBtYWtlIGEgY2hvaWNlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsgVGhhbmsgeW91LCBhbmQg eWVzLCB0aGUgV0cgbmVlZHMgdG8gbWFrZSBhIGRlY2lzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsgS2F0aGxlZW48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsm Z3Q7Jmd0OyAoNSkgU2VjdGlvbiA2IHNlZW1zIHRvIGJlIG1pc3NpbmcgYSBkaXNjdXNzaW9uIG9m IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBjb25zZXF1 ZW5jZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAm Z3Q7Jmd0OyZndDsgb2YgY29tbXVuaWNhdGluZyBlcnJvbmVvdXMgcG9ydCByYW5nZSBhbmQgcG9y dCBtYXBwaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGlu Zm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyBTaW5jZSBwYXJ0IG9mIHRoZSBtb3RpdmF0aW9uIGZvciB0aGVzZSBh dHRyaWJ1dGVzIGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7IGlkZW50aWZpY2F0aW9uIG9mIHRoZSBob3N0LCB0aGlzIG5lZWRz IHRvIGJlIGRpc2N1c3NlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAtLTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAtLTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyBDT01NRU5UOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7IC0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IC0tPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICgxKSBXaGF0IGRv ZXMgaXQgbWVhbiBmb3IgYW4gSVAtUG9ydC1SYW5nZSBhdHRyaWJ1dGUgdG8gaGF2ZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBJ UC1Qb3J0LVR5cGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDsgMSBvciAyPyBDYW4gbnVtYmVycyBpbiB0aGUgd2hvbGUgcmFuZ2Ug YmUgdXNlZCBmb3IgYW55IG9mIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBwb3J0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7IG9yIGlkZW50aWZpZXIgdHlwZXM/IE9yIGlzIHRoZSByYW5n ZSBleHBlY3RlZCB0byBiZSBzcGxpdCB1cDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBzb21laG93IGFtb25nIHRoZSBtdWx0aXBs ZSB0eXBlcz8gSSB0aGluayB0aGlzIG5lZWRzIHRvIGJlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGV4cGxhaW5lZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgKDIpIEluIDQuMS40 LCBob3cgZG9lcyB0aGUgSVNQIGtub3cgdGhhdCBKb2UgaXMgdHJhdmVsaW5nPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZndDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsmZ3Q7IC0t PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7 Jmd0OyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgJmd0OyZndDsgS2F0aGxlZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhcjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGFuayB5b3UuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_DC7880973D477648AC15A3BA66253F686E9578A5SJCEML701CHMchi_-- From nobody Mon Sep 12 10:39:27 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A18812B00E; Mon, 12 Sep 2016 10:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=DpdfPlRA; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=VFyuGye0 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 oWEeFoiwXU_v; Mon, 12 Sep 2016 10:39:23 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB34012B00F; Mon, 12 Sep 2016 10:39:22 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2295820805; Mon, 12 Sep 2016 13:39:22 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 12 Sep 2016 13:39:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=dD3WdW8R1bKUYuEUZ3WLM0zn8oc=; b=DpdfPl RAAECZ7FKgsBLkSdIXHQ6+2F3hVltUkyZRDleYZ7X5+mcmt7RuGAnYY2d0XAnUIy Nnug30MKhYO3mXZutUfrrdNuk5dsg4JVPMedD0E+OBzL84jLHBc4vG2B23kwb3qh UrbgIERV8fnclyXyzvhuhL2rkHav4a5EbuGFI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=dD3WdW8R1bKUYuE UZ3WLM0zn8oc=; b=VFyuGye0/91Y+6C01fuBJDh4J34r2yX+XczFZ1RhHVB/pb9 phnOIeoAF+ntvZOaENjvQJbsCDaHC4X3Cb2knaR9EGmb0jlxLERR/7We3sgIGKvP mtDvOmM4R0NfWXwgtY/6ETfKT+ddJ28w0FWlWZEGfujRkdDSvUdhtPeeEXfc= X-Sasl-enc: 9pDpuc4rbn7kjQaanXhBUAHIvB0SQOnOjSL7s9gmOr7K 1473701961 Received: from [10.24.127.108] (unknown [128.107.241.187]) by mail.messagingengine.com (Postfix) with ESMTPA id 81F65F29D9; Mon, 12 Sep 2016 13:39:20 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <17466_1473152611_57CE8663_17466_5602_1_6B7134B31289DC4FAF731D844122B36E01F9ECE4@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Mon, 12 Sep 2016 13:39:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <17466_1473152611_57CE8663_17466_5602_1_6B7134B31289DC4FAF731D844122B36E01F9ECE4@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , "radext@ietf.org" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 17:39:25 -0000 Hi Lionel, > On Sep 6, 2016, at 5:03 AM, lionel.morand@orange.com wrote: >=20 > Hi Alissa, >=20 > thank you for your review and sorry for this "late" feedback. >=20 > Here is my feedback as shepherd of the document. This needs to be = completed by draft authors and the AD. >=20 > Regards, >=20 > Lionel >=20 >>>>> (1) I find the absence of any definition of error handling = behavior >>>>> in this document to be a problem. I realize that the attributes >>>>> specified in this document are meant to be transmitted between >>>>> components that are all operated by the same administrative = entity, >>>>> but implementors can still make mistakes, and for those cases it >>>>> seems like error handling should be defined. >=20 > My understanding is that, when defining authorization type attributes = that are use over RADIUS, it is not deemed required to define the = specific use of these attributes nor the error handling. > As for other AAA documents, this draft is not specifying a specific = procedure or a new protocol application. It is just about defining = attributes that can be used in the use case described in this document = but also in any other solution that would see advantage to reuse these = attributes. The main point of this document is to ensure that the = definitions of these attributes are correct (type, length, value), = unambiguous and describe in which messages they can appear. > The exact behavior of the client/server using these attributes is = often left out of this kind of document. It is up to the specification = describing the implementation the clients and/or servers using these = attributes to define this error handling. Are there plans to specify the client-server interaction in a = standardized way? I can see why the sort of error-handling I described = might not fit in this document, but I don=E2=80=99t know how we end up = with interoperable clients and servers if there isn=E2=80=99t a = standardized understanding of the error handling. >=20 >=20 >>>>> (2) Section 3.1.2 says: >>>>>=20 >>>>> "For port allocation, both IP-Port-Range-Start TLV and IP- >>>>> Port-Range-End TLV must be included; for port deallocation, the >>>>> inclusion of these two TLVs is optional and if not included, it >>>>> implies that all ports that are previously allocated are now >>>>> deallocated." >>>>>=20 >>>>> How does an AAA server distinguish between port allocation and >>>>> deallocation requests if a deallocation request includes a range >>>>> start and range end? >=20 > If I'm correct, the answer is below: >=20 > 3.2.8. IP-Port-Alloc TLV >=20 > The format of IP-Port-Alloc TLV is shown in Figure 11. This > attribute carries IPFIX Information Element 230, "natEvent", which = is > a flag to indicate an action of NAT operation (refer to [IPFIX]). >=20 > When the value of natEvent is "1" (Create event), it means to > allocate a range of transport ports; when the value is "2", it means > to deallocate a range of transports ports. For the purpose of this > TLV, no other value is used. Got it, apologies for missing this. Thanks, Alissa >=20 >>>>> (3) The specification of IP-Port-Local-Id seems to allow for >>>>> unnecessary exposure of potentially sensitive information. There = is >>>>> no explanation given for why the combination of the other >>>>> identifiers included in IP-Port-Range and IP-Port-Forwarding >>>>> attributes is insufficient to identify the host in DS-Extra-Lite = and >>>>> Lightweight 4over6 cases. As defined, it sounds like = implementations >>>>> could put basically any user, device, or interface identifier in >>>>> there. If this TLV is actually necessary to communicate what these >>>>> attributes are trying to accomplish, the justification for it = should >>>>> be provided and the limitations on when this field may be used and >>>>> what kind of identifiers can appear here should be stated. >=20 > My understanding was that the IP-Port-Local-Id is required when it is = not possible to rely on an internal IPv4 or IPv6 address to identify an = ongoing session. > but authors can clarify the use of this attribute and address the = privacy concerns. >=20 > by the way, if not already spotted: >=20 > IP-Port-Int-IPv6-Addr TLV >=20 > This TLV contains an IPv4 address that is associated with the >=20 > s/ This TLV contains an IPv4 address/ This TLV contains an IPv6 = address >=20 > On the 4), I will answer in a separate email. >=20 > Lionel >=20 >> -----Message d'origine----- >> De : kathleen.moriarty.ietf@gmail.com >> [mailto:kathleen.moriarty.ietf@gmail.com] >> Envoy=C3=A9 : mardi 16 ao=C3=BBt 2016 23:16 >> =C3=80 : Alissa Cooper >> Cc : IESG; draft-ietf-radext-ip-port-radius-ext@ietf.org; MORAND = Lionel >> IMT/OLN; radext-chairs@ietf.org; radext@ietf.org >> Objet : Re: Alissa Cooper's Discuss on = draft-ietf-radext-ip-port-radius-ext-11: >> (with DISCUSS and COMMENT) >>=20 >>=20 >>=20 >> Sent from my iPhone >>=20 >>> On Aug 16, 2016, at 4:54 PM, Alissa Cooper = wrote: >>>=20 >>>=20 >>>> On Aug 16, 2016, at 4:41 PM, Kathleen Moriarty >> wrote: >>>>=20 >>>> Alissa, >>>>=20 >>>> Thanks for your detailed review, this is helpful. Hopefully we = will >>>> be able to resolve this with the editors and shepherd before = Thursday. >>>> I have one question in line that may help with the resolution for = at >>>> least #1 & #6. >>>>=20 >>>>> On Tue, Aug 16, 2016 at 3:02 PM, Alissa Cooper >> wrote: >>>>> Alissa Cooper has entered the following ballot position for >>>>> draft-ietf-radext-ip-port-radius-ext-11: Discuss >>>>>=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-radext-ip-port-radius-ex >>>>> t/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>> DISCUSS: >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>>=20 >>>>> (1) I find the absence of any definition of error handling = behavior >>>>> in this document to be a problem. I realize that the attributes >>>>> specified in this document are meant to be transmitted between >>>>> components that are all operated by the same administrative = entity, >>>>> but implementors can still make mistakes, and for those cases it >>>>> seems like error handling should be defined. For example: >>>>>=20 >>>>> - What happens if the AAA server sends an IP-Port-Limit-Info >>>>> attribute with a larger limit than the CGN is able to allocate to >>>>> that particular user? What is the CGN supposed to do and how is = that >>>>> communicated back to the AAA server? >>>>>=20 >>>>> - What happens if the CGN sends an IP-Port-Range attribute that >>>>> encompasses a larger range than a previously sent = IP-Port-Limit-Info? >>>>> What is the AAA server supposed to do? >>>>>=20 >>>>> - What happens if the AAA server sends an IP-Port-Forwarding-Map >>>>> attribute to map a port that is not within the requesting host's >>>>> allocated range? Is the CGN expected to change the mapping and = send >>>>> a CoA with a different IP-Port-Forwarding-Map, or communicate some >>>>> sort of error, or something else? >>>>>=20 >>>>> There are surely other error cases. I think it's worth going = through >>>>> the uses of each attribute and specifying all the error handling = behavior. >>>>> This seems especially important since part of the motivation for >>>>> these attributes is for identification and the consequences of >>>>> erroneous identification could be severe for the user. Discussion = of >>>>> those consequences is also missing from Section 6. >>>>=20 >>>> As an alternative, I usually approach this type of problem as >>>> defining what is acceptable and making everything else less >>>> acceptable. White lists are much easier to maintain and eliminate >>>> the possibility of missing something. If you and the WG agree, = could >>>> we go forward with that approach instead of defining all possible >>>> problems, just limiting what is acceptable and making everything = else an >> error? >>>=20 >>> I think it=E2=80=99s fine to say =E2=80=9Cthe only correct behavior = is X=E2=80=9D but you still need to say >> what implementations are expected to do when not-X happens. And X = will have >> different values for the different usages of each of these = attributes. >>>=20 >> Agreed, thanks. >>=20 >> Kathleen >>> Alissa >>>=20 >>>> This approach >>>> applies to a few of your other discuss points as well, namely #2, = #5, >>>> and to some degree #3. >>>>=20 >>>>>=20 >>>>> (2) Section 3.1.2 says: >>>>>=20 >>>>> "For port allocation, both IP-Port-Range-Start TLV and IP- >>>>> Port-Range-End TLV must be included; for port deallocation, the >>>>> inclusion of these two TLVs is optional and if not included, it >>>>> implies that all ports that are previously allocated are now >>>>> deallocated." >>>>>=20 >>>>> How does an AAA server distinguish between port allocation and >>>>> deallocation requests if a deallocation request includes a range >>>>> start and range end? Is the server supposed to assume that = whatever >>>>> range is specified by the most recently received IP-Port-Range >>>>> attribute represents the only range of allocated ports for the = host? >>>>> What is the meaning of sending an IP-Port-Range request with only = a >>>>> start value or an end value but not both (as seems to be allowable = by the >> above)? >>>>>=20 >>>>> (3) The specification of IP-Port-Local-Id seems to allow for >>>>> unnecessary exposure of potentially sensitive information. There = is >>>>> no explanation given for why the combination of the other >>>>> identifiers included in IP-Port-Range and IP-Port-Forwarding >>>>> attributes is insufficient to identify the host in DS-Extra-Lite = and >>>>> Lightweight 4over6 cases. As defined, it sounds like = implementations >>>>> could put basically any user, device, or interface identifier in >>>>> there. If this TLV is actually necessary to communicate what these >>>>> attributes are trying to accomplish, the justification for it = should >>>>> be provided and the limitations on when this field may be used and >>>>> what kind of identifiers can appear here should be stated. >>>>>=20 >>>>> (4) The shepherd write-up discusses two different approaches to >>>>> defining the sub-TLV types and then says: "Both approaches were >>>>> considered as valid and the WG has decided to let IANA decide what >>>>> the approach is preferred when allocating the TLV-Type for the >>>>> sub-TLVs defined in this document." This is not appropriate. The >>>>> document needs to explicitly define how the types should be >>>>> allocated and should not leave the decision to IANA. I see that = IANA >>>>> has already noted that Section 7.3 is ambiguous about this; the WG = needs to >> make a choice. >>>>=20 >>>> Thank you, and yes, the WG needs to make a decision. >>>>=20 >>>> Kathleen >>>>=20 >>>>>=20 >>>>> (5) Section 6 seems to be missing a discussion of the consequences >>>>> of communicating erroneous port range and port mapping = information. >>>>> Since part of the motivation for these attributes is = identification >>>>> of the host, this needs to be discussed. >>>>>=20 >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>> COMMENT: >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>>=20 >>>>> (1) What does it mean for an IP-Port-Range attribute to have >>>>> IP-Port-Type >>>>> 1 or 2? Can numbers in the whole range be used for any of the port >>>>> or identifier types? Or is the range expected to be split up = somehow >>>>> among the multiple types? I think this needs to be explained. >>>>>=20 >>>>> (2) In 4.1.4, how does the ISP know that Joe is traveling? >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>>=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From nobody Mon Sep 12 10:49:48 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA8412B01B; Mon, 12 Sep 2016 10:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=L+u2/lRU; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Qw5zsaYa 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 z81w8Cuqgp1Q; Mon, 12 Sep 2016 10:49:43 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862E612B018; Mon, 12 Sep 2016 10:49:42 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C5AD8208CA; Mon, 12 Sep 2016 13:49:41 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 12 Sep 2016 13:49:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=fLCYFmedRA/DB2bAiUldHFvsdsw=; b=L+u2/l RUaU7oGYTmY365/nA2xKVFJCl5gMHHq2p5O+H+8Kl7RTF/1iFBtQ+ZoMoARWIxBq N99F9D+04uyfIzSHPmmvRA+KkYyKJYfhNgavWr/vWZSRbynr6bGurLz0t6P/busc gGYEJ08CD7CpM3zQ2rqKln7bx4LbCEnaNMJ4c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=fLCYFmedRA/DB2b AiUldHFvsdsw=; b=Qw5zsaYaOeRTR9m/BkeYD36LbtZM3Z8eOzwvXameHaPMIF3 hPV9FIYVhuJlBkhEICbN7uRwympQn4Zf3T5pkVrxV34UztL3vyAu92t/ywBVPAtU OPoJXFY/JKec8DhlcQY9k2jXdoxU4O0hGIFn8ul0ogpvZGLUCMoFKfrKfBdw= X-Sasl-enc: sTCN92pNTeRi3A4NVgoqEu3/FDx51LuwY6lX668dMWge 1473702581 Received: from [10.24.127.108] (unknown [128.107.241.187]) by mail.messagingengine.com (Postfix) with ESMTPA id 185E3F2988; Mon, 12 Sep 2016 13:49:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Mon, 12 Sep 2016 13:49:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <73C567F3-5BE1-4B2F-8C9E-AF165AADB0DC@cooperw.in> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "kathleen.moriarty.ietf@gmail.com" , "radext@ietf.org" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 17:49:46 -0000 Hi Lionel, > On Sep 6, 2016, at 8:31 AM, lionel.morand@orange.com wrote: >=20 > Hi, >=20 > On the specific discussion on IANA, here is my summary for more = details. > When discussed in the group, two voices (Alan and myself) had two = different strong positions. > Other voices were neutral saying that both could work, without any = preference. Others didn't care. > In order not to block the process, it was concluded that IANA would be = maybe more appropriate to decide if my concerns about the registry = management are also an issue for them. And because IANA is part of the = IESG review process, it was thought that it was good to their feedback, = even if it means that we have to update the draft afterward. IETF last = calls are also for that purpose I think. I disagree. The WG needs to decide how it wants to structure the = registries. It can choose something complicated that will require more = work for IANA, or it can choose something simpler, but the WG should = choose whatever it thinks is best. IANA is involved in the last call = process to provide feedback about whether the instructions given to them = are clear, not to provide an opinion about how registries should be = structured. As long as the instructions are clear, IANA should be able = to create registries however the IETF chooses to specify them. Alissa >=20 > Now, in the details (text is short but illustrated with tables for = clarification of the concerns). >=20 > The current position in the draft is to allocate a unique value per = TLV, such as: >=20 > Name Value Meaning > ---- ----- ------- > IP-Port-Type 1 see Section 3.2.1 > IP-Port-Limit 2 see Section 3.2.2 > IP-Port-Ext-IPv4-Addr 3 see Section 3.2.3 > IP-Port-Int-IPv4-Addr 4 see Section 3.2.4 > IP-Port-Int-IPv6-Addr 5 see Section 3.2.5 > IP-Port-Int-Port 6 see Section 3.2.6 > IP-Port-Ext-Port 7 see Section 3.2.7 > IP-Port-Alloc 8 see Section 3.2.8 > IP-Port-Range-Start 9 see Section 3.2.9 > IP-Port-Range-End 10 see Section 3.2.10 > IP-Port-Local-Id 11 see Section 3.2.11 >=20 > Which means that whatever the parent attribute, value 1 will have to = be reserved for IP-Port, value 2 for IP-Port-Limit, etc. even if these = TLVs are never unused in these attributes. > The argument given by Alan is that "a TLV called "foo" should have the = same TLV-Type value (e.g. 1) across multiple parent TLVs. There is = enough space to do sparse allocation."=20 >=20 > However, the allocation rule for TLV is defined as follow in the = RFC6929: >=20 > 10.3.6. Allocation within a TLV >=20 > Specifications can request allocation of Attribute Type values = within > an Attribute of data type TLV. The encapsulating TLV can be > allocated in the same specification, or it can have been previously > allocated. >=20 > Specifications need to request allocation within a specific = Attribute > Type value (e.g., "TYPE.TLV.*"). Allocations are performed from the > smallest Unassigned value, proceeding to the largest Unassigned > value. >=20 > Moreover, in section 2.3. "TLV Data Type" of the same RFC, it is = said: >=20 > As with the Extended-Type field defined above, the TLV-Type is > meaningful only within the context defined by "Type" fields of = the > encapsulating Attributes. That is, the field may be thought of = as > defining a new type space of the form > "Type.Extended-Type.TLV-Type". Where TLVs are nested, the type > space is of the form "Type.Extended-Type.TLV-Type.TLV-Type", etc. >=20 > Following these recommendations, the section 7.3 should be revised as = follow, with a TLV-Type defined per parent attribute: >=20 > 7.3. IANA Considerations on New RADIUS Sub-attributes >=20 > This specification requests allocation of the following = sub-attributes within > the attribute IP-Port-Limit-Info 241.TBD1: >=20 > Identifier Name =20 > -------------- --------------=20 > 241.TBD1.1 IP-Port-Type =20 > 241.TBD1.2 IP-Port-Limit =20 > 241.TBD1.3 IP-Port-Ext-IPv4-Addr > 241. TBD1.{4-253} Unassigned > 245. TBD1.{254-255} Reserved >=20 > This specification requests allocation of the following = sub-attributes within > the attribute IP-Port-Range 241.TBD2: >=20 > Identifier Name =20 > ---- ---- =20 > 241.TBD2.1 IP-Port-Type-1 =20 > 241.TBD2.2 IP-Port-Ext-IPv4-Addr-1 > 241.TBD2.3 IP-Port-Local-Id-1 =20 > 241.TBD2.4 IP-Port-Alloc =20 > 241.TBD2.5 IP-Port-Range-Start > 241.TBD2.6 IP-Port-Range-End =20 > 241. TBD2.{7-253} Unassigned > 245. TBD2.{254-255} Reserved >=20 > This specification requests allocation of the following = sub-attributes within > the attribute IP-Port-Forwarding-Map 241.TBD3: >=20 > Type Name =20 > ---- ---- =20 > 241.TBD3.1 IP-Port-Type-2=20 > 241.TBD3.2 IP-Port-Ext-IPv4-Addr-2 > 241.TBD3.3 IP-Port-Local-Id-1 > 241.TBD3.4 IP-Port-Int-IPv4-Addr=20 > 241.TBD3.5 IP-Port-Int-IPv6-Addr=20 > 241.TBD3.6 IP-Port-Int-Port=20 > 241.TBD3.7 IP-Port-Ext-Port > 241. TBD3.{8-253} Unassigned > 245. TBD3.{254-255} Reserved >=20 > Here is an "example" of what would look like after the Radius = Attribute Types registry after publication of the new RFC. >=20 > 241 Extended-Attribute-1 [RFC6929] > 241.1 Frag-Status [RFC7499] > 241.2 Proxy-State-Length [RFC7499] >=20 > 241.3 IP-Port-Limit-Info NEW RFC > 241.3.1 IP-Port-Type-1 NEW RFC > 241.3.2 IP-Port-Ext-IPv4-Addr-1 = NEW RFC > 241.3.3 IP-Port-Limit NEW RFC > 241.3.{4-253} Unassigned NEW RFC > 245.3.{254-255} Reserved NEW RFC >=20 > 241.4 IP-Port-Range NEW RFC > 241.4.1 IP-Port-Type-2 NEW RFC > 241.4.2 IP-Port-Ext-IPv4-Addr-2 NEW RFC > 241.4.3 IP-Port-Local-Id-1 NEW RFC > 241.4.4 IP-Port-Alloc NEW RFC > 241.4.5 IP-Port-Range-Start NEW RFC > 241.4.6 IP-Port-Range-End NEW RFC > 241.4.{7-253} Unassigned NEW RFC > 245.4.{254-255} Reserved NEW RFC >=20 > 241.5 IP-Port-Forwarding-Map NEW RFC > 241.5.1 IP-Port-Type-3 NEW RFC > 241.5.2 IPort-Ext-IPv4-Addr-3 NEW RFC > 241.5.3 IP-Port-Local-Id-2 NEW RFC > 241.5.4 IP-Port-Int-IPv4-Addr NEW RFC > 241.5.5 IP-Port-Int-IPv6-Addr NEW RFC > 241.5.6 IP-Port-Int-Port = NEW RFC > 241.5.7 IP-Port-Ext-Port NEW RFC > 241.5.{8-253} Unassigned NEW RFC > 245.5.{254-255} Reserved NEW RFC >=20 > 241.{6-25} Unassigned=09 > 241.26 Extended-Vendor-Specific-1 = [RFC6929] > 241.{27-240} Unassigned=09 > 241.{241-255} Reserved [RFC6929] >=20 > This approach is straightforward for IANA in terms of allocation and I = still don't see the real issue from a dictionary point of view. >=20 > In the other hand, here is an "example" of what would look like the = registry if Alan's proposal is accepted. >=20 > 241 Extended-Attribute-1 [RFC6929] > 241.1 Frag-Status [RFC7499] > 241.2 Proxy-State-Length [RFC7499] >=20 > 241.3 IP-Port-Limit-Info NEW RFC > 241.3.1 IP-Port-Type NEW RFC > 241.3.2 IP-Port-Ext-IPv4-Addr = NEW RFC > 241.3.3 IP-Port-Limit NEW RFC > 241.3.{4-11} Reserved NEW RFC > 241.3.{12-253} Unassigned NEW RFC > 241.3.{254-255} Reserved NEW RFC >=20 > 241.4 IP-Port-Range NEW RFC > 241.4.1 IP-Port-Type NEW RFC > 241.4.2 IP-Port-Ext-IPv4-Addr NEW RFC > 241.4.3 Reserved NEW RFC > 241.4.4 IP-Port-Local-Id = NEW RFC > 241.4.5 IP-Port-Alloc NEW RFC > 241.4.6 IP-Port-Range-Start NEW RFC > 241.4.7 IP-Port-Range-End NEW RFC > 241.4.{8-11} Reserved NEW RFC > 241.4.{12-253} Unassigned NEW RFC > 241.4.{254-255} Reserved NEW RFC >=20 > 241.5 IP-Port-Forwarding-Map NEW RFC > 241.5.1 IP-Port-Type NEW RFC > 241.5.2 IPort-Ext-IPv4-Addr NEW RFC > 241.5.3 Reserved NEW RFC > 241.5.4 IP-Port-Local-Id = NEW RFC > 241.5.5 Reserved NEW RFC > 241.5.6 Reserved NEW RFC > 241.5.7 Reserved NEW RFC > 241.5.8 IP-Port-Int-IPv4-Addr NEW RFC > 241.5.9 IP-Port-Int-IPv6-Addr NEW RFC > 241.5.10 IP-Port-Int-Port = NEW RFC > 241.5.11 IP-Port-Ext-Port NEW RFC > 241.5.{12-253} Unassigned NEW RFC > 241.5.{254-255} Reserved NEW RFC >=20 > And the values x.x.{1-11} will have to be reserved for any new = attribute of type "TLV" defined in the ranges 241.{6-240}, 242.{1-240}, = 243.{1-240}, 244.{1-240}, 245.{1-240} and 246.{1-240}. > It would be like defining a new registry for sub-TLVs. That is, in my = opinion, in contradiction with the definition of the TLV data type given = in section 7.3 of RFC6929 (see above). >=20 > I hope that this clarifies my point. >=20 > regards, >=20 > Lionel >=20 >> -----Message d'origine----- >> De : kathleen.moriarty.ietf@gmail.com >> [mailto:kathleen.moriarty.ietf@gmail.com] >> Envoy=C3=A9 : mardi 16 ao=C3=BBt 2016 23:16 >> =C3=80 : Alissa Cooper >> Cc : IESG; draft-ietf-radext-ip-port-radius-ext@ietf.org; MORAND = Lionel >> IMT/OLN; radext-chairs@ietf.org; radext@ietf.org >> Objet : Re: Alissa Cooper's Discuss on = draft-ietf-radext-ip-port-radius-ext-11: >> (with DISCUSS and COMMENT) >>=20 >>=20 >>=20 >> Sent from my iPhone >>=20 >>> On Aug 16, 2016, at 4:54 PM, Alissa Cooper = wrote: >>>=20 >>>=20 >>>> On Aug 16, 2016, at 4:41 PM, Kathleen Moriarty >> wrote: >>>>=20 >>>> Alissa, >>>>=20 >>>> Thanks for your detailed review, this is helpful. Hopefully we = will >>>> be able to resolve this with the editors and shepherd before = Thursday. >>>> I have one question in line that may help with the resolution for = at >>>> least #1 & #6. >>>>=20 >>>>> On Tue, Aug 16, 2016 at 3:02 PM, Alissa Cooper >> wrote: >>>>> Alissa Cooper has entered the following ballot position for >>>>> draft-ietf-radext-ip-port-radius-ext-11: Discuss >>>>>=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-radext-ip-port-radius-ex >>>>> t/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>> DISCUSS: >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>>=20 >>>>> (1) I find the absence of any definition of error handling = behavior >>>>> in this document to be a problem. I realize that the attributes >>>>> specified in this document are meant to be transmitted between >>>>> components that are all operated by the same administrative = entity, >>>>> but implementors can still make mistakes, and for those cases it >>>>> seems like error handling should be defined. For example: >>>>>=20 >>>>> - What happens if the AAA server sends an IP-Port-Limit-Info >>>>> attribute with a larger limit than the CGN is able to allocate to >>>>> that particular user? What is the CGN supposed to do and how is = that >>>>> communicated back to the AAA server? >>>>>=20 >>>>> - What happens if the CGN sends an IP-Port-Range attribute that >>>>> encompasses a larger range than a previously sent = IP-Port-Limit-Info? >>>>> What is the AAA server supposed to do? >>>>>=20 >>>>> - What happens if the AAA server sends an IP-Port-Forwarding-Map >>>>> attribute to map a port that is not within the requesting host's >>>>> allocated range? Is the CGN expected to change the mapping and = send >>>>> a CoA with a different IP-Port-Forwarding-Map, or communicate some >>>>> sort of error, or something else? >>>>>=20 >>>>> There are surely other error cases. I think it's worth going = through >>>>> the uses of each attribute and specifying all the error handling = behavior. >>>>> This seems especially important since part of the motivation for >>>>> these attributes is for identification and the consequences of >>>>> erroneous identification could be severe for the user. Discussion = of >>>>> those consequences is also missing from Section 6. >>>>=20 >>>> As an alternative, I usually approach this type of problem as >>>> defining what is acceptable and making everything else less >>>> acceptable. White lists are much easier to maintain and eliminate >>>> the possibility of missing something. If you and the WG agree, = could >>>> we go forward with that approach instead of defining all possible >>>> problems, just limiting what is acceptable and making everything = else an >> error? >>>=20 >>> I think it=E2=80=99s fine to say =E2=80=9Cthe only correct behavior = is X=E2=80=9D but you still need to say >> what implementations are expected to do when not-X happens. And X = will have >> different values for the different usages of each of these = attributes. >>>=20 >> Agreed, thanks. >>=20 >> Kathleen >>> Alissa >>>=20 >>>> This approach >>>> applies to a few of your other discuss points as well, namely #2, = #5, >>>> and to some degree #3. >>>>=20 >>>>>=20 >>>>> (2) Section 3.1.2 says: >>>>>=20 >>>>> "For port allocation, both IP-Port-Range-Start TLV and IP- >>>>> Port-Range-End TLV must be included; for port deallocation, the >>>>> inclusion of these two TLVs is optional and if not included, it >>>>> implies that all ports that are previously allocated are now >>>>> deallocated." >>>>>=20 >>>>> How does an AAA server distinguish between port allocation and >>>>> deallocation requests if a deallocation request includes a range >>>>> start and range end? Is the server supposed to assume that = whatever >>>>> range is specified by the most recently received IP-Port-Range >>>>> attribute represents the only range of allocated ports for the = host? >>>>> What is the meaning of sending an IP-Port-Range request with only = a >>>>> start value or an end value but not both (as seems to be allowable = by the >> above)? >>>>>=20 >>>>> (3) The specification of IP-Port-Local-Id seems to allow for >>>>> unnecessary exposure of potentially sensitive information. There = is >>>>> no explanation given for why the combination of the other >>>>> identifiers included in IP-Port-Range and IP-Port-Forwarding >>>>> attributes is insufficient to identify the host in DS-Extra-Lite = and >>>>> Lightweight 4over6 cases. As defined, it sounds like = implementations >>>>> could put basically any user, device, or interface identifier in >>>>> there. If this TLV is actually necessary to communicate what these >>>>> attributes are trying to accomplish, the justification for it = should >>>>> be provided and the limitations on when this field may be used and >>>>> what kind of identifiers can appear here should be stated. >>>>>=20 >>>>> (4) The shepherd write-up discusses two different approaches to >>>>> defining the sub-TLV types and then says: "Both approaches were >>>>> considered as valid and the WG has decided to let IANA decide what >>>>> the approach is preferred when allocating the TLV-Type for the >>>>> sub-TLVs defined in this document." This is not appropriate. The >>>>> document needs to explicitly define how the types should be >>>>> allocated and should not leave the decision to IANA. I see that = IANA >>>>> has already noted that Section 7.3 is ambiguous about this; the WG = needs to >> make a choice. >>>>=20 >>>> Thank you, and yes, the WG needs to make a decision. >>>>=20 >>>> Kathleen >>>>=20 >>>>>=20 >>>>> (5) Section 6 seems to be missing a discussion of the consequences >>>>> of communicating erroneous port range and port mapping = information. >>>>> Since part of the motivation for these attributes is = identification >>>>> of the host, this needs to be discussed. >>>>>=20 >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>> COMMENT: >>>>> = -------------------------------------------------------------------- >>>>> -- >>>>>=20 >>>>> (1) What does it mean for an IP-Port-Range attribute to have >>>>> IP-Port-Type >>>>> 1 or 2? Can numbers in the whole range be used for any of the port >>>>> or identifier types? Or is the range expected to be split up = somehow >>>>> among the multiple types? I think this needs to be explained. >>>>>=20 >>>>> (2) In 4.1.4, how does the ISP know that Joe is traveling? >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>>=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From nobody Mon Sep 12 11:02:28 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C6FFA12B006; Mon, 12 Sep 2016 11:02:26 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A28127058 for ; Mon, 12 Sep 2016 11:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.707 X-Spam-Level: X-Spam-Status: No, score=-4.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 Pb4deA_cCEaw for ; Mon, 12 Sep 2016 11:02:25 -0700 (PDT) Received: from smtp02.icann.org (smtp01.icann.org [192.0.46.81]) (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 946D312B00F for ; Mon, 12 Sep 2016 11:02:25 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp02.icann.org (Postfix) with ESMTP id D713EE3433 for ; Mon, 12 Sep 2016 18:02:24 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id A026DC20267; Mon, 12 Sep 2016 18:02:24 +0000 (UTC) RT-Owner: sabrina.tanamal From: "Sabrina Tanamal via RT" In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #922685 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: sabrina.tanamal@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 12 Sep 2016 18:02:24 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160912180226.C6FFA12B006@ietfa.amsl.com> Resent-Date: Mon, 12 Sep 2016 11:02:26 -0700 (PDT) Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext.all@ietf.org Subject: [radext] [IANA #922685] expert review for draft-ietf-radext-ip-port-radius-ext (IP Flow Information Export (IPFIX) Entities) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: drafts-expert-review-comment@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 18:02:27 -0000 Dear Authors, Without approval from the registry experts, we will not be able to complete the registrations completed by this document. Will there be a new version available for review? Thank you, Sabrina Tanamal IANA Specialist ICANN On Sat Aug 20 00:29:38 2016, amanda.baber wrote: > Dear Authors, > > The experts for the IPFIX IE registry have returned the following > review: > > In general, the Information Elements in draft-ietf-radext-ip-port- > radius-ext are so underspecified as to be unimplementable. They should > not be added to the registry in their present form. The authors are > advised to read RFC 7013, especially Section 4, which provides useful > information on defining Information Elements. Specifically: > > The Information Element transportType is underspecified: (a) I presume > this is in reference to sourceTransportPort and > destinationTransportPort, but the description must say this if it is > the case; (b) It's not clear at all from the description in what > context this distinction is useful; (c) What's an ICMP identifier? > > In addition, the description of transportType appears to create a > table which should probably be handled as a subregistry. See See > RFC7013 section 4.7. for advice on the creation of tables without > subregistries (in short, "don't".) > > The Information Element natTransportLimit has an inappropriate name; > it does not describe that which it (presumably) is supposed to > represent (see RFC 7013 section 4.1). In addition, it is > underspecified. It is impossible to implement from the description. Is > the field IPv4 specific, or is IPv6 supported as well? (If not, why > not?) > > The Information Element localID has an inappropriate name; it is far > too general (see RFC 7013 section 4.1). It uses an inappropriate > abstract data type (addresses should never be represented as UTF-8 > strings in IPFIX, see RFC 7013 section 4.2). It is underspecified as > well as poorly designed. Without the ability to disambiguate the type > of information in the field, this is not a useful Information Element. > Without a complete enumeration of possible types (n.b. 'etc.' in the > description), it is not a useful Information Element. Its purpose is > unclear from its description; further, it appears to violate the > following guidance in RFC 7013 section 4: "The Information Element > must be unique within the registry, and its description must represent > a substantially different meaning from that of any existing > Information Element. An existing Information Element that can be > reused for a given purpose should be reused." > > Best regards, > > Amanda Baber > IANA Lead Specialist > ICANN From nobody Tue Sep 13 06:41:12 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D4312B736; Tue, 13 Sep 2016 06:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 mfmLMd4SMYF0; Tue, 13 Sep 2016 06:41:03 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAF312B584; Tue, 13 Sep 2016 06:24:01 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 1D0CCC07D2; Tue, 13 Sep 2016 15:24:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id DBEBB200CC; Tue, 13 Sep 2016 15:23:59 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0301.000; Tue, 13 Sep 2016 15:23:59 +0200 From: To: Alan DeKok Thread-Topic: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHSCFDrJHPCcWo6q0uDplNMG5A9GKB3RQkQ Date: Tue, 13 Sep 2016 13:23:59 +0000 Message-ID: <1813_1473773040_57D7FDEF_1813_3639_1_6B7134B31289DC4FAF731D844122B36E01FAA8D8@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> In-Reply-To: <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , Alissa Cooper , "kathleen.moriarty.ietf@gmail.com" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 13:41:10 -0000 Hi Alan, If such a registry is defined by the WG and managed by the IANA, to ensure = that a newly-defined sub-TLV can be reused in any parent TLV, we are limiti= ng de-facto the number of possible sub-TLV values to 253 values (254-255 be= ing anyway reserved for future use)? Moreover, an update of the allocation policy given in the RFC6929 sect. 10.= 3.6 would be required. In comparison, according to the RFC6929, it is possible to define up to 253= sub-TLV *per* TLV attributes at the first level. It means that it is theor= etically possible to define approximatively up to +/- 380.000 distinct sub= -TLV at the first level. I think that limiting to 253 values just to enable to use the same sub-TLV = in multiple parent attribute is too restrictive.=20 If one solution has to choose, I would go with the most flexible one. regards, Lionel > -----Message d'origine----- > De=A0: Alan DeKok [mailto:aland@deployingradius.com] > Envoy=E9=A0: mardi 6 septembre 2016 17:11 > =C0=A0: MORAND Lionel IMT/OLN > Cc=A0: kathleen.moriarty.ietf@gmail.com; Alissa Cooper; draft-ietf-radext= -ip-port- > radius-ext@ietf.org; radext@ietf.org; IESG; radext-chairs@ietf.org > Objet=A0: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-po= rt-radius- > ext-11: (with DISCUSS and COMMENT) >=20 > On Sep 6, 2016, at 11:03 AM, > wrote: > > " In this case, there are multiple parent attributes which define essen= tially the > same sub-TLVs. It would be nice to be able to re-use these these sub-TLV= s, > without having multiple different definitions for them." > > > > How do you know that a newly defined sub-TLV will/may be reused or not = in > other (future) parent attributes? >=20 > You know that the sub-TLVs are re-used in the current spec. Future att= ributes > are largely a future problem. >=20 > > In the document describing the new attribute, you may have a clear idea= about > the use in multiple parent attributes for one sub-TLV (Foo) and you may c= onsider > that another sub-TLV (Bar) will be used only once. But tomorrow, for anot= her > purpose, the sub-TLV Bar appears to be really useful and it is decided to= use it in > multiple (new) attributes. > > > > How will you ensure that the same value can be reused for Bar if not re= served? >=20 > Which is why I agreed with the idea to create a registry for the sub-TL= Vs. >=20 > Alan DeKok. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Sep 13 06:44:10 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 33FEF12B59F; Tue, 13 Sep 2016 06:44:08 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF5F12B4C1 for ; Tue, 13 Sep 2016 06:44:08 -0700 (PDT) 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 lS8iIWNSNi3k for ; Tue, 13 Sep 2016 06:44:03 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 D149F12B59F for ; Tue, 13 Sep 2016 06:25:56 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id 16so157627151vko.2 for ; Tue, 13 Sep 2016 06:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dxlB24qqideqE9CBpWI1OQQMsxWpIZsVrm+S88QsyXM=; b=CQkick609YqFYVTGt4BUPXfOS2UXSdoujVOor7L6xQE12yEGPEawgiFjQkH4OpOPrt w9xNH+ksAb56mlXSjRxY5ehyPFA9xBDjzIZKSu3GMqesca11S3la01oIu6l0By8J3dSx 2ZoFjFYiOQiOC1la382QcakMcDVCAOvNOG/b21D7gxiN3heYduoJXJKWppS4fAbbf7Sa KH5kJtOwCWsnpDqlWxvIstU762n6eKgpHbpI2gtUlinoxq49x7ffhNeZwNKl/slGcoJV /9T/T/ld9ny907C2Zxe0r0N/5Xcn2yrl+AFygUpCguaWI9jmcli3jxk42Q0WE7OH20uW Id7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dxlB24qqideqE9CBpWI1OQQMsxWpIZsVrm+S88QsyXM=; b=kIlmpZhv8O2nE2hbr/Wl4SiysisHP6q244/0xaGO+Wr2MjTXDKiODe8WjhvPWAmc0/ kxLhc+jZoEtNfYUh8u6Ypvea1AG2j98lXXQzG04YPprBtnpvQuDl+P93q9ZNEwCALdT9 9ffHuTPCGPdhw+UagL/pFJEiINUQYtIkVygfAn/BEWWg4Qv++4UmoZlKIedFVeB5SIeM JUDz2ZCuqbmEpTfmI0eWAxXgjU9rjx/qeapqF9rLGU0NY/Hmjk5BYTLN8pMQ9YpGrrtY QJTliR8lopJTWOiRSX1Yjc8WSEL3Bh5vUfn79rl5VsJZ68isrdck2ebZ9t5vgb/cvf2R vIeQ== X-Gm-Message-State: AE9vXwN/0jdwvCqhNqqPwX9aRvDs5VmLrHIByN8X6sOsJqWI+ox95EFnZKvm+Bjj04lZGbkUyE8Z/48g3d4LMQ== X-Received: by 10.31.221.3 with SMTP id u3mr685526vkg.25.1473773155727; Tue, 13 Sep 2016 06:25:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Tue, 13 Sep 2016 06:25:55 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Tue, 13 Sep 2016 09:25:55 -0400 Message-ID: To: "drafts-expert-review-comment@iana.org" Content-Type: text/plain; charset=UTF-8 Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160913134408.33FEF12B59F@ietfa.amsl.com> Resent-Date: Tue, 13 Sep 2016 06:44:08 -0700 (PDT) Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext.all@ietf.org Subject: Re: [radext] [IANA #922685] expert review for draft-ietf-radext-ip-port-radius-ext (IP Flow Information Export (IPFIX) Entities) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 13:44:08 -0000 Thank you, Sabrina. The radext editors will make the changes, but it is up to the IESG to approve the document (not the IPFIX experts). Thanks, Kathleen On Mon, Sep 12, 2016 at 2:02 PM, Sabrina Tanamal via RT wrote: > Dear Authors, > > Without approval from the registry experts, we will not be able to complete the registrations completed by this document. Will there be a new version available for review? > > Thank you, > > Sabrina Tanamal > IANA Specialist > ICANN > > On Sat Aug 20 00:29:38 2016, amanda.baber wrote: >> Dear Authors, >> >> The experts for the IPFIX IE registry have returned the following >> review: >> >> In general, the Information Elements in draft-ietf-radext-ip-port- >> radius-ext are so underspecified as to be unimplementable. They should >> not be added to the registry in their present form. The authors are >> advised to read RFC 7013, especially Section 4, which provides useful >> information on defining Information Elements. Specifically: >> >> The Information Element transportType is underspecified: (a) I presume >> this is in reference to sourceTransportPort and >> destinationTransportPort, but the description must say this if it is >> the case; (b) It's not clear at all from the description in what >> context this distinction is useful; (c) What's an ICMP identifier? >> >> In addition, the description of transportType appears to create a >> table which should probably be handled as a subregistry. See See >> RFC7013 section 4.7. for advice on the creation of tables without >> subregistries (in short, "don't".) >> >> The Information Element natTransportLimit has an inappropriate name; >> it does not describe that which it (presumably) is supposed to >> represent (see RFC 7013 section 4.1). In addition, it is >> underspecified. It is impossible to implement from the description. Is >> the field IPv4 specific, or is IPv6 supported as well? (If not, why >> not?) >> >> The Information Element localID has an inappropriate name; it is far >> too general (see RFC 7013 section 4.1). It uses an inappropriate >> abstract data type (addresses should never be represented as UTF-8 >> strings in IPFIX, see RFC 7013 section 4.2). It is underspecified as >> well as poorly designed. Without the ability to disambiguate the type >> of information in the field, this is not a useful Information Element. >> Without a complete enumeration of possible types (n.b. 'etc.' in the >> description), it is not a useful Information Element. Its purpose is >> unclear from its description; further, it appears to violate the >> following guidance in RFC 7013 section 4: "The Information Element >> must be unique within the registry, and its description must represent >> a substantially different meaning from that of any existing >> Information Element. An existing Information Element that can be >> reused for a given purpose should be reused." >> >> Best regards, >> >> Amanda Baber >> IANA Lead Specialist >> ICANN > > > -- Best regards, Kathleen From nobody Tue Sep 13 07:12:02 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C022B12B56F; Tue, 13 Sep 2016 07:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 V5GS1jXjuDxp; Tue, 13 Sep 2016 07:11:54 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9466A12B715; Tue, 13 Sep 2016 06:39:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 8D1D11DDF; Tue, 13 Sep 2016 13:39:39 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH1bkEKH0X_j; Tue, 13 Sep 2016 13:39:39 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 7BF6B5FD; Tue, 13 Sep 2016 13:39:38 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <1813_1473773040_57D7FDEF_1813_3639_1_6B7134B31289DC4FAF731D844122B36E01FAA8D8@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Tue, 13 Sep 2016 09:39:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <23CAC502-C1F0-4DD6-AB82-8A38BD6D0B88@deployingradius.com> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <28413_1473165080_57CEB718_28413_354_4_6B7134B31289DC4FAF731D844122B36E01F9F38E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4DCE81CA-FC1F-4CFF-82E1-135E158087C6@deployingradius.com> <9128_1473174225_57CEDAD1_9128_1350_1_6B7134B31289DC4FAF731D844122B36E01F9F961@OPEXCLILM43.corporate.adroot.infra.ftgroup> <4B308285-584D-4A53-BCA0-F1EC1F9C3BC9@deployingradius.com> <1813_1473773040_57D7FDEF_1813_3639_1_6B7134B31289DC4FAF731D844122B36E01FAA8D8@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , Alissa Cooper , "kathleen.moriarty.ietf@gmail.com" , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 14:12:00 -0000 > On Sep 13, 2016, at 9:23 AM, = wrote: > If such a registry is defined by the WG and managed by the IANA, to = ensure that a newly-defined sub-TLV can be reused in any parent TLV, No. Those sub-TLVs can only be re-used in *appropriate* parent TLVs. = The parents need to specify that they are using the common registry. = All other TLV parents are free to specify whatever sub-TLVs they want. Alan DeKok. From nobody Tue Sep 13 09:15:57 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A1212B406; Tue, 13 Sep 2016 09:15:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147378335661.23599.14360522901667394673.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2016 09:15:56 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Joel Jaeggli's No Objection on draft-ietf-radext-ip-port-radius-ext-11: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 16:15:57 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-11: 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-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Tim Chown Tim.Chown@jisc.ac.uk provided the opdir review. At this time, this position is not a discuss, but I would like to see a discussion or pointer to a dicussion on the role of this method vs pcp. thanks joel Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines three new RADIUS attributes to be used when communicating with a RADIUS server to facilitate the configuration or reporting of IP and port ranges used with a network appliance, typically a CGN, where there is a need to constrain the ports available per customer where IP address sharing is in use. The three RADIUS attributes are: IP-Port-Limit-Info - defines the maximum number of ports available IP-Port-Range - the specific range of port numbers available IP-Port-Forwarding-Map - to configure port forwarding on a NAT/CGN device I would consider the document to be "Ready with Issues". I have some general comments, followed by some specific comments. Note that while I am familiar with RADIUS (from an eduroam context) the draft is not one I was familiar with or followed prior to this review. Thus these comments may have already been addressed. General comments: There are at least two areas in which this document has "creep". One is that it is providing an alternative method to PCP to define port forwarding mappings on a device. So there is an open question as to whether PCP should be the method of choice for this function, or whether we wish to create a new way to establish such mappings. Secondly, two of the new attributes support inclusion of a new TLV, IP-Port-Local-Id, which allows user/device-specific information to be transmitted via RADIUS, such as MAC address or VLAN ID. While this is intended to allow differentiation of users for accounting/identification r, in doing so it adds an additional potential privacy concern into a new RADIUS attribute, depending on specific use cases of the TLV. This is not discussed in the Security Considerations section, but probably should be. I note the new attributes use a number of IPFIX information elements; has the draft considered its relationship to draft-ietf-behave-ipfix-nat-logging-09, which says the "lack of a consistent way to log the data makes it difficult to write the collector applications that would receive this data and process it to present useful information"? This draft is introducing a new method to log such elements; is this a concern at all? The examples of use cases of the new attributes include both NAT44 devices and CGNs. The document could state more clearly the address sharing scenarios, perhaps with a simplified network element diagram for each example, showing the user/host, CPE/NAT44, and NAT444/CGN? Some additional clarity here would be useful (see also comments below). Also, the term "the user" is used in many places in the document where in practice "the customer's CPE" would be more appropriate. Specific comments: NAT64 is mentioned as a use case at the start, but no example is given later in the document. This might add useful value. In Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elements in the TLV are 16 bit values, but 32 bits are reserved for the element. Similarly the NatEvent element is 8-bit, but has 32 bits reserved. It would be useful if the document stated why these elements are being padded out to 32 bits. In Section 4.1.1, I don't think NAT64 is specifically designed to multiplex users over a smaller number of shared IPv4 addresses, rather its primary design goal is to facilitate access to legacy IPv4 content from IPv6-only networks. The text should be clarified. Also in 4.1.1, do users really have service agreements that state port limits? If they do, I doubt users are aware of them (or care...), and the issue is beyond the scope of this document. In 4.1.2, I think you mean "block", not "bulk"? And the comment on "randomization" might fit better in the Security Considerations section if you discuss privacy there (which is presumably what you mean?) Also in 4.1.2 you discuss the scenario as if it's CGN, but the flow diagram shows only the NAT44 (presumably in the CPE) and not an ISP CGN. The same happens in 4.1.3; discussion of CGN and NAT44 interchangeably, without the diagram showing there may (presumably) be mappings to establish at both the user's CPE and the ISP's CGN. And in 4.1.4 the example talks of NAT44 for Joe's CPE, but then also about a CGN allocating more ports; is that at the NAT44, or at the CGN? (These specific NAT44/CGN comments are examples of the general comment I made earlier.) In Section 5, I found the format of the table with 0 and 0+ a little unintuitive. -- Tim _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir From nobody Wed Sep 14 15:56:14 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1D812B0D8; Wed, 14 Sep 2016 15:56:12 -0700 (PDT) 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.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147389377247.29884.8510043117785245776.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 15:56:12 -0700 Archived-At: Cc: draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Stephen Farrell's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 22:56:12 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-11: 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-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Sorry for not spotting this in other documents, but do we understand the privacy characteristics of this ICMP identifier? It may well be that the resolution of this discuss requires some other document to exist (in which case I'll get out of the way of this one) but I think we ought be quite cautious in how we introduce new functions for identifiers that may be personally identifying, so I'd like to chat about this a bit. Did the WG discuss the privacy issues associated with this identifier? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - write-up: Yeah, major yuks to leaving design decisions to IANA. While the folks there are quite capable, they are not able to make IETF consensus decisions. If the WG aren't sure, ask IANA personnel (or someone) and then verify that that outcome garners rough consensus back in the WG or using other IETF processes. So Alissa's discuss point#4 is entirely, completely and fully correct and a showstopper really. - I also agree with the issue called out in Joel's comment about mission creep and how this overlaps with PCP. Did the WG consider whether or not it is a good idea for the IETF to define multiple ways in which some of these features can be added? If so, what is the justification for there being more than one? (Is that somewhere in the WG list archive? If not, it ought be.) It may well be that having a RADIUS mechanism for this is also a good plan, but I think that ought be justified. - 4.1.4: using port 80 as an example is very 1990's. Would it not be better to be more up to date? That's not just a facetious point - web cameras being left open to the Internet are a major swamp for botnet gestation. Better to use a more desirable example really. - The secdir review [1] also noted a bunch of issues that as far as I can see received no response so far, but that do deserve a response. (Apologies if I missed a response.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06736.html From nobody Wed Sep 14 19:02:16 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD54A12B117; Wed, 14 Sep 2016 19:02:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147390493480.29837.13062685844459913591.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 19:02:14 -0700 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 02:02:15 -0000 IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Wed Sep 14 19:02:55 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FA312B117; Wed, 14 Sep 2016 19:02:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , "The IESG" , , X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147390497384.29804.17105379193063239992.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 19:02:53 -0700 From: IETF Secretariat Archived-At: Subject: [radext] Telechat update notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 02:02:54 -0000 Telechat date has been changed to 2016-09-29 from 2016-09-15 ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Wed Sep 14 19:06:45 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6206E12B117 for ; Wed, 14 Sep 2016 19:06:44 -0700 (PDT) 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 3v4x3del5WDa for ; Wed, 14 Sep 2016 19:06:42 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 A46FF12B03F for ; Wed, 14 Sep 2016 19:06:42 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id m62so6469437vkd.3 for ; Wed, 14 Sep 2016 19:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=c4d3YcnEsWepl47RUEIc/Nk1RRbgO1RkVh7tG+++jdw=; b=e43jF8XifZpJJBaJktZ4r21XVL0otFXAIfbUJmp/R8kz5FVEMSL3MFj7g5HETtvLbe 9+Jcud+3HkSUBdqnfuCLYeMtEcMUluUkVyXN2eWBgDLFmuF8bjZi61NqRd8kM8kROP6g OUrqJ3XQcL3jqaex3GPvN9wSkJNDLplq795t5tCNnsKLYJeJHF7R3imBH9DkotQvKZVg lvRw1HOfBwdopn3R76TsLumNORbXUVLi0beIhyGbLrfB7ps62FWZO+3A/MgZowhBLwUj n/qiBrSpTlWj/iVglL2VT48Q1f9hzsASa5uzeK2b0xR/r1TrCwyec9uPSQ+oF5CnRo/r jsjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c4d3YcnEsWepl47RUEIc/Nk1RRbgO1RkVh7tG+++jdw=; b=Kq85MLfWRjQnN50gylJjV10YjtUV3q4yuL/sPHESJEaBWfBFyKHaYB2u3Xu6mDDEwz 24eqyKdiFnr1v1kvpR7MScRfzFDiGgxTuldp9yhBH4J5Y1ulmNlSn+qXRt6nG42mACWT Hm5gNit6OQgQ4q3BVgvXEyWTiBuP+zL+j3EP+nUPPX23/ATtq0n38Jb0s5ub3Z3ADyns cZZA5pWMzf4kEQNQW1Im94282wBMEh+Rxu9cJ0NJmPlMQFxay6Rlv6XQOdhDofWndY9t WFwiS/VoLugAH32XKC+f7I/3Q6ZJYY9LYMfn8bEtVrG5smHYmQpH7O8O+ITw/DLpidXk eYwQ== X-Gm-Message-State: AE9vXwNBa+J3T/JNvjZx4vIUOrmo0UlCz/XdzZeVc2QXL3G+vynRHqgE8zjR8y2yYTsnWrY2C2ydZU7dNQhH/Q== X-Received: by 10.31.10.21 with SMTP id 21mr953271vkk.29.1473905201738; Wed, 14 Sep 2016 19:06:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Wed, 14 Sep 2016 19:06:41 -0700 (PDT) From: Kathleen Moriarty Date: Wed, 14 Sep 2016 22:06:41 -0400 Message-ID: To: "radext@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [radext] draft-ietf-radext-ip-port-radius-ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 02:06:44 -0000 Hello, I am pushing this draft out to the next telechat as the editors have not been responsive enough to have this move forward on tomorrow's telechat. Please respond to the outstanding discuss and comments as well as the IANA review as there are some noteworthy concerns that absolutely need to be addressed. If responses do not start to come in next week, I'll pull this from the telechat (Sept 29, 2016). Thank you. -- Best regards, Kathleen From nobody Thu Sep 15 05:26:27 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F3712B168; Thu, 15 Sep 2016 05:26:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147394238317.12106.98287185089633062.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2016 05:26:23 -0700 Archived-At: Cc: Tim.Chown@jisc.ac.uk, draft-ietf-radext-ip-port-radius-ext@ietf.org, lionel.morand@orange.com, radext-chairs@ietf.org, radext@ietf.org Subject: [radext] Benoit Claise's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 12:26:23 -0000 Benoit Claise has entered the following ballot position for draft-ietf-radext-ip-port-radius-ext-11: 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-radext-ip-port-radius-ext/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm late for my review here. If some points in my DISCUSS/COMMENT have been discussed already let me know. I'll flag this as a DISCUSS to follow up on the IPFIX issues. First of, I applause the attempt to reuse/map/combine data models (IPFIX information element and RADIUS attribute). Now, there are a couple of issues. The first set of issues has been sent via the IPFIX experts, copied here for tracking purposes. Dear Authors, The experts for the IPFIX IE registry have returned the following review: In general, the Information Elements in draft-ietf-radext-ip-port- radius-ext are so underspecified as to be unimplementable. They should not be added to the registry in their present form. The authors are advised to read RFC 7013, especially Section 4, which provides useful information on defining Information Elements. Specifically: The Information Element transportType is underspecified: (a) I presume this is in reference to sourceTransportPort and destinationTransportPort, but the description must say this if it is the case; (b) It's not clear at all from the description in what context this distinction is useful; (c) What's an ICMP identifier? In addition, the description of transportType appears to create a table which should probably be handled as a subregistry. See See RFC7013 section 4.7. for advice on the creation of tables without subregistries (in short, "don't".) The Information Element natTransportLimit has an inappropriate name; it does not describe that which it (presumably) is supposed to represent (see RFC 7013 section 4.1). In addition, it is underspecified. It is impossible to implement from the description. Is the field IPv4 specific, or is IPv6 supported as well? (If not, why not?) The Information Element localID has an inappropriate name; it is far too general (see RFC 7013 section 4.1). It uses an inappropriate abstract data type (addresses should never be represented as UTF-8 strings in IPFIX, see RFC 7013 section 4.2). It is underspecified as well as poorly designed. Without the ability to disambiguate the type of information in the field, this is not a useful Information Element. Without a complete enumeration of possible types (n.b. 'etc.' in the description), it is not a useful Information Element. Its purpose is unclear from its description; further, it appears to violate the following guidance in RFC 7013 section 4: "The Information Element must be unique within the registry, and its description must represent a substantially different meaning from that of any existing Information Element. An existing Information Element that can be reused for a given purpose should be reused." I have some more issues I would like to discuss: - section 3.2.5, as an example, contains a list of sourceIPv6Address. In IPFIX, we would export those as a list [RFC 6313] Does this RADIUS document want to only reuse the semantic of individual IPFIX information element? And also the semantic of multiple information elements [RFC 6313]? And also the IPFIX encoding? For example, some IPFIX fields are "right justified" (sourceTransportPort), while some others are not (localID) The document should be clear. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 1. IP-Port-Limit-Info: This attribute may be carried in RADIUS Access-Accept, Access-Request, Accounting-Request or CoA-Request packet. The purpose of this attribute is to limit the total number of TCP/UDP ports and/or ICMP identifiers allocated to a user, associated with one or more IPv4 addresses. I see "may be carried". Could it be carried in other packets ... was my first question. It was not clear (until I read the rest of the document) that it's a non compulsory attribute only in Access-Accept, Access-Request, Accounting-Request or CoA-Request packets. Proposal: 1. IP-Port-Limit-Info: The purpose of this attribute is to limit the total number of TCP/UDP ports and/or ICMP identifiers allocated to a user, associated with one or more IPv4 addresses. This attribute is carried in RADIUS Access-Accept, Access-Request, Accounting-Request or CoA-Request packets. Same remark for the other two points below. 2. IP-Port-Range: This attribute may be carried in RADIUS Accounting-Request packet. The purpose of this attribute is to report by an address sharing device (e.g., a CGN) to the RADIUS server the range of TCP/UDP ports and/or ICMP identifiers that have been allocated or deallocated associated with a given IPv4 address for a user. 3. IP-Port-Forwarding-Map: This attribute may be carried in RADIUS Access-Accept, Access-Request, Accounting-Request or CoA-Request packet. The purpose of this attribute is to specify how an IPv4 address and a TCP/ UDP port (or an ICMP identifier) is mapped to another IPv4 address and a TCP/UDP port (or an ICMP identifier). - 1. IP-Port-Limit-Info: This attribute may be carried in RADIUS Access-Accept, Access-Request, Accounting-Request or CoA-Request packet. The purpose of this attribute is to limit the total number of TCP/UDP ports and/or ICMP identifiers allocated to a user, associated with one or more IPv4 addresses. Only for TCP/UDP? I believe Mirja had the same question. - Section 2. Terminology. Typically, you want to have that note at the beginning: Note that the definitions of "internal IP address", "internal port", "internal realm", "external IP address", "external port", "external realm", and "mapping" are the same as defined in Port Control Protocol (PCP) [RFC6887], and the Common Requirements for Carrier- Grade NATs (CGNs) [RFC6888]. If I know of RFC6887 and RFC6888, I don't read the definitions. - Section 3.1.3 This attribute is of type "TLV" as defined in the RADIUS Protocol Extensions [RFC6929]. It contains the following sub-attributes: ... o either an IP-Port-Int-IPv4-Addr TLV (see Section 3.2.4) or an IP- Port-Local-Id TLV (see Section 3.2.11), o either an IP-Port-Int-IPv6-Addr TLV (see Section 3.2.5) or an IP- Port-Local-Id TLV (see Section 3.2.11), Depending on the IP-Port-Type value, it's one of the two above, not both. - I believe the RFC 2119 keywords usage is sometimes weak (generic comment for the entire document) Example1: section 3.1.3 The attribute contains a 2-byte IP internal port number that is associated with an internal IPv4 or IPv6 address, or a locally significant identifier at the customer site, and a 2-byte IP external port number that is associated with an external IPv4 address. The internal IPv4 or IPv6 address, or the local identifier must be included; the external IPv4 address may also be included. Not RFC 2119 keywords. Shoud they be MUST and MAY? And the next paragraph contains RFC 2119 keywords. The IP-Port-Forwarding-Map Attribute MAY appear in an Access-Accept packet. It MAY also appear in an Access-Request packet to indicate a preferred port mapping by the device co-located with NAS. However the server is not required to honor such a preference. Example2: IP-Port-Ext-IPv4-Addr TLV MAY be included in the following Attributes: o IP-Port-Limit-Info Attribute, identified as 241.TBD1.3 (see Section 3.1.1). o IP-Port-Range Attribute, identified as 241.TBD2.3 (see Section 3.1.2). o IP-Port-Forwarding-Mapping Attribute, identified as 241.TBD3.3 (see Section 3.1.3). Don't you need the RFC2119 keyword in the reverse situation, in section 3.1.1 (IP-Port-Limit-Info Attribute)? OLD: o an optional IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3). NEW: o The IP-Port-Limit-Info Attribute MAY contain the IP-Port-Ext-IPv4-Addr (see Section 3.2.3). This logic would not only be clearer, but would also avoid inconsistencies. See section 3.1.3 OLD: It contains the following sub-attributes: ... o an IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3). NEW: It contains the following sub-attributes: ... o an optional IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3). Example 3: natEvent Integer. This field contains the data (unsigned8) of natEvent (230) defined in IPFIX, right justified, and unused bits must be set to zero. It indicates the allocation or deallocation of a range of IP ports as follows: MUST? From nobody Thu Sep 15 10:09:31 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796DA12B380; Thu, 15 Sep 2016 10:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 QV_X5fK3bCUh; Thu, 15 Sep 2016 10:09:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4135612B319; Thu, 15 Sep 2016 09:42:00 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id A0BFC3B4937; Thu, 15 Sep 2016 18:41:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 794A227C07B; Thu, 15 Sep 2016 18:41:58 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0301.000; Thu, 15 Sep 2016 18:41:58 +0200 From: To: "David B. Nelson" Thread-Topic: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHR9/Cwu6n7TFEfE0aWCTw3JOS72qBL68EAgAADpYCAAAXuAIAfD2BwqSufjMbW5EA68A== Date: Thu, 15 Sep 2016 16:41:57 +0000 Message-ID: <32333_1473957718_57DACF56_32333_668_1_6B7134B31289DC4FAF731D844122B36E01FB02AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <147137412687.22998.17081075232946825763.idtracker@ietfa.amsl.com> <17466_1473152611_57CE8663_17466_5602_1_6B7134B31289DC4FAF731D844122B36E01F9ECE4@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1665923093.11596755.1473175346518.JavaMail.zimbra@comcast.net> In-Reply-To: <1665923093.11596755.1473175346518.JavaMail.zimbra@comcast.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , Alissa Cooper , kathleen moriarty ietf , IESG , "radext-chairs@ietf.org" Subject: Re: [radext] Alissa Cooper's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 17:09:24 -0000 SGkgRGF2ZSwNCg0KUGxlYXNlIHNlZSBiZWxvdy4NCg0KUmVnYXJkcywNCg0KTGlvbmVsDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IERhdmlkIEIuIE5lbHNvbiBbbWFp bHRvOmQuYi5uZWxzb25AY29tY2FzdC5uZXRdDQo+IEVudm95w6nCoDogbWFyZGkgNiBzZXB0ZW1i cmUgMjAxNiAxNzoyMg0KPiDDgMKgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCj4gQ2PCoDoga2F0 aGxlZW4gbW9yaWFydHkgaWV0ZjsgQWxpc3NhIENvb3BlcjsgZHJhZnQtaWV0Zi1yYWRleHQtaXAt cG9ydC1yYWRpdXMtDQo+IGV4dEBpZXRmLm9yZzsgcmFkZXh0QGlldGYub3JnOyBJRVNHOyByYWRl eHQtY2hhaXJzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbcmFkZXh0XSBBbGlzc2EgQ29vcGVy J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy0NCj4gZXh0LTEx OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gTGlvbmVsIHdyb3RlOg0KPiANCj4g PiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQsIHdoZW4gZGVmaW5pbmcgYXV0aG9yaXphdGlvbiB0 eXBlIGF0dHJpYnV0ZXMNCj4gPiB0aGF0IGFyZSB1c2Ugb3ZlciBSQURJVVMsIGl0IGlzIG5vdCBk ZWVtZWQgcmVxdWlyZWQgdG8gZGVmaW5lIHRoZQ0KPiA+IHNwZWNpZmljIHVzZSBvZiB0aGVzZSBh dHRyaWJ1dGVzIG5vciB0aGUgZXJyb3IgaGFuZGxpbmcuDQo+IA0KPiBZZXMgYW5kIG5vLiAgV2hp bGUgYXR0cmlidXRlcyBjYW4gYmUgcmUtdXNlZCBpbiBtdWx0aXBsZSBhcHBsaWNhdGlvbnMgYW5k IHVzZQ0KPiBjYXNlcywgdGhlICpzZW1hbnRpY3MqIG9mIHRoZSBhdXRob3JpemF0aW9uIG5lZWRz IHRvIGJlIHVuYW1iaWd1b3VzLg0KPiBSZW1lbWJlciwgUkFESVVTIGRvZXNuJ3QgaGF2ZSB0aGUg bm90aW9uIG9mIGFwcGxpY2F0aW9ucywgc28gdGhlIG1lYW5pbmcgb2YNCj4gYXR0cmlidXRlcyBu ZWVkcyB0byBiZSBpZGVtcG90ZW50LCBpZiBnb29kIGludGVyb3BlcmFiaWxpdHkgdG8gdG8gYmUg YWNoaWV2ZWQuDQoNCltMTV0gSSBhZ3JlZS4gRXNwZWNpYWxseSBvbiB0aGUgc2VtYW50aWMgaXNz dWUuDQoNCj4gDQo+ID4gQXMgZm9yIG90aGVyIEFBQSBkb2N1bWVudHMsIHRoaXMgZHJhZnQgaXMg bm90IHNwZWNpZnlpbmcgYSBzcGVjaWZpYw0KPiA+IHByb2NlZHVyZSBvciBhIG5ldyBwcm90b2Nv bCBhcHBsaWNhdGlvbi4gSXQgaXMganVzdCBhYm91dCBkZWZpbmluZw0KPiA+IGF0dHJpYnV0ZXMg dGhhdCBjYW4gYmUgdXNlZCBpbiB0aGUgdXNlIGNhc2UgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1l bnQNCj4gPiBidXQgYWxzbyBpbiBhbnkgb3RoZXIgc29sdXRpb24gdGhhdCB3b3VsZCBzZWUgYWR2 YW50YWdlIHRvIHJldXNlIHRoZXNlDQo+IGF0dHJpYnV0ZXMuDQo+IA0KPiBZZXMsIGJ1dCBzZWUg YWJvdmUuDQoNCltMTV0gb2suDQoNCj4gDQo+ID4gVGhlIG1haW4gcG9pbnQgb2YgdGhpcyBkb2N1 bWVudCBpcyB0byBlbnN1cmUgdGhhdCB0aGUgZGVmaW5pdGlvbnMgb2YNCj4gPiB0aGVzZSBhdHRy aWJ1dGVzIGFyZSBjb3JyZWN0ICh0eXBlLCBsZW5ndGgsIHZhbHVlKSwgdW5hbWJpZ3VvdXMgYW5k DQo+ID4gZGVzY3JpYmUgaW4gd2hpY2ggbWVzc2FnZXMgdGhleSBjYW4gYXBwZWFyLg0KPiANCj4g VGhlIGRlZmluaXRpb24gb2YgUkFESVVTIGF0dHJpYnV0ZXMgYWxzbyBpbmNsdWRlcyB0aGVpciBz ZW1hbnRpY3MsIG5vdCBqdXN0IHRoZWlyDQo+IHN5bnRheC4NCj4gDQo+ID4gVGhlIGV4YWN0IGJl aGF2aW9yIG9mIHRoZSBjbGllbnQvc2VydmVyIHVzaW5nIHRoZXNlIGF0dHJpYnV0ZXMgaXMNCj4g PiBvZnRlbiBsZWZ0IG91dCBvZiB0aGlzIGtpbmQgb2YgZG9jdW1lbnQuIEl0IGlzIHVwIHRvIHRo ZSBzcGVjaWZpY2F0aW9uDQo+ID4gZGVzY3JpYmluZyB0aGUgaW1wbGVtZW50YXRpb24gdGhlIGNs aWVudHMgYW5kL29yIHNlcnZlcnMgdXNpbmcgdGhlc2UNCj4gPiBhdHRyaWJ1dGVzIHRvIGRlZmlu ZSB0aGlzIGVycm9yIGhhbmRsaW5nLg0KPiANCj4gSSBkaXNhZ3JlZS4gIExlYXZpbmcgb3V0IHNl bWFudGljcyBhbmQgY2xpZW50L3NlcnZlciBiZWhhdmlvciBpcyBub3QgdHJhZGl0aW9uYWwNCj4g Zm9yIFJBRElVUyBhbmQgaXMgbGlrZWx5IHRvIGxlYWQgdG8gcG9vciBpbnRlcm9wZXJhYmlsaXR5 Lg0KDQpbTE1dIEkgdGhpbmsgdGhhdCB0aGVyZSBpcyB3aGF0IGl0IGNvdWxkIGJlIGFuZCB3aGF0 IGl0IGlzLiBBcyBJIHNhaWQsIEkgYWdyZWUgd2l0aCB5b3VyIGNvbW1lbnQgb24gdGhlIGZvcm1h dCBhbmQgdGhlIHNlbWFudGljIG9mIHRoZSBhdHRyaWJ1dGVzLiBCdXQgb24gY2xpZW50L3NlcnZl ciBiZWhhdmlvciBhbmQgZXJyb3IgaGFuZGxpbmcsIHlvdSBjYW4gY2hlY2sgZm9yIGluc3RhbmNl IHdpdGggUkZDNzI2OCBhbmQgUkZDNjkxMSAob3RoZXIgc3RhbmRhcmRzIHRyYWNrIFJGQ3MgZGVm aW5pbmcgUkFESVVTIGF0dHJpYnV0ZXMpIHRoYXQgdGhlc2UgYXNwZWN0cyBhcmUgbm90IGFsd2F5 cyBhZGRyZXNzZWQuIEl0IGRlcGVuZHMgb24gd2hvIGlzIHRoZSByZWFsICJjbGllbnQiIG9mIHRo ZSBzcGVjaWZpY2F0aW9uLiBJbiB0aGUgcHJlc2VudCBjYXNlLCB0aGUgYXR0cmlidXRlcyBhcmUg b25seSB1c2VkIGZvciBjb25maWd1cmF0aW9uIG9yIHJlcG9ydGluZywgbm90IHN0cmljdGx5IHJl bGF0ZWQgdG8gdGhlIGF1dGhvcml6YXRpb24gcHJvY2Vzcy4gICANCk5vdywgaWYgYXV0aG9ycyB3 YW50IHRvIGFkZHJlc3MgdGhlc2UgcG9pbnRzIGluIHRoZSBkcmFmdCwgSSB3aWxsIGJlIGZpbmUu IEJ1dCBJJ20gbm90IGNvbnZpbmNlZCBpdCBpcyByZXF1aXJlZCB0byBiZSBwdWJsaXNoZWQgYXMg UkZDLg0KDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gRGF2ZSBOZWxzb24NCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMK cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn YWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz LgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5r IHlvdS4KCg== From nobody Mon Sep 19 03:11:39 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F3712B292; Mon, 19 Sep 2016 03:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 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=-2.316, SPF_PASS=-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 wP2rhz9PIy5t; Mon, 19 Sep 2016 03:11:28 -0700 (PDT) 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 9F19612B293; Mon, 19 Sep 2016 03:11:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWL15186; Mon, 19 Sep 2016 10:11:22 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 19 Sep 2016 11:11:21 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.53]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0235.001; Mon, 19 Sep 2016 03:11:15 -0700 From: Dean cheng To: Benoit Claise , The IESG Thread-Topic: [radext] Benoit Claise's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHSD0xk4h3y3hpW3UmXsV7mzWiK2qCAkf3w Date: Mon, 19 Sep 2016 10:11:14 +0000 Message-ID: References: <147394238317.12106.98287185089633062.idtracker@ietfa.amsl.com> In-Reply-To: <147394238317.12106.98287185089633062.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.29] Content-Type: multipart/alternative; boundary="_000_DC7880973D477648AC15A3BA66253F686E95DB56SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.57DFB9CB.014A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.53, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f80c05d716ad425d4cdf8aaea8622ad1 Archived-At: Cc: "Tim.Chown@jisc.ac.uk" , "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , "radext-chairs@ietf.org" , "lionel.morand@orange.com" Subject: Re: [radext] Benoit Claise's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 10:11:33 -0000 --_000_DC7880973D477648AC15A3BA66253F686E95DB56SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, Many thanks for your comments. We'll incorporate your proposals and fixes for other comments we have received together into a new revision of this draft at a later time when this round of discussion concludes. We'll need some time requiring consensus among authors but also the WG. Please see below as well. Regards Dean > -----Original Message----- > From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Benoit > Claise > Sent: Thursday, September 15, 2016 5:26 AM > To: The IESG > Cc: Tim.Chown@jisc.ac.uk; draft-ietf-radext-ip-port-radius-ext@ietf.org; > lionel.morand@orange.com; radext-chairs@ietf.org; radext@ietf.org > Subject: [radext] Benoit Claise's Discuss on draft-ietf-radext-ip-port- > radius-ext-11: (with DISCUSS and COMMENT) > > Benoit Claise has entered the following ballot position for > draft-ietf-radext-ip-port-radius-ext-11: 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-radext-ip-port-radius-ext/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm late for my review here. If some points in my DISCUSS/COMMENT have > been discussed already let me know. > > I'll flag this as a DISCUSS to follow up on the IPFIX issues. > First of, I applause the attempt to reuse/map/combine data models > (IPFIX information element and RADIUS attribute). > > Now, there are a couple of issues. > The first set of issues has been sent via the IPFIX experts, copied > here for tracking purposes. > > Dear Authors, > > The experts for the IPFIX IE registry have returned the following > review: > > In general, the Information Elements in draft-ietf-radext-ip-port- > radius-ext are so underspecified as to be unimplementable. They > should > not be added to the registry in their present form. The authors are > advised to read RFC 7013, especially Section 4, which provides > useful > information on defining Information Elements. Specifically: > > The Information Element transportType is underspecified: (a) I > presume > this is in reference to sourceTransportPort and > destinationTransportPort, but the description must say this if it > is > the case; (b) It's not clear at all from the description in what > context this distinction is useful; (c) What's an ICMP identifier? > > In addition, the description of transportType appears to create a > table which should probably be handled as a subregistry. See See > RFC7013 section 4.7. for advice on the creation of tables without > subregistries (in short, "don't".) > > The Information Element natTransportLimit has an inappropriate name; > it does not describe that which it (presumably) is supposed to > represent (see RFC 7013 section 4.1). In addition, it is > underspecified. It is impossible to implement from the description. > Is > the field IPv4 specific, or is IPv6 supported as well? (If not, why > not?) > > The Information Element localID has an inappropriate name; it is > far > too general (see RFC 7013 section 4.1). It uses an inappropriate > abstract data type (addresses should never be represented as UTF-8 > strings in IPFIX, see RFC 7013 section 4.2). It is underspecified > as > well as poorly designed. Without the ability to disambiguate the > type > of information in the field, this is not a useful Information > Element. > Without a complete enumeration of possible types (n.b. 'etc.' in > the > description), it is not a useful Information Element. Its purpose > is > unclear from its description; further, it appears to violate the > following guidance in RFC 7013 section 4: "The Information Element > must be unique within the registry, and its description must > represent > a substantially different meaning from that of any existing > Information Element. An existing Information Element that can be > reused for a given purpose should be reused." In my email on 9/11, we're planning to replace "transportType" (as a proposed new IE) by just a port type and make IP-Port-Type TLV optional. Also, we're planning to remove IP-Port-Local-Id TLV so that "localID" (as a proposed new IE) will not be needed. For the remaining proposed IE, i.e., "natTransportLimit", we'll change the name to "transportLimit" (or something similar) so that this IE can be used for other scenario in addition to NAT case, but also in both IPv4 and IPv6 networking. Text will be added for the explanation. > > I have some more issues I would like to discuss: > - section 3.2.5, as an example, contains a list of sourceIPv6Address. > In IPFIX, we would export those as a list [RFC 6313] Does this RADIUS > document want to only reuse the semantic of individual IPFIX > information element? > And also the semantic of multiple information elements [RFC 6313]? > And also the IPFIX encoding? For example, some IPFIX fields are "right > justified" (sourceTransportPort), while some others are not (localID) > The document should be clear. > In Section 3.2.5, the IP-Port-Int-IPv6-Addr TLV contains a single sourceIPv6Address (not a list), and we intend to reuse the semantics of the original IPFIX definition. This is true also for IP-Port-Int-IPv4-Addr TLV defined in Section 3.2.4, where sourceIPv4Address is also an IPFIX IE. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - > > 1. IP-Port-Limit-Info: This attribute may be carried in RADIUS > Access-Accept, Access-Request, Accounting-Request or CoA-Request > packet. The purpose of this attribute is to limit the total > number of TCP/UDP ports and/or ICMP identifiers allocated to a > user, associated with one or more IPv4 addresses. > > I see "may be carried". Could it be carried in other packets ... was my > first question. > It was not clear (until I read the rest of the document) that it's a > non compulsory attribute only in Access-Accept, Access-Request, > Accounting-Request or CoA-Request packets. > Proposal: > 1. IP-Port-Limit-Info: The purpose of this attribute is to limit > the total > number of TCP/UDP ports and/or ICMP identifiers allocated to a > user, associated with one or more IPv4 addresses. This attribute > is > carried in RADIUS Access-Accept, Access-Request, Accounting- > Request or > CoA-Request packets. Thank you very much for your proposal, and we'll incorporate this into the next revision. > > Same remark for the other two points below. Thank you and we will update the text for the following two in the same fashion as you proposed above. > > 2. IP-Port-Range: This attribute may be carried in RADIUS > Accounting-Request packet. The purpose of this attribute is to > report by an address sharing device (e.g., a CGN) to the RADIUS > server the range of TCP/UDP ports and/or ICMP identifiers that > have been allocated or deallocated associated with a given IPv4 > address for a user. > > 3. IP-Port-Forwarding-Map: This attribute may be carried in RADIUS > Access-Accept, Access-Request, Accounting-Request or CoA-Request > packet. The purpose of this attribute is to specify how an IPv4 > address and a TCP/ UDP port (or an ICMP identifier) is mapped to > another IPv4 address and a TCP/UDP port (or an ICMP identifier). > > - > > 1. IP-Port-Limit-Info: This attribute may be carried in RADIUS > Access-Accept, Access-Request, Accounting-Request or CoA-Request > packet. The purpose of this attribute is to limit the total > number of TCP/UDP ports and/or ICMP identifiers allocated to a > user, associated with one or more IPv4 addresses. > > > Only for TCP/UDP? I believe Mirja had the same question. We're planning to make change to IP-Port-Type TLV as described in my email on 9/11, summarized below: - Make this TLV optionally included in IP-Port-Limit-Info Attribute and IP-Port-Forwarding-Map Attribute - If not included, the port type/number is a "don't care". - The value of this TLV contains an single entry from http://www.i= ana.org/assignments/service-names-port-numbers/service-names-port-numbers.x= html. > > - Section 2. Terminology. > Typically, you want to have that note at the beginning: > > Note that the definitions of "internal IP address", "internal port", > "internal realm", "external IP address", "external port", "external > realm", and "mapping" are the same as defined in Port Control > Protocol (PCP) [RFC6887], and the Common Requirements for Carrier- > Grade NATs (CGNs) [RFC6888]. > > If I know of RFC6887 and RFC6888, I don't read the definitions. OK, we'll remove this paragraph. > > - Section 3.1.3 > > This attribute is of type "TLV" as defined in the RADIUS Protocol > Extensions [RFC6929]. It contains the following sub-attributes: > > ... > > o either an IP-Port-Int-IPv4-Addr TLV (see Section 3.2.4) or an IP- > Port-Local-Id TLV (see Section 3.2.11), > > o either an IP-Port-Int-IPv6-Addr TLV (see Section 3.2.5) or an IP- > Port-Local-Id TLV (see Section 3.2.11), > > Depending on the IP-Port-Type value, it's one of the two above, not > both. This is a good catch - thanks! We will update the text so that only one is included dependindg on IPv4 or IPv6 scenario. > > - I believe the RFC 2119 keywords usage is sometimes weak (generic > comment for the entire document) > Example1: section 3.1.3 > > The attribute contains a 2-byte IP internal port number that is > associated with an internal IPv4 or IPv6 address, or a locally > significant identifier at the customer site, and a 2-byte IP > external > port number that is associated with an external IPv4 address. The > internal IPv4 or IPv6 address, or the local identifier must be > included; the external IPv4 address may also be included. > > Not RFC 2119 keywords. Shoud they be MUST and MAY? > And the next paragraph contains RFC 2119 keywords. > > The IP-Port-Forwarding-Map Attribute MAY appear in an Access-Accept > packet. It MAY also appear in an Access-Request packet to indicate > a > preferred port mapping by the device co-located with NAS. However > the server is not required to honor such a preference. > > Example2: > > IP-Port-Ext-IPv4-Addr TLV MAY be included in the following > Attributes: > > o IP-Port-Limit-Info Attribute, identified as 241.TBD1.3 (see > Section 3.1.1). > > o IP-Port-Range Attribute, identified as 241.TBD2.3 (see > Section 3.1.2). > > o IP-Port-Forwarding-Mapping Attribute, identified as 241.TBD3.3 > (see Section 3.1.3). > > Don't you need the RFC2119 keyword in the reverse situation, in section > 3.1.1 (IP-Port-Limit-Info Attribute)? > OLD: > o an optional IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3). > > NEW: > o The IP-Port-Limit-Info Attribute MAY contain the IP-Port-Ext-IPv4- > Addr (see Section 3.2.3). > > This logic would not only be clearer, but would also avoid > inconsistencies. > See section 3.1.3 > OLD: > > It contains the following sub-attributes: > ... > o an IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3). > > > NEW: > > It contains the following sub-attributes: > > ... > o an optional IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3). > > Example 3: > > natEvent > > Integer. This field contains the data (unsigned8) of natEvent > (230) defined in IPFIX, right justified, and unused bits must be > set to zero. It indicates the allocation or deallocation of a > range of IP ports as follows: > > MUST? Thanks! We'll take your proposal but also apply it to others in the text. > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --_000_DC7880973D477648AC15A3BA66253F686E95DB56SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Benoit,

 

Many thanks for your comments. We'll incorporate<= o:p>

your proposals and fixes for other comments we

have received together into a new revision of

this draft at a later time when this round of

discussion concludes. We'll need some time <= /o:p>

requiring consensus among authors but also the WG= .

 

Please see below as well.

 

Regards

Dean

 

> -----Original Message-----

> From: radext [mailto:radext-bounces@ietf.org= ] On Behalf Of Benoit

> Claise

> Sent: Thursday, September 15, 2016 5:26 AM

> To: The IESG

> Cc: Tim.Chown@jisc.ac.uk; draft-ietf-radext-= ip-port-radius-ext@ietf.org;

> lionel.morand@orange.com; radext-chairs@ietf= .org; radext@ietf.org

> Subject: [radext] Benoit Claise's Discuss on= draft-ietf-radext-ip-port-

> radius-ext-11: (with DISCUSS and COMMENT)

>

> Benoit Claise has entered the following ball= ot position for

> draft-ietf-radext-ip-port-radius-ext-11: Dis= cuss

>

> When responding, please keep the subject lin= e intact and reply to all

> email addresses included in the To and CC li= nes. (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 positi= ons, can be found here:

> https://datatracker.i= etf.org/doc/draft-ietf-radext-ip-port-radius-ext/

>

>

>

> --------------------------------------------= --------------------------

> DISCUSS:

> --------------------------------------------= --------------------------

>

> I'm late for my review here. If some points = in my DISCUSS/COMMENT have

> been discussed already let me know.

>

> I'll flag this as a DISCUSS to follow up on = the IPFIX issues.

> First of, I applause the attempt to reuse/ma= p/combine data models

> (IPFIX information element and RADIUS attrib= ute).

>

> Now, there are a couple of issues.

> The first set of issues has been sent via th= e IPFIX experts, copied

> here for tracking purposes.

>

>     Dear Authors,

>

>     The experts for the = IPFIX IE registry have returned the following

>     review:

>

>     In general, the Info= rmation Elements in draft-ietf-radext-ip-port-

>     radius-ext are so un= derspecified as to be unimplementable. They

> should

>     not be added to the = registry in their present form. The authors are

>     advised to read RFC = 7013, especially Section 4, which provides

> useful

>     information on defin= ing Information Elements. Specifically:

>

>     The Information Elem= ent transportType is underspecified: (a) I

> presume

>     this is in reference= to sourceTransportPort and

>     destinationTransport= Port, but the description must say this if it

> is

>     the case; (b) It's n= ot clear at all from the description in what

>     context this distinc= tion is useful; (c) What's an ICMP identifier?

>

>     In addition, the des= cription of transportType appears to create a

>     table which should p= robably be handled as a subregistry. See See

>     RFC7013 section 4.7.= for advice on the creation of tables without

>     subregistries (in sh= ort, "don't".)

>

>     The Information Elem= ent natTransportLimit has an inappropriate name;

>     it does not describe= that which it (presumably) is supposed to

>     represent (see RFC 7= 013 section 4.1). In addition, it is

>     underspecified. It i= s impossible to implement from the description.

> Is

>     the field IPv4 speci= fic, or is IPv6 supported as well? (If not, why

>     not?)

>

>     The Information Elem= ent localID has an inappropriate name; it is

> far

>     too general (see RFC= 7013 section 4.1). It uses an inappropriate

>     abstract data type (= addresses should never be represented as UTF-8

>     strings in IPFIX, se= e RFC 7013 section 4.2). It is underspecified

> as

>     well as poorly desig= ned. Without the ability to disambiguate the

> type

>     of information in th= e field, this is not a useful Information

> Element.

>     Without a complete e= numeration of possible types (n.b. 'etc.' in

> the

>     description), it is = not a useful Information Element. Its purpose

> is

>     unclear from its des= cription; further, it appears to violate the

>     following guidance i= n RFC 7013 section 4: "The Information Element

>     must be unique withi= n the registry, and its description must

> represent

>     a substantially diff= erent meaning from that of any existing

>     Information Element.= An existing Information Element that can be

>     reused for a given p= urpose should be reused."

 

In my email on 9/11, = we're planning to replace "transportType"

(as a proposed new IE= ) by just a port type and make IP-Port-Type

TLV optional. Also, w= e're planning to remove IP-Port-Local-Id TLV

so that "localID= " (as a proposed new IE) will not be needed.

 

For the remaining pro= posed IE, i.e., "natTransportLimit", we'll

change the name to &q= uot;transportLimit" (or something similar) so that

this IE can be used f= or other scenario in addition to

NAT case, but also in= both IPv4 and IPv6 networking. Text

will be added for the= explanation.

 

>

> I have some more issues I would like to disc= uss:

> - section 3.2.5, as an example, contains a l= ist of sourceIPv6Address.

> In IPFIX, we would export those as a list [R= FC 6313] Does this RADIUS

> document want to only reuse the semantic of = individual IPFIX

> information element?

> And also the semantic of multiple informatio= n elements [RFC 6313]?

> And also the IPFIX encoding? For example, so= me IPFIX fields are "right

> justified" (sourceTransportPort), while= some others are not (localID)

> The document should be clear.

>

In Section 3.2.5, the= IP-Port-Int-IPv6-Addr TLV contains

a single sourceIPv6Ad= dress (not a list), and we intend to

reuse the semantics o= f the original IPFIX definition. This

is true also for IP-P= ort-Int-IPv4-Addr TLV defined in

Section 3.2.4, where = sourceIPv4Address is also an IPFIX IE.

 

>

> --------------------------------------------= --------------------------

> COMMENT:

> --------------------------------------------= --------------------------

>

> -

>

>    1.  IP-Port-Limit-Inf= o: This attribute may be carried in RADIUS

>        Ac= cess-Accept, Access-Request, Accounting-Request or CoA-Request

>        pa= cket.  The purpose of this attribute is to limit the total<= /p>

>        nu= mber of TCP/UDP ports and/or ICMP identifiers allocated to a

>        us= er, associated with one or more IPv4 addresses.

>

> I see "may be carried". Could it b= e carried in other packets ... was my

> first question.

> It was not clear (until I read the rest of t= he document) that it's a

> non compulsory attribute only in Access-Acce= pt, Access-Request,

> Accounting-Request or CoA-Request packets.

> Proposal:

>    1.  IP-Port-Limit-Inf= o: The purpose of this attribute is to limit

> the total

>        nu= mber of TCP/UDP ports and/or ICMP identifiers allocated to a

>        us= er, associated with one or more IPv4 addresses. This attribute

> is

>        ca= rried in RADIUS Access-Accept, Access-Request, Accounting-

> Request or

>        Co= A-Request packets.

 

Thank you very much f= or your proposal, and we'll incorporate this

into the next revisio= n.

 

>

> Same remark for the other two points below.<= o:p>

 

Thank you and we will update the text for the fol= lowing

two in the same fashion as you proposed above.

 

>

>  2.  IP-Port-Range: This attribute= may be carried in RADIUS

>        Ac= counting-Request packet.  The purpose of this attribute is to

>        re= port by an address sharing device (e.g., a CGN) to the RADIUS

>        se= rver the range of TCP/UDP ports and/or ICMP identifiers that

>        ha= ve been allocated or deallocated associated with a given IPv4

>        ad= dress for a user.

>

>    3.  IP-Port-Forwardin= g-Map: This attribute may be carried in RADIUS

>        Ac= cess-Accept, Access-Request, Accounting-Request or CoA-Request

>        pa= cket.  The purpose of this attribute is to specify how an IPv4

>        ad= dress and a TCP/ UDP port (or an ICMP identifier) is mapped to

>        an= other IPv4 address and a TCP/UDP port (or an ICMP identifier).

>

> -

>

>    1.  IP-Port-Limit-Inf= o: This attribute may be carried in RADIUS

>        Ac= cess-Accept, Access-Request, Accounting-Request or CoA-Request

>        pa= cket.  The purpose of this attribute is to limit the total<= /p>

>        nu= mber of TCP/UDP ports and/or ICMP identifiers allocated to a

>        us= er, associated with one or more IPv4 addresses.

>

>

> Only for TCP/UDP? I believe Mirja had the sa= me question.

 

We're planning to mak= e change to IP-Port-Type TLV as described

in my email on 9/11, = summarized below:

 

   - Make t= his TLV optionally included in

   &nb= sp; IP-Port-Limit-Info Attribute and

   &nb= sp; IP-Port-Forwarding-Map Attribute

 

   - If not= included, the port type/number is a "don’t care".

 

   - The va= lue of this TLV contains an single entry from      = ; http://www.iana.org/assignments/service-names-port-numbers/service-names-= port-numbers.xhtml.

 

>

> - Section 2. Terminology.

> Typically, you want to have that note at the= beginning:

>

>    Note that the definitions = of "internal IP address", "internal port",

>    "internal realm"= , "external IP address", "external port", "externa= l

>    realm", and "map= ping" are the same as defined in Port Control

>    Protocol (PCP) [RFC6887], = and the Common Requirements for Carrier-

>    Grade NATs (CGNs) [RFC6888= ].

>

> If I know of RFC6887 and RFC6888, I don't re= ad the definitions.

 

OK, we'll remove this= paragraph.

 

>

> - Section 3.1.3

>

>    This attribute is of type = "TLV" as defined in the RADIUS Protocol

>    Extensions [RFC6929]. = ; It contains the following sub-attributes:

>

>    ...

>

>    o  either an IP-Port-= Int-IPv4-Addr TLV (see Section 3.2.4) or an IP-

>       Port-Loc= al-Id TLV (see Section 3.2.11),

>

>    o  either an IP-Port-= Int-IPv6-Addr TLV (see Section 3.2.5) or an IP-

>       Port-Loc= al-Id TLV (see Section 3.2.11),

>

> Depending on the IP-Port-Type value, it's on= e of the two above, not

> both.

 

This is a good catch = - thanks! We will update the text so that

only one is included = dependindg on IPv4 or IPv6 scenario.

 

>

> - I believe the RFC 2119 keywords usage is s= ometimes weak (generic

> comment for the entire document)<= /p>

> Example1: section 3.1.3

>

>    The attribute contains a 2= -byte IP internal port number that is

>    associated with an interna= l IPv4 or IPv6 address, or a locally

>    significant identifier at = the customer site, and a 2-byte IP

> external

>    port number that is associ= ated with an external IPv4 address.  The

>    internal IPv4 or IPv6 addr= ess, or the local identifier must be

>    included; the external IPv= 4 address may also be included.

>

> Not RFC 2119 keywords. Shoud they be MUST an= d MAY?

> And the next paragraph contains RFC 2119 key= words.

>

>    The IP-Port-Forwarding-Map= Attribute MAY appear in an Access-Accept

>    packet.  It MAY also = appear in an Access-Request packet to indicate

> a

>    preferred port mapping by = the device co-located with NAS.  However

>    the server is not required= to honor such a preference.

>

> Example2:

>

>    IP-Port-Ext-IPv4-Addr TLV = MAY be included in the following

>    Attributes:

>

>    o  IP-Port-Limit-Info= Attribute, identified as 241.TBD1.3 (see

>       Section = 3.1.1).

>

>    o  IP-Port-Range Attr= ibute, identified as 241.TBD2.3 (see

>       Section = 3.1.2).

>

>    o  IP-Port-Forwarding= -Mapping Attribute, identified as 241.TBD3.3

>       (see Sec= tion 3.1.3).

>

> Don't you need the RFC2119 keyword in the re= verse situation, in section

> 3.1.1 (IP-Port-Limit-Info Attribute)?

> OLD:

>    o  an optional IP-Por= t-Ext-IPv4-Addr TLV (see Section 3.2.3).

>

> NEW:

>    o The IP-Port-Limit-Info A= ttribute MAY contain the IP-Port-Ext-IPv4-

> Addr (see Section 3.2.3).

>

> This logic would not only be clearer, but wo= uld also avoid

> inconsistencies.

> See section 3.1.3

> OLD:

>

> It contains the following sub-attributes:

>    ...

>    o  an IP-Port-Ext-IPv= 4-Addr TLV (see Section 3.2.3).

>

>

> NEW:

>

> It contains the following sub-attributes:

>

>   ...

>    o  an optional IP-Por= t-Ext-IPv4-Addr TLV (see Section 3.2.3).

>

> Example 3:

>

>    natEvent

>

>       Integer.=   This field contains the data (unsigned8) of natEvent

>       (230) de= fined in IPFIX, right justified, and unused bits must be

>       set to z= ero.  It indicates the allocation or deallocation of a

>       range of= IP ports as follows:

>

> MUST?

 

Thanks! We'll take your proposal but also apply i= t to

others in the text.

 

>

>

> ____________________________________________= ___

> radext mailing list

> radext@ietf.org

> https://www.ietf.org/= mailman/listinfo/radext

--_000_DC7880973D477648AC15A3BA66253F686E95DB56SJCEML701CHMchi_-- From nobody Wed Sep 21 13:17:15 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81F412BED4; Wed, 21 Sep 2016 13:17:14 -0700 (PDT) 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 iZ7sssDmftbq; Wed, 21 Sep 2016 13:17:12 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 E860012BED3; Wed, 21 Sep 2016 13:17:11 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id g192so73355367ywh.1; Wed, 21 Sep 2016 13:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1sRl9ShhFELqQydQKSq8ss2v86qS9PUVAyTHv6ejypE=; b=SbaDbjhroqJPQZxFTWo6lwUg3KM3RPQnofbc+5pRzIYYUkKD6P1SW49xHspp+nwkzR 3NrfkdT6wuLR9ygLFcxChrGt4RpSF3+oH+B92URaBwTH/UEazmrszEMW53ZNeWY5xf9/ iiaY9w7ke4ppgEO0iNB4DA/PIzzOQLxDLCn0h83+yziJdXF0HsOMN473LRUsaTpbXz+/ gyxlaI3cASwPZ8Pq+Y4C7VkOv2jcPRtmVTk5270aMKayyVonq6tA+LpIanK7IxzWxLpv 02woNzh+5VQoqzrjUea2iHspcXKZg5G9A1yhCv5twu/PxqOuQlw/McDrk3mX/CThHcTd 3PnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1sRl9ShhFELqQydQKSq8ss2v86qS9PUVAyTHv6ejypE=; b=CNCfvwl1KBPcppt7wXkpy3KDIzRzTLcFfltV4bvHPtIN4+CYB6oSn7EOxXS94Qt+/G 72jYC/T22ZLV53sQGSf9mfOlsNV8y0Lyqgocxfiha2D8SbfnUOzGyTSeKxJ8KnDwdg3n 5KoGx5ut2+WH68j44cNUbzCaQKXsmfJr9gqJuRdM/PqTtufg1aLrJYzdkUIKd0Xpesbo NmAg1M8SsHmt8DMtmbp/P3OfmT7UXZLqfWjAxVRUDhnF+Hbg3WhoZiw/SIe47vIvGP3S q6uoJ/pROq1SOm7Iu9SqSMNnij/3Trp1BidllKlcVMjcQvP1HTD9HB7KJSIBPWs7d3DU ARGQ== X-Gm-Message-State: AE9vXwPLVCXRV2N46xO0ccNSO1zWF/+f2RX9UX46lPABma+uzLm9igfPQfT85hb3P16yCpRZlQjdGpw0iHjWOA== X-Received: by 10.129.56.85 with SMTP id f82mr37904622ywa.45.1474489031123; Wed, 21 Sep 2016 13:17:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Wed, 21 Sep 2016 13:17:10 -0700 (PDT) In-Reply-To: References: <147394238317.12106.98287185089633062.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Wed, 21 Sep 2016 16:17:10 -0400 Message-ID: To: Dean cheng , "radext@ietf.org" , "radext-chairs@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Benoit Claise , "Tim.Chown@jisc.ac.uk" , "lionel.morand@orange.com" , The IESG , "draft-ietf-radext-ip-port-radius-ext@ietf.org" Subject: Re: [radext] Benoit Claise's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 20:17:15 -0000 Hello, Since I haven't seen much movement on this draft and the comment below indicates there will be another pass at this draft by the WG, is it safe to pull this off of the next telechat and wait for the WG? If another WGLC is needed to address the expert review, I think that is the right course of action. If not and comments and discusses will be addressed by this Friday, please let me know. Thank you, Kathleen On Mon, Sep 19, 2016 at 6:11 AM, Dean cheng wrote: > Hi Benoit, > > > > Many thanks for your comments. We'll incorporate > > your proposals and fixes for other comments we > > have received together into a new revision of > > this draft at a later time when this round of > > discussion concludes. We'll need some time > > requiring consensus among authors but also the WG. > > > > Please see below as well. > > > > Regards > > Dean > > > >> -----Original Message----- > >> From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Benoit > >> Claise > >> Sent: Thursday, September 15, 2016 5:26 AM > >> To: The IESG > >> Cc: Tim.Chown@jisc.ac.uk; draft-ietf-radext-ip-port-radius-ext@ietf.org; > >> lionel.morand@orange.com; radext-chairs@ietf.org; radext@ietf.org > >> Subject: [radext] Benoit Claise's Discuss on draft-ietf-radext-ip-port- > >> radius-ext-11: (with DISCUSS and COMMENT) > >> > >> Benoit Claise has entered the following ballot position for > >> draft-ietf-radext-ip-port-radius-ext-11: 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-radext-ip-port-radius-ext/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> I'm late for my review here. If some points in my DISCUSS/COMMENT have > >> been discussed already let me know. > >> > >> I'll flag this as a DISCUSS to follow up on the IPFIX issues. > >> First of, I applause the attempt to reuse/map/combine data models > >> (IPFIX information element and RADIUS attribute). > >> > >> Now, there are a couple of issues. > >> The first set of issues has been sent via the IPFIX experts, copied > >> here for tracking purposes. > >> > >> Dear Authors, > >> > >> The experts for the IPFIX IE registry have returned the following > >> review: > >> > >> In general, the Information Elements in draft-ietf-radext-ip-port- > >> radius-ext are so underspecified as to be unimplementable. They > >> should > >> not be added to the registry in their present form. The authors are > >> advised to read RFC 7013, especially Section 4, which provides > >> useful > >> information on defining Information Elements. Specifically: > >> > >> The Information Element transportType is underspecified: (a) I > >> presume > >> this is in reference to sourceTransportPort and > >> destinationTransportPort, but the description must say this if it > >> is > >> the case; (b) It's not clear at all from the description in what > >> context this distinction is useful; (c) What's an ICMP identifier? > >> > >> In addition, the description of transportType appears to create a > >> table which should probably be handled as a subregistry. See See > >> RFC7013 section 4.7. for advice on the creation of tables without > >> subregistries (in short, "don't".) > >> > >> The Information Element natTransportLimit has an inappropriate name; > >> it does not describe that which it (presumably) is supposed to > >> represent (see RFC 7013 section 4.1). In addition, it is > >> underspecified. It is impossible to implement from the description. > >> Is > >> the field IPv4 specific, or is IPv6 supported as well? (If not, why > >> not?) > >> > >> The Information Element localID has an inappropriate name; it is > >> far > >> too general (see RFC 7013 section 4.1). It uses an inappropriate > >> abstract data type (addresses should never be represented as UTF-8 > >> strings in IPFIX, see RFC 7013 section 4.2). It is underspecified > >> as > >> well as poorly designed. Without the ability to disambiguate the > >> type > >> of information in the field, this is not a useful Information > >> Element. > >> Without a complete enumeration of possible types (n.b. 'etc.' in > >> the > >> description), it is not a useful Information Element. Its purpose > >> is > >> unclear from its description; further, it appears to violate the > >> following guidance in RFC 7013 section 4: "The Information Element > >> must be unique within the registry, and its description must > >> represent > >> a substantially different meaning from that of any existing > >> Information Element. An existing Information Element that can be > >> reused for a given purpose should be reused." > > > > In my email on 9/11, we're planning to replace "transportType" > > (as a proposed new IE) by just a port type and make IP-Port-Type > > TLV optional. Also, we're planning to remove IP-Port-Local-Id TLV > > so that "localID" (as a proposed new IE) will not be needed. > > > > For the remaining proposed IE, i.e., "natTransportLimit", we'll > > change the name to "transportLimit" (or something similar) so that > > this IE can be used for other scenario in addition to > > NAT case, but also in both IPv4 and IPv6 networking. Text > > will be added for the explanation. > > > >> > >> I have some more issues I would like to discuss: > >> - section 3.2.5, as an example, contains a list of sourceIPv6Address. > >> In IPFIX, we would export those as a list [RFC 6313] Does this RADIUS > >> document want to only reuse the semantic of individual IPFIX > >> information element? > >> And also the semantic of multiple information elements [RFC 6313]? > >> And also the IPFIX encoding? For example, some IPFIX fields are "right > >> justified" (sourceTransportPort), while some others are not (localID) > >> The document should be clear. > >> > > In Section 3.2.5, the IP-Port-Int-IPv6-Addr TLV contains > > a single sourceIPv6Address (not a list), and we intend to > > reuse the semantics of the original IPFIX definition. This > > is true also for IP-Port-Int-IPv4-Addr TLV defined in > > Section 3.2.4, where sourceIPv4Address is also an IPFIX IE. > > > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> - > >> > >> 1. IP-Port-Limit-Info: This attribute may be carried in RADIUS > >> Access-Accept, Access-Request, Accounting-Request or CoA-Request > >> packet. The purpose of this attribute is to limit the total > >> number of TCP/UDP ports and/or ICMP identifiers allocated to a > >> user, associated with one or more IPv4 addresses. > >> > >> I see "may be carried". Could it be carried in other packets ... was my > >> first question. > >> It was not clear (until I read the rest of the document) that it's a > >> non compulsory attribute only in Access-Accept, Access-Request, > >> Accounting-Request or CoA-Request packets. > >> Proposal: > >> 1. IP-Port-Limit-Info: The purpose of this attribute is to limit > >> the total > >> number of TCP/UDP ports and/or ICMP identifiers allocated to a > >> user, associated with one or more IPv4 addresses. This attribute > >> is > >> carried in RADIUS Access-Accept, Access-Request, Accounting- > >> Request or > >> CoA-Request packets. > > > > Thank you very much for your proposal, and we'll incorporate this > > into the next revision. > > > >> > >> Same remark for the other two points below. > > > > Thank you and we will update the text for the following > > two in the same fashion as you proposed above. > > > >> > >> 2. IP-Port-Range: This attribute may be carried in RADIUS > >> Accounting-Request packet. The purpose of this attribute is to > >> report by an address sharing device (e.g., a CGN) to the RADIUS > >> server the range of TCP/UDP ports and/or ICMP identifiers that > >> have been allocated or deallocated associated with a given IPv4 > >> address for a user. > >> > >> 3. IP-Port-Forwarding-Map: This attribute may be carried in RADIUS > >> Access-Accept, Access-Request, Accounting-Request or CoA-Request > >> packet. The purpose of this attribute is to specify how an IPv4 > >> address and a TCP/ UDP port (or an ICMP identifier) is mapped to > >> another IPv4 address and a TCP/UDP port (or an ICMP identifier). > >> > >> - > >> > >> 1. IP-Port-Limit-Info: This attribute may be carried in RADIUS > >> Access-Accept, Access-Request, Accounting-Request or CoA-Request > >> packet. The purpose of this attribute is to limit the total > >> number of TCP/UDP ports and/or ICMP identifiers allocated to a > >> user, associated with one or more IPv4 addresses. > >> > >> > >> Only for TCP/UDP? I believe Mirja had the same question. > > > > We're planning to make change to IP-Port-Type TLV as described > > in my email on 9/11, summarized below: > > > > - Make this TLV optionally included in > > IP-Port-Limit-Info Attribute and > > IP-Port-Forwarding-Map Attribute > > > > - If not included, the port type/number is a "don=E2=80=99t care". > > > > - The value of this TLV contains an single entry from > http://www.iana.org/assignments/service-names-port-numbers/service-names-= port-numbers.xhtml. > > > >> > >> - Section 2. Terminology. > >> Typically, you want to have that note at the beginning: > >> > >> Note that the definitions of "internal IP address", "internal port", > >> "internal realm", "external IP address", "external port", "external > >> realm", and "mapping" are the same as defined in Port Control > >> Protocol (PCP) [RFC6887], and the Common Requirements for Carrier- > >> Grade NATs (CGNs) [RFC6888]. > >> > >> If I know of RFC6887 and RFC6888, I don't read the definitions. > > > > OK, we'll remove this paragraph. > > > >> > >> - Section 3.1.3 > >> > >> This attribute is of type "TLV" as defined in the RADIUS Protocol > >> Extensions [RFC6929]. It contains the following sub-attributes: > >> > >> ... > >> > >> o either an IP-Port-Int-IPv4-Addr TLV (see Section 3.2.4) or an IP- > >> Port-Local-Id TLV (see Section 3.2.11), > >> > >> o either an IP-Port-Int-IPv6-Addr TLV (see Section 3.2.5) or an IP- > >> Port-Local-Id TLV (see Section 3.2.11), > >> > >> Depending on the IP-Port-Type value, it's one of the two above, not > >> both. > > > > This is a good catch - thanks! We will update the text so that > > only one is included dependindg on IPv4 or IPv6 scenario. > > > >> > >> - I believe the RFC 2119 keywords usage is sometimes weak (generic > >> comment for the entire document) > >> Example1: section 3.1.3 > >> > >> The attribute contains a 2-byte IP internal port number that is > >> associated with an internal IPv4 or IPv6 address, or a locally > >> significant identifier at the customer site, and a 2-byte IP > >> external > >> port number that is associated with an external IPv4 address. The > >> internal IPv4 or IPv6 address, or the local identifier must be > >> included; the external IPv4 address may also be included. > >> > >> Not RFC 2119 keywords. Shoud they be MUST and MAY? > >> And the next paragraph contains RFC 2119 keywords. > >> > >> The IP-Port-Forwarding-Map Attribute MAY appear in an Access-Accept > >> packet. It MAY also appear in an Access-Request packet to indicate > >> a > >> preferred port mapping by the device co-located with NAS. However > >> the server is not required to honor such a preference. > >> > >> Example2: > >> > >> IP-Port-Ext-IPv4-Addr TLV MAY be included in the following > >> Attributes: > >> > >> o IP-Port-Limit-Info Attribute, identified as 241.TBD1.3 (see > >> Section 3.1.1). > >> > >> o IP-Port-Range Attribute, identified as 241.TBD2.3 (see > >> Section 3.1.2). > >> > >> o IP-Port-Forwarding-Mapping Attribute, identified as 241.TBD3.3 > >> (see Section 3.1.3). > >> > >> Don't you need the RFC2119 keyword in the reverse situation, in section > >> 3.1.1 (IP-Port-Limit-Info Attribute)? > >> OLD: > >> o an optional IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3). > >> > >> NEW: > >> o The IP-Port-Limit-Info Attribute MAY contain the IP-Port-Ext-IPv4- > >> Addr (see Section 3.2.3). > >> > >> This logic would not only be clearer, but would also avoid > >> inconsistencies. > >> See section 3.1.3 > >> OLD: > >> > >> It contains the following sub-attributes: > >> ... > >> o an IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3). > >> > >> > >> NEW: > >> > >> It contains the following sub-attributes: > >> > >> ... > >> o an optional IP-Port-Ext-IPv4-Addr TLV (see Section 3.2.3). > >> > >> Example 3: > >> > >> natEvent > >> > >> Integer. This field contains the data (unsigned8) of natEvent > >> (230) defined in IPFIX, right justified, and unused bits must be > >> set to zero. It indicates the allocation or deallocation of a > >> range of IP ports as follows: > >> > >> MUST? > > > > Thanks! We'll take your proposal but also apply it to > > others in the text. > > > >> > >> > >> _______________________________________________ > >> radext mailing list > >> radext@ietf.org > >> https://www.ietf.org/mailman/listinfo/radext --=20 Best regards, Kathleen From nobody Wed Sep 21 23:22:59 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B450812D0EF; Wed, 21 Sep 2016 23:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 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, RP_MATCHES_RCVD=-2.316, 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 bU65ohx1Ak-R; Wed, 21 Sep 2016 23:22:46 -0700 (PDT) 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 52D4312D0B1; Wed, 21 Sep 2016 23:22:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRS02088; Thu, 22 Sep 2016 06:22:39 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 22 Sep 2016 07:22:38 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.53]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0235.001; Wed, 21 Sep 2016 23:22:33 -0700 From: Dean cheng To: Kathleen Moriarty , "radext@ietf.org" , "radext-chairs@ietf.org" Thread-Topic: [radext] Benoit Claise's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) Thread-Index: AQHSD0xk4h3y3hpW3UmXsV7mzWiK2qCAkf3wgARPBgCAADHmcA== Date: Thu, 22 Sep 2016 06:22:30 +0000 Message-ID: References: <147394238317.12106.98287185089633062.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.244] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.57E378B2.008E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.53, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e0db5ba1771b8965b0f2afe6038c8b8c Archived-At: Cc: Benoit Claise , "Tim.Chown@jisc.ac.uk" , "draft-ietf-radext-ip-port-radius-ext@ietf.org" , The IESG , "lionel.morand@orange.com" Subject: Re: [radext] Benoit Claise's Discuss on draft-ietf-radext-ip-port-radius-ext-11: (with DISCUSS and COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 06:22:50 -0000 SGkgS2F0aGxlZW4sDQoNClllcyB3ZSBhdXRob3JzIGFyZSBpbiB0aGUgcHJvY2VzcyB0bw0KdXBk YXRlIHRoZSBkcmFmdCBiYXNlZCBvbiB0aGUgY29tbWVudHMuDQpQZXJzb25hbGx5IEkgdGhpbmsg aXQgaXMgYmV0dGVyIHRvDQp3YWl0IGZvciB0aGUgbmV3IHJldmlzaW9uIGZvciB0aGUNCmZpbmFs IHJldmlldyBhbmQgZGlzY3Vzc2lvbi4NCg0KUmVnYXJkcw0KRGVhbg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJhZGV4dCBbbWFpbHRvOnJhZGV4dC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgS2F0aGxlZW4NCj4gTW9yaWFydHkNCj4gU2VudDogV2VkbmVz ZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTYgMToxNyBQTQ0KPiBUbzogRGVhbiBjaGVuZzsgcmFkZXh0 QGlldGYub3JnOyByYWRleHQtY2hhaXJzQGlldGYub3JnDQo+IENjOiBCZW5vaXQgQ2xhaXNlOyBU aW0uQ2hvd25AamlzYy5hYy51azsgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBUaGUNCj4gSUVT RzsgZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0QGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbcmFkZXh0XSBCZW5vaXQgQ2xhaXNlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJh ZGV4dC1pcC0NCj4gcG9ydC1yYWRpdXMtZXh0LTExOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KQ0KPiANCj4gSGVsbG8sDQo+IA0KPiBTaW5jZSBJIGhhdmVuJ3Qgc2VlbiBtdWNoIG1vdmVtZW50 IG9uIHRoaXMgZHJhZnQgYW5kIHRoZSBjb21tZW50IGJlbG93DQo+IGluZGljYXRlcyB0aGVyZSB3 aWxsIGJlIGFub3RoZXIgcGFzcyBhdCB0aGlzIGRyYWZ0IGJ5IHRoZSBXRywgaXMgaXQNCj4gc2Fm ZSB0byBwdWxsIHRoaXMgb2ZmIG9mIHRoZSBuZXh0IHRlbGVjaGF0IGFuZCB3YWl0IGZvciB0aGUg V0c/ICBJZg0KPiBhbm90aGVyIFdHTEMgaXMgbmVlZGVkIHRvIGFkZHJlc3MgdGhlIGV4cGVydCBy ZXZpZXcsIEkgdGhpbmsgdGhhdCBpcw0KPiB0aGUgcmlnaHQgY291cnNlIG9mIGFjdGlvbi4gIElm IG5vdCBhbmQgY29tbWVudHMgYW5kIGRpc2N1c3NlcyB3aWxsIGJlDQo+IGFkZHJlc3NlZCBieSB0 aGlzIEZyaWRheSwgcGxlYXNlIGxldCBtZSBrbm93Lg0KPiANCj4gVGhhbmsgeW91LA0KPiBLYXRo bGVlbg0KPiANCj4gDQo+IA0KPiBPbiBNb24sIFNlcCAxOSwgMjAxNiBhdCA2OjExIEFNLCBEZWFu IGNoZW5nIDxkZWFuLmNoZW5nQGh1YXdlaS5jb20+DQo+IHdyb3RlOg0KPiA+IEhpIEJlbm9pdCwN Cj4gPg0KPiA+DQo+ID4NCj4gPiBNYW55IHRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gV2UnbGwg aW5jb3Jwb3JhdGUNCj4gPg0KPiA+IHlvdXIgcHJvcG9zYWxzIGFuZCBmaXhlcyBmb3Igb3RoZXIg Y29tbWVudHMgd2UNCj4gPg0KPiA+IGhhdmUgcmVjZWl2ZWQgdG9nZXRoZXIgaW50byBhIG5ldyBy ZXZpc2lvbiBvZg0KPiA+DQo+ID4gdGhpcyBkcmFmdCBhdCBhIGxhdGVyIHRpbWUgd2hlbiB0aGlz IHJvdW5kIG9mDQo+ID4NCj4gPiBkaXNjdXNzaW9uIGNvbmNsdWRlcy4gV2UnbGwgbmVlZCBzb21l IHRpbWUNCj4gPg0KPiA+IHJlcXVpcmluZyBjb25zZW5zdXMgYW1vbmcgYXV0aG9ycyBidXQgYWxz byB0aGUgV0cuDQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxlYXNlIHNlZSBiZWxvdyBhcyB3ZWxsLg0K PiA+DQo+ID4NCj4gPg0KPiA+IFJlZ2FyZHMNCj4gPg0KPiA+IERlYW4NCj4gPg0KPiA+DQo+ID4N Cj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPg0KPiA+PiBGcm9tOiByYWRleHQg W21haWx0bzpyYWRleHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbm9pdA0KPiA+ DQo+ID4+IENsYWlzZQ0KPiA+DQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTUsIDIw MTYgNToyNiBBTQ0KPiA+DQo+ID4+IFRvOiBUaGUgSUVTRw0KPiA+DQo+ID4+IENjOiBUaW0uQ2hv d25AamlzYy5hYy51azsNCj4gPj4gZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0 QGlldGYub3JnOw0KPiA+DQo+ID4+IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTsgcmFkZXh0LWNo YWlyc0BpZXRmLm9yZzsgcmFkZXh0QGlldGYub3JnDQo+ID4NCj4gPj4gU3ViamVjdDogW3JhZGV4 dF0gQmVub2l0IENsYWlzZSdzIERpc2N1c3Mgb24NCj4gPj4gZHJhZnQtaWV0Zi1yYWRleHQtaXAt cG9ydC0NCj4gPg0KPiA+PiByYWRpdXMtZXh0LTExOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KQ0KPiA+DQo+ID4+DQo+ID4NCj4gPj4gQmVub2l0IENsYWlzZSBoYXMgZW50ZXJlZCB0aGUgZm9s bG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPg0KPiA+PiBkcmFmdC1pZXRmLXJhZGV4dC1p cC1wb3J0LXJhZGl1cy1leHQtMTE6IERpc2N1c3MNCj4gPg0KPiA+Pg0KPiA+DQo+ID4+IFdoZW4g cmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5 IHRvDQo+IGFsbA0KPiA+DQo+ID4+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8g YW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dA0KPiA+PiB0aGlzDQo+ID4NCj4gPj4gaW50 cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4NCj4gPj4NCj4gPg0KPiA+Pg0KPiA+ DQo+ID4+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLQ0KPiA+DQo+ID4+IGNyaXRlcmlhLmh0bWwNCj4gPg0KPiA+PiBmb3IgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiA+ DQo+ID4+DQo+ID4NCj4gPj4NCj4gPg0KPiA+PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ID4NCj4gPj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRp dXMtDQo+IGV4dA0KPiA+PiAvDQo+ID4NCj4gPj4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+DQo+ID4N Cj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiA+PiAtDQo+ID4NCj4gPj4gRElTQ1VTUzoNCj4gPg0K PiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiAtDQo+ID4+IC0NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+IEknbSBs YXRlIGZvciBteSByZXZpZXcgaGVyZS4gSWYgc29tZSBwb2ludHMgaW4gbXkgRElTQ1VTUy9DT01N RU5UDQo+ID4+IGhhdmUNCj4gPg0KPiA+PiBiZWVuIGRpc2N1c3NlZCBhbHJlYWR5IGxldCBtZSBr bm93Lg0KPiA+DQo+ID4+DQo+ID4NCj4gPj4gSSdsbCBmbGFnIHRoaXMgYXMgYSBESVNDVVNTIHRv IGZvbGxvdyB1cCBvbiB0aGUgSVBGSVggaXNzdWVzLg0KPiA+DQo+ID4+IEZpcnN0IG9mLCBJIGFw cGxhdXNlIHRoZSBhdHRlbXB0IHRvIHJldXNlL21hcC9jb21iaW5lIGRhdGEgbW9kZWxzDQo+ID4N Cj4gPj4gKElQRklYIGluZm9ybWF0aW9uIGVsZW1lbnQgYW5kIFJBRElVUyBhdHRyaWJ1dGUpLg0K PiA+DQo+ID4+DQo+ID4NCj4gPj4gTm93LCB0aGVyZSBhcmUgYSBjb3VwbGUgb2YgaXNzdWVzLg0K PiA+DQo+ID4+IFRoZSBmaXJzdCBzZXQgb2YgaXNzdWVzIGhhcyBiZWVuIHNlbnQgdmlhIHRoZSBJ UEZJWCBleHBlcnRzLCBjb3BpZWQNCj4gPg0KPiA+PiBoZXJlIGZvciB0cmFja2luZyBwdXJwb3Nl cy4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+ICAgICBEZWFyIEF1dGhvcnMsDQo+ID4NCj4gPj4NCj4g Pg0KPiA+PiAgICAgVGhlIGV4cGVydHMgZm9yIHRoZSBJUEZJWCBJRSByZWdpc3RyeSBoYXZlIHJl dHVybmVkIHRoZQ0KPiBmb2xsb3dpbmcNCj4gPg0KPiA+PiAgICAgcmV2aWV3Og0KPiA+DQo+ID4+ DQo+ID4NCj4gPj4gICAgIEluIGdlbmVyYWwsIHRoZSBJbmZvcm1hdGlvbiBFbGVtZW50cyBpbg0K PiA+PiBkcmFmdC1pZXRmLXJhZGV4dC1pcC1wb3J0LQ0KPiA+DQo+ID4+ICAgICByYWRpdXMtZXh0 IGFyZSBzbyB1bmRlcnNwZWNpZmllZCBhcyB0byBiZSB1bmltcGxlbWVudGFibGUuIFRoZXkNCj4g Pg0KPiA+PiBzaG91bGQNCj4gPg0KPiA+PiAgICAgbm90IGJlIGFkZGVkIHRvIHRoZSByZWdpc3Ry eSBpbiB0aGVpciBwcmVzZW50IGZvcm0uIFRoZSBhdXRob3JzDQo+ID4+IGFyZQ0KPiA+DQo+ID4+ ICAgICBhZHZpc2VkIHRvIHJlYWQgUkZDIDcwMTMsIGVzcGVjaWFsbHkgU2VjdGlvbiA0LCB3aGlj aCBwcm92aWRlcw0KPiA+DQo+ID4+IHVzZWZ1bA0KPiA+DQo+ID4+ICAgICBpbmZvcm1hdGlvbiBv biBkZWZpbmluZyBJbmZvcm1hdGlvbiBFbGVtZW50cy4gU3BlY2lmaWNhbGx5Og0KPiA+DQo+ID4+ DQo+ID4NCj4gPj4gICAgIFRoZSBJbmZvcm1hdGlvbiBFbGVtZW50IHRyYW5zcG9ydFR5cGUgaXMg dW5kZXJzcGVjaWZpZWQ6IChhKSBJDQo+ID4NCj4gPj4gcHJlc3VtZQ0KPiA+DQo+ID4+ICAgICB0 aGlzIGlzIGluIHJlZmVyZW5jZSB0byBzb3VyY2VUcmFuc3BvcnRQb3J0IGFuZA0KPiA+DQo+ID4+ ICAgICBkZXN0aW5hdGlvblRyYW5zcG9ydFBvcnQsIGJ1dCB0aGUgZGVzY3JpcHRpb24gbXVzdCBz YXkgdGhpcyBpZg0KPiBpdA0KPiA+DQo+ID4+IGlzDQo+ID4NCj4gPj4gICAgIHRoZSBjYXNlOyAo YikgSXQncyBub3QgY2xlYXIgYXQgYWxsIGZyb20gdGhlIGRlc2NyaXB0aW9uIGluIHdoYXQNCj4g Pg0KPiA+PiAgICAgY29udGV4dCB0aGlzIGRpc3RpbmN0aW9uIGlzIHVzZWZ1bDsgKGMpIFdoYXQn cyBhbiBJQ01QDQo+IGlkZW50aWZpZXI/DQo+ID4NCj4gPj4NCj4gPg0KPiA+PiAgICAgSW4gYWRk aXRpb24sIHRoZSBkZXNjcmlwdGlvbiBvZiB0cmFuc3BvcnRUeXBlIGFwcGVhcnMgdG8gY3JlYXRl DQo+IGENCj4gPg0KPiA+PiAgICAgdGFibGUgd2hpY2ggc2hvdWxkIHByb2JhYmx5IGJlIGhhbmRs ZWQgYXMgYSBzdWJyZWdpc3RyeS4gU2VlIFNlZQ0KPiA+DQo+ID4+ICAgICBSRkM3MDEzIHNlY3Rp b24gNC43LiBmb3IgYWR2aWNlIG9uIHRoZSBjcmVhdGlvbiBvZiB0YWJsZXMNCj4gd2l0aG91dA0K PiA+DQo+ID4+ICAgICBzdWJyZWdpc3RyaWVzIChpbiBzaG9ydCwgImRvbid0Ii4pDQo+ID4NCj4g Pj4NCj4gPg0KPiA+PiAgICAgVGhlIEluZm9ybWF0aW9uIEVsZW1lbnQgbmF0VHJhbnNwb3J0TGlt aXQgaGFzIGFuIGluYXBwcm9wcmlhdGUNCj4gPj4gbmFtZTsNCj4gPg0KPiA+PiAgICAgaXQgZG9l cyBub3QgZGVzY3JpYmUgdGhhdCB3aGljaCBpdCAocHJlc3VtYWJseSkgaXMgc3VwcG9zZWQgdG8N Cj4gPg0KPiA+PiAgICAgcmVwcmVzZW50IChzZWUgUkZDIDcwMTMgc2VjdGlvbiA0LjEpLiBJbiBh ZGRpdGlvbiwgaXQgaXMNCj4gPg0KPiA+PiAgICAgdW5kZXJzcGVjaWZpZWQuIEl0IGlzIGltcG9z c2libGUgdG8gaW1wbGVtZW50IGZyb20gdGhlDQo+IGRlc2NyaXB0aW9uLg0KPiA+DQo+ID4+IElz DQo+ID4NCj4gPj4gICAgIHRoZSBmaWVsZCBJUHY0IHNwZWNpZmljLCBvciBpcyBJUHY2IHN1cHBv cnRlZCBhcyB3ZWxsPyAoSWYgbm90LA0KPiA+PiB3aHkNCj4gPg0KPiA+PiAgICAgbm90PykNCj4g Pg0KPiA+Pg0KPiA+DQo+ID4+ICAgICBUaGUgSW5mb3JtYXRpb24gRWxlbWVudCBsb2NhbElEIGhh cyBhbiBpbmFwcHJvcHJpYXRlIG5hbWU7IGl0IGlzDQo+ID4NCj4gPj4gZmFyDQo+ID4NCj4gPj4g ICAgIHRvbyBnZW5lcmFsIChzZWUgUkZDIDcwMTMgc2VjdGlvbiA0LjEpLiBJdCB1c2VzIGFuIGlu YXBwcm9wcmlhdGUNCj4gPg0KPiA+PiAgICAgYWJzdHJhY3QgZGF0YSB0eXBlIChhZGRyZXNzZXMg c2hvdWxkIG5ldmVyIGJlIHJlcHJlc2VudGVkIGFzDQo+ID4+IFVURi04DQo+ID4NCj4gPj4gICAg IHN0cmluZ3MgaW4gSVBGSVgsIHNlZSBSRkMgNzAxMyBzZWN0aW9uIDQuMikuIEl0IGlzDQo+IHVu ZGVyc3BlY2lmaWVkDQo+ID4NCj4gPj4gYXMNCj4gPg0KPiA+PiAgICAgd2VsbCBhcyBwb29ybHkg ZGVzaWduZWQuIFdpdGhvdXQgdGhlIGFiaWxpdHkgdG8gZGlzYW1iaWd1YXRlIHRoZQ0KPiA+DQo+ ID4+IHR5cGUNCj4gPg0KPiA+PiAgICAgb2YgaW5mb3JtYXRpb24gaW4gdGhlIGZpZWxkLCB0aGlz IGlzIG5vdCBhIHVzZWZ1bCBJbmZvcm1hdGlvbg0KPiA+DQo+ID4+IEVsZW1lbnQuDQo+ID4NCj4g Pj4gICAgIFdpdGhvdXQgYSBjb21wbGV0ZSBlbnVtZXJhdGlvbiBvZiBwb3NzaWJsZSB0eXBlcyAo bi5iLiAnZXRjLicgaW4NCj4gPg0KPiA+PiB0aGUNCj4gPg0KPiA+PiAgICAgZGVzY3JpcHRpb24p LCBpdCBpcyBub3QgYSB1c2VmdWwgSW5mb3JtYXRpb24gRWxlbWVudC4gSXRzDQo+IHB1cnBvc2UN Cj4gPg0KPiA+PiBpcw0KPiA+DQo+ID4+ICAgICB1bmNsZWFyIGZyb20gaXRzIGRlc2NyaXB0aW9u OyBmdXJ0aGVyLCBpdCBhcHBlYXJzIHRvIHZpb2xhdGUgdGhlDQo+ID4NCj4gPj4gICAgIGZvbGxv d2luZyBndWlkYW5jZSBpbiBSRkMgNzAxMyBzZWN0aW9uIDQ6ICJUaGUgSW5mb3JtYXRpb24NCj4g Pj4gRWxlbWVudA0KPiA+DQo+ID4+ICAgICBtdXN0IGJlIHVuaXF1ZSB3aXRoaW4gdGhlIHJlZ2lz dHJ5LCBhbmQgaXRzIGRlc2NyaXB0aW9uIG11c3QNCj4gPg0KPiA+PiByZXByZXNlbnQNCj4gPg0K PiA+PiAgICAgYSBzdWJzdGFudGlhbGx5IGRpZmZlcmVudCBtZWFuaW5nIGZyb20gdGhhdCBvZiBh bnkgZXhpc3RpbmcNCj4gPg0KPiA+PiAgICAgSW5mb3JtYXRpb24gRWxlbWVudC4gQW4gZXhpc3Rp bmcgSW5mb3JtYXRpb24gRWxlbWVudCB0aGF0IGNhbiBiZQ0KPiA+DQo+ID4+ICAgICByZXVzZWQg Zm9yIGEgZ2l2ZW4gcHVycG9zZSBzaG91bGQgYmUgcmV1c2VkLiINCj4gPg0KPiA+DQo+ID4NCj4g PiBJbiBteSBlbWFpbCBvbiA5LzExLCB3ZSdyZSBwbGFubmluZyB0byByZXBsYWNlICJ0cmFuc3Bv cnRUeXBlIg0KPiA+DQo+ID4gKGFzIGEgcHJvcG9zZWQgbmV3IElFKSBieSBqdXN0IGEgcG9ydCB0 eXBlIGFuZCBtYWtlIElQLVBvcnQtVHlwZQ0KPiA+DQo+ID4gVExWIG9wdGlvbmFsLiBBbHNvLCB3 ZSdyZSBwbGFubmluZyB0byByZW1vdmUgSVAtUG9ydC1Mb2NhbC1JZCBUTFYNCj4gPg0KPiA+IHNv IHRoYXQgImxvY2FsSUQiIChhcyBhIHByb3Bvc2VkIG5ldyBJRSkgd2lsbCBub3QgYmUgbmVlZGVk Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IEZvciB0aGUgcmVtYWluaW5nIHByb3Bvc2VkIElFLCBpLmUu LCAibmF0VHJhbnNwb3J0TGltaXQiLCB3ZSdsbA0KPiA+DQo+ID4gY2hhbmdlIHRoZSBuYW1lIHRv ICJ0cmFuc3BvcnRMaW1pdCIgKG9yIHNvbWV0aGluZyBzaW1pbGFyKSBzbyB0aGF0DQo+ID4NCj4g PiB0aGlzIElFIGNhbiBiZSB1c2VkIGZvciBvdGhlciBzY2VuYXJpbyBpbiBhZGRpdGlvbiB0bw0K PiA+DQo+ID4gTkFUIGNhc2UsIGJ1dCBhbHNvIGluIGJvdGggSVB2NCBhbmQgSVB2NiBuZXR3b3Jr aW5nLiBUZXh0DQo+ID4NCj4gPiB3aWxsIGJlIGFkZGVkIGZvciB0aGUgZXhwbGFuYXRpb24uDQo+ ID4NCj4gPg0KPiA+DQo+ID4+DQo+ID4NCj4gPj4gSSBoYXZlIHNvbWUgbW9yZSBpc3N1ZXMgSSB3 b3VsZCBsaWtlIHRvIGRpc2N1c3M6DQo+ID4NCj4gPj4gLSBzZWN0aW9uIDMuMi41LCBhcyBhbiBl eGFtcGxlLCBjb250YWlucyBhIGxpc3Qgb2Ygc291cmNlSVB2NkFkZHJlc3MuDQo+ID4NCj4gPj4g SW4gSVBGSVgsIHdlIHdvdWxkIGV4cG9ydCB0aG9zZSBhcyBhIGxpc3QgW1JGQyA2MzEzXSBEb2Vz IHRoaXMNCj4gUkFESVVTDQo+ID4NCj4gPj4gZG9jdW1lbnQgd2FudCB0byBvbmx5IHJldXNlIHRo ZSBzZW1hbnRpYyBvZiBpbmRpdmlkdWFsIElQRklYDQo+ID4NCj4gPj4gaW5mb3JtYXRpb24gZWxl bWVudD8NCj4gPg0KPiA+PiBBbmQgYWxzbyB0aGUgc2VtYW50aWMgb2YgbXVsdGlwbGUgaW5mb3Jt YXRpb24gZWxlbWVudHMgW1JGQyA2MzEzXT8NCj4gPg0KPiA+PiBBbmQgYWxzbyB0aGUgSVBGSVgg ZW5jb2Rpbmc/IEZvciBleGFtcGxlLCBzb21lIElQRklYIGZpZWxkcyBhcmUNCj4gPj4gInJpZ2h0 DQo+ID4NCj4gPj4ganVzdGlmaWVkIiAoc291cmNlVHJhbnNwb3J0UG9ydCksIHdoaWxlIHNvbWUg b3RoZXJzIGFyZSBub3QgKGxvY2FsSUQpDQo+ID4NCj4gPj4gVGhlIGRvY3VtZW50IHNob3VsZCBi ZSBjbGVhci4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4gSW4gU2VjdGlvbiAzLjIuNSwgdGhlIElQLVBv cnQtSW50LUlQdjYtQWRkciBUTFYgY29udGFpbnMNCj4gPg0KPiA+IGEgc2luZ2xlIHNvdXJjZUlQ djZBZGRyZXNzIChub3QgYSBsaXN0KSwgYW5kIHdlIGludGVuZCB0bw0KPiA+DQo+ID4gcmV1c2Ug dGhlIHNlbWFudGljcyBvZiB0aGUgb3JpZ2luYWwgSVBGSVggZGVmaW5pdGlvbi4gVGhpcw0KPiA+ DQo+ID4gaXMgdHJ1ZSBhbHNvIGZvciBJUC1Qb3J0LUludC1JUHY0LUFkZHIgVExWIGRlZmluZWQg aW4NCj4gPg0KPiA+IFNlY3Rpb24gMy4yLjQsIHdoZXJlIHNvdXJjZUlQdjRBZGRyZXNzIGlzIGFs c28gYW4gSVBGSVggSUUuDQo+ID4NCj4gPg0KPiA+DQo+ID4+DQo+ID4NCj4gPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gLQ0KPiA+PiAtDQo+ID4NCj4gPj4gQ09NTUVOVDoNCj4gPg0KPiA+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiAtDQo+ID4+IC0NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+IC0NCj4gPg0KPiA+Pg0KPiA+DQo+ ID4+ICAgIDEuICBJUC1Qb3J0LUxpbWl0LUluZm86IFRoaXMgYXR0cmlidXRlIG1heSBiZSBjYXJy aWVkIGluIFJBRElVUw0KPiA+DQo+ID4+ICAgICAgICBBY2Nlc3MtQWNjZXB0LCBBY2Nlc3MtUmVx dWVzdCwgQWNjb3VudGluZy1SZXF1ZXN0IG9yDQo+ID4+IENvQS1SZXF1ZXN0DQo+ID4NCj4gPj4g ICAgICAgIHBhY2tldC4gIFRoZSBwdXJwb3NlIG9mIHRoaXMgYXR0cmlidXRlIGlzIHRvIGxpbWl0 IHRoZSB0b3RhbA0KPiA+DQo+ID4+ICAgICAgICBudW1iZXIgb2YgVENQL1VEUCBwb3J0cyBhbmQv b3IgSUNNUCBpZGVudGlmaWVycyBhbGxvY2F0ZWQgdG8NCj4gYQ0KPiA+DQo+ID4+ICAgICAgICB1 c2VyLCBhc3NvY2lhdGVkIHdpdGggb25lIG9yIG1vcmUgSVB2NCBhZGRyZXNzZXMuDQo+ID4NCj4g Pj4NCj4gPg0KPiA+PiBJIHNlZSAibWF5IGJlIGNhcnJpZWQiLiBDb3VsZCBpdCBiZSBjYXJyaWVk IGluIG90aGVyIHBhY2tldHMgLi4uIHdhcw0KPiA+PiBteQ0KPiA+DQo+ID4+IGZpcnN0IHF1ZXN0 aW9uLg0KPiA+DQo+ID4+IEl0IHdhcyBub3QgY2xlYXIgKHVudGlsIEkgcmVhZCB0aGUgcmVzdCBv ZiB0aGUgZG9jdW1lbnQpIHRoYXQgaXQncyBhDQo+ID4NCj4gPj4gbm9uIGNvbXB1bHNvcnkgYXR0 cmlidXRlIG9ubHkgaW4gQWNjZXNzLUFjY2VwdCwgQWNjZXNzLVJlcXVlc3QsDQo+ID4NCj4gPj4g QWNjb3VudGluZy1SZXF1ZXN0IG9yIENvQS1SZXF1ZXN0IHBhY2tldHMuDQo+ID4NCj4gPj4gUHJv cG9zYWw6DQo+ID4NCj4gPj4gICAgMS4gIElQLVBvcnQtTGltaXQtSW5mbzogVGhlIHB1cnBvc2Ug b2YgdGhpcyBhdHRyaWJ1dGUgaXMgdG8gbGltaXQNCj4gPg0KPiA+PiB0aGUgdG90YWwNCj4gPg0K PiA+PiAgICAgICAgbnVtYmVyIG9mIFRDUC9VRFAgcG9ydHMgYW5kL29yIElDTVAgaWRlbnRpZmll cnMgYWxsb2NhdGVkIHRvDQo+IGENCj4gPg0KPiA+PiAgICAgICAgdXNlciwgYXNzb2NpYXRlZCB3 aXRoIG9uZSBvciBtb3JlIElQdjQgYWRkcmVzc2VzLiBUaGlzDQo+ID4+IGF0dHJpYnV0ZQ0KPiA+ DQo+ID4+IGlzDQo+ID4NCj4gPj4gICAgICAgIGNhcnJpZWQgaW4gUkFESVVTIEFjY2Vzcy1BY2Nl cHQsIEFjY2Vzcy1SZXF1ZXN0LCBBY2NvdW50aW5nLQ0KPiA+DQo+ID4+IFJlcXVlc3Qgb3INCj4g Pg0KPiA+PiAgICAgICAgQ29BLVJlcXVlc3QgcGFja2V0cy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBU aGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHByb3Bvc2FsLCBhbmQgd2UnbGwgaW5jb3Jwb3Jh dGUgdGhpcw0KPiA+DQo+ID4gaW50byB0aGUgbmV4dCByZXZpc2lvbi4NCj4gPg0KPiA+DQo+ID4N Cj4gPj4NCj4gPg0KPiA+PiBTYW1lIHJlbWFyayBmb3IgdGhlIG90aGVyIHR3byBwb2ludHMgYmVs b3cuDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhhbmsgeW91IGFuZCB3ZSB3aWxsIHVwZGF0ZSB0aGUg dGV4dCBmb3IgdGhlIGZvbGxvd2luZw0KPiA+DQo+ID4gdHdvIGluIHRoZSBzYW1lIGZhc2hpb24g YXMgeW91IHByb3Bvc2VkIGFib3ZlLg0KPiA+DQo+ID4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+ICAy LiAgSVAtUG9ydC1SYW5nZTogVGhpcyBhdHRyaWJ1dGUgbWF5IGJlIGNhcnJpZWQgaW4gUkFESVVT DQo+ID4NCj4gPj4gICAgICAgIEFjY291bnRpbmctUmVxdWVzdCBwYWNrZXQuICBUaGUgcHVycG9z ZSBvZiB0aGlzIGF0dHJpYnV0ZSBpcw0KPiA+PiB0bw0KPiA+DQo+ID4+ICAgICAgICByZXBvcnQg YnkgYW4gYWRkcmVzcyBzaGFyaW5nIGRldmljZSAoZS5nLiwgYSBDR04pIHRvIHRoZQ0KPiA+PiBS QURJVVMNCj4gPg0KPiA+PiAgICAgICAgc2VydmVyIHRoZSByYW5nZSBvZiBUQ1AvVURQIHBvcnRz IGFuZC9vciBJQ01QIGlkZW50aWZpZXJzDQo+IHRoYXQNCj4gPg0KPiA+PiAgICAgICAgaGF2ZSBi ZWVuIGFsbG9jYXRlZCBvciBkZWFsbG9jYXRlZCBhc3NvY2lhdGVkIHdpdGggYSBnaXZlbg0KPiA+ PiBJUHY0DQo+ID4NCj4gPj4gICAgICAgIGFkZHJlc3MgZm9yIGEgdXNlci4NCj4gPg0KPiA+Pg0K PiA+DQo+ID4+ICAgIDMuICBJUC1Qb3J0LUZvcndhcmRpbmctTWFwOiBUaGlzIGF0dHJpYnV0ZSBt YXkgYmUgY2FycmllZCBpbg0KPiA+PiBSQURJVVMNCj4gPg0KPiA+PiAgICAgICAgQWNjZXNzLUFj Y2VwdCwgQWNjZXNzLVJlcXVlc3QsIEFjY291bnRpbmctUmVxdWVzdCBvcg0KPiA+PiBDb0EtUmVx dWVzdA0KPiA+DQo+ID4+ICAgICAgICBwYWNrZXQuICBUaGUgcHVycG9zZSBvZiB0aGlzIGF0dHJp YnV0ZSBpcyB0byBzcGVjaWZ5IGhvdyBhbg0KPiA+PiBJUHY0DQo+ID4NCj4gPj4gICAgICAgIGFk ZHJlc3MgYW5kIGEgVENQLyBVRFAgcG9ydCAob3IgYW4gSUNNUCBpZGVudGlmaWVyKSBpcyBtYXBw ZWQNCj4gPj4gdG8NCj4gPg0KPiA+PiAgICAgICAgYW5vdGhlciBJUHY0IGFkZHJlc3MgYW5kIGEg VENQL1VEUCBwb3J0IChvciBhbiBJQ01QDQo+IGlkZW50aWZpZXIpLg0KPiA+DQo+ID4+DQo+ID4N Cj4gPj4gLQ0KPiA+DQo+ID4+DQo+ID4NCj4gPj4gICAgMS4gIElQLVBvcnQtTGltaXQtSW5mbzog VGhpcyBhdHRyaWJ1dGUgbWF5IGJlIGNhcnJpZWQgaW4gUkFESVVTDQo+ID4NCj4gPj4gICAgICAg IEFjY2Vzcy1BY2NlcHQsIEFjY2Vzcy1SZXF1ZXN0LCBBY2NvdW50aW5nLVJlcXVlc3Qgb3INCj4g Pj4gQ29BLVJlcXVlc3QNCj4gPg0KPiA+PiAgICAgICAgcGFja2V0LiAgVGhlIHB1cnBvc2Ugb2Yg dGhpcyBhdHRyaWJ1dGUgaXMgdG8gbGltaXQgdGhlIHRvdGFsDQo+ID4NCj4gPj4gICAgICAgIG51 bWJlciBvZiBUQ1AvVURQIHBvcnRzIGFuZC9vciBJQ01QIGlkZW50aWZpZXJzIGFsbG9jYXRlZCB0 bw0KPiBhDQo+ID4NCj4gPj4gICAgICAgIHVzZXIsIGFzc29jaWF0ZWQgd2l0aCBvbmUgb3IgbW9y ZSBJUHY0IGFkZHJlc3Nlcy4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+DQo+ID4NCj4gPj4gT25seSBm b3IgVENQL1VEUD8gSSBiZWxpZXZlIE1pcmphIGhhZCB0aGUgc2FtZSBxdWVzdGlvbi4NCj4gPg0K PiA+DQo+ID4NCj4gPiBXZSdyZSBwbGFubmluZyB0byBtYWtlIGNoYW5nZSB0byBJUC1Qb3J0LVR5 cGUgVExWIGFzIGRlc2NyaWJlZA0KPiA+DQo+ID4gaW4gbXkgZW1haWwgb24gOS8xMSwgc3VtbWFy aXplZCBiZWxvdzoNCj4gPg0KPiA+DQo+ID4NCj4gPiAgICAtIE1ha2UgdGhpcyBUTFYgb3B0aW9u YWxseSBpbmNsdWRlZCBpbg0KPiA+DQo+ID4gICAgICBJUC1Qb3J0LUxpbWl0LUluZm8gQXR0cmli dXRlIGFuZA0KPiA+DQo+ID4gICAgICBJUC1Qb3J0LUZvcndhcmRpbmctTWFwIEF0dHJpYnV0ZQ0K PiA+DQo+ID4NCj4gPg0KPiA+ICAgIC0gSWYgbm90IGluY2x1ZGVkLCB0aGUgcG9ydCB0eXBlL251 bWJlciBpcyBhICJkb27igJl0IGNhcmUiLg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgIC0gVGhlIHZh bHVlIG9mIHRoaXMgVExWIGNvbnRhaW5zIGFuIHNpbmdsZSBlbnRyeSBmcm9tDQo+ID4gaHR0cDov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9zZXJ2aWNlLW5hbWVzLXBvcnQtbnVtYmVycy9zZXJ2 aWNlLQ0KPiBuYW1lcy1wb3J0LW51bWJlcnMueGh0bWwuDQo+ID4NCj4gPg0KPiA+DQo+ID4+DQo+ ID4NCj4gPj4gLSBTZWN0aW9uIDIuIFRlcm1pbm9sb2d5Lg0KPiA+DQo+ID4+IFR5cGljYWxseSwg eW91IHdhbnQgdG8gaGF2ZSB0aGF0IG5vdGUgYXQgdGhlIGJlZ2lubmluZzoNCj4gPg0KPiA+Pg0K PiA+DQo+ID4+ICAgIE5vdGUgdGhhdCB0aGUgZGVmaW5pdGlvbnMgb2YgImludGVybmFsIElQIGFk ZHJlc3MiLCAiaW50ZXJuYWwNCj4gPj4gcG9ydCIsDQo+ID4NCj4gPj4gICAgImludGVybmFsIHJl YWxtIiwgImV4dGVybmFsIElQIGFkZHJlc3MiLCAiZXh0ZXJuYWwgcG9ydCIsDQo+ID4+ICJleHRl cm5hbA0KPiA+DQo+ID4+ICAgIHJlYWxtIiwgYW5kICJtYXBwaW5nIiBhcmUgdGhlIHNhbWUgYXMg ZGVmaW5lZCBpbiBQb3J0IENvbnRyb2wNCj4gPg0KPiA+PiAgICBQcm90b2NvbCAoUENQKSBbUkZD Njg4N10sIGFuZCB0aGUgQ29tbW9uIFJlcXVpcmVtZW50cyBmb3INCj4gQ2Fycmllci0NCj4gPg0K PiA+PiAgICBHcmFkZSBOQVRzIChDR05zKSBbUkZDNjg4OF0uDQo+ID4NCj4gPj4NCj4gPg0KPiA+ PiBJZiBJIGtub3cgb2YgUkZDNjg4NyBhbmQgUkZDNjg4OCwgSSBkb24ndCByZWFkIHRoZSBkZWZp bml0aW9ucy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBPSywgd2UnbGwgcmVtb3ZlIHRoaXMgcGFyYWdy YXBoLg0KPiA+DQo+ID4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+IC0gU2VjdGlvbiAzLjEuMw0KPiA+ DQo+ID4+DQo+ID4NCj4gPj4gICAgVGhpcyBhdHRyaWJ1dGUgaXMgb2YgdHlwZSAiVExWIiBhcyBk ZWZpbmVkIGluIHRoZSBSQURJVVMgUHJvdG9jb2wNCj4gPg0KPiA+PiAgICBFeHRlbnNpb25zIFtS RkM2OTI5XS4gIEl0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgc3ViLWF0dHJpYnV0ZXM6DQo+ID4N Cj4gPj4NCj4gPg0KPiA+PiAgICAuLi4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+ICAgIG8gIGVpdGhl ciBhbiBJUC1Qb3J0LUludC1JUHY0LUFkZHIgVExWIChzZWUgU2VjdGlvbiAzLjIuNCkgb3IgYW4N Cj4gPj4gSVAtDQo+ID4NCj4gPj4gICAgICAgUG9ydC1Mb2NhbC1JZCBUTFYgKHNlZSBTZWN0aW9u IDMuMi4xMSksDQo+ID4NCj4gPj4NCj4gPg0KPiA+PiAgICBvICBlaXRoZXIgYW4gSVAtUG9ydC1J bnQtSVB2Ni1BZGRyIFRMViAoc2VlIFNlY3Rpb24gMy4yLjUpIG9yIGFuDQo+ID4+IElQLQ0KPiA+ DQo+ID4+ICAgICAgIFBvcnQtTG9jYWwtSWQgVExWIChzZWUgU2VjdGlvbiAzLjIuMTEpLA0KPiA+ DQo+ID4+DQo+ID4NCj4gPj4gRGVwZW5kaW5nIG9uIHRoZSBJUC1Qb3J0LVR5cGUgdmFsdWUsIGl0 J3Mgb25lIG9mIHRoZSB0d28gYWJvdmUsIG5vdA0KPiA+DQo+ID4+IGJvdGguDQo+ID4NCj4gPg0K PiA+DQo+ID4gVGhpcyBpcyBhIGdvb2QgY2F0Y2ggLSB0aGFua3MhIFdlIHdpbGwgdXBkYXRlIHRo ZSB0ZXh0IHNvIHRoYXQNCj4gPg0KPiA+IG9ubHkgb25lIGlzIGluY2x1ZGVkIGRlcGVuZGluZGcg b24gSVB2NCBvciBJUHY2IHNjZW5hcmlvLg0KPiA+DQo+ID4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+ IC0gSSBiZWxpZXZlIHRoZSBSRkMgMjExOSBrZXl3b3JkcyB1c2FnZSBpcyBzb21ldGltZXMgd2Vh ayAoZ2VuZXJpYw0KPiA+DQo+ID4+IGNvbW1lbnQgZm9yIHRoZSBlbnRpcmUgZG9jdW1lbnQpDQo+ ID4NCj4gPj4gRXhhbXBsZTE6IHNlY3Rpb24gMy4xLjMNCj4gPg0KPiA+Pg0KPiA+DQo+ID4+ICAg IFRoZSBhdHRyaWJ1dGUgY29udGFpbnMgYSAyLWJ5dGUgSVAgaW50ZXJuYWwgcG9ydCBudW1iZXIg dGhhdCBpcw0KPiA+DQo+ID4+ICAgIGFzc29jaWF0ZWQgd2l0aCBhbiBpbnRlcm5hbCBJUHY0IG9y IElQdjYgYWRkcmVzcywgb3IgYSBsb2NhbGx5DQo+ID4NCj4gPj4gICAgc2lnbmlmaWNhbnQgaWRl bnRpZmllciBhdCB0aGUgY3VzdG9tZXIgc2l0ZSwgYW5kIGEgMi1ieXRlIElQDQo+ID4NCj4gPj4g ZXh0ZXJuYWwNCj4gPg0KPiA+PiAgICBwb3J0IG51bWJlciB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0 aCBhbiBleHRlcm5hbCBJUHY0IGFkZHJlc3MuDQo+IFRoZQ0KPiA+DQo+ID4+ICAgIGludGVybmFs IElQdjQgb3IgSVB2NiBhZGRyZXNzLCBvciB0aGUgbG9jYWwgaWRlbnRpZmllciBtdXN0IGJlDQo+ ID4NCj4gPj4gICAgaW5jbHVkZWQ7IHRoZSBleHRlcm5hbCBJUHY0IGFkZHJlc3MgbWF5IGFsc28g YmUgaW5jbHVkZWQuDQo+ID4NCj4gPj4NCj4gPg0KPiA+PiBOb3QgUkZDIDIxMTkga2V5d29yZHMu IFNob3VkIHRoZXkgYmUgTVVTVCBhbmQgTUFZPw0KPiA+DQo+ID4+IEFuZCB0aGUgbmV4dCBwYXJh Z3JhcGggY29udGFpbnMgUkZDIDIxMTkga2V5d29yZHMuDQo+ID4NCj4gPj4NCj4gPg0KPiA+PiAg ICBUaGUgSVAtUG9ydC1Gb3J3YXJkaW5nLU1hcCBBdHRyaWJ1dGUgTUFZIGFwcGVhciBpbiBhbg0K PiA+PiBBY2Nlc3MtQWNjZXB0DQo+ID4NCj4gPj4gICAgcGFja2V0LiAgSXQgTUFZIGFsc28gYXBw ZWFyIGluIGFuIEFjY2Vzcy1SZXF1ZXN0IHBhY2tldCB0bw0KPiA+PiBpbmRpY2F0ZQ0KPiA+DQo+ ID4+IGENCj4gPg0KPiA+PiAgICBwcmVmZXJyZWQgcG9ydCBtYXBwaW5nIGJ5IHRoZSBkZXZpY2Ug Y28tbG9jYXRlZCB3aXRoIE5BUy4NCj4gSG93ZXZlcg0KPiA+DQo+ID4+ICAgIHRoZSBzZXJ2ZXIg aXMgbm90IHJlcXVpcmVkIHRvIGhvbm9yIHN1Y2ggYSBwcmVmZXJlbmNlLg0KPiA+DQo+ID4+DQo+ ID4NCj4gPj4gRXhhbXBsZTI6DQo+ID4NCj4gPj4NCj4gPg0KPiA+PiAgICBJUC1Qb3J0LUV4dC1J UHY0LUFkZHIgVExWIE1BWSBiZSBpbmNsdWRlZCBpbiB0aGUgZm9sbG93aW5nDQo+ID4NCj4gPj4g ICAgQXR0cmlidXRlczoNCj4gPg0KPiA+Pg0KPiA+DQo+ID4+ICAgIG8gIElQLVBvcnQtTGltaXQt SW5mbyBBdHRyaWJ1dGUsIGlkZW50aWZpZWQgYXMgMjQxLlRCRDEuMyAoc2VlDQo+ID4NCj4gPj4g ICAgICAgU2VjdGlvbiAzLjEuMSkuDQo+ID4NCj4gPj4NCj4gPg0KPiA+PiAgICBvICBJUC1Qb3J0 LVJhbmdlIEF0dHJpYnV0ZSwgaWRlbnRpZmllZCBhcyAyNDEuVEJEMi4zIChzZWUNCj4gPg0KPiA+ PiAgICAgICBTZWN0aW9uIDMuMS4yKS4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+ICAgIG8gIElQLVBv cnQtRm9yd2FyZGluZy1NYXBwaW5nIEF0dHJpYnV0ZSwgaWRlbnRpZmllZCBhcyAyNDEuVEJEMy4z DQo+ID4NCj4gPj4gICAgICAgKHNlZSBTZWN0aW9uIDMuMS4zKS4NCj4gPg0KPiA+Pg0KPiA+DQo+ ID4+IERvbid0IHlvdSBuZWVkIHRoZSBSRkMyMTE5IGtleXdvcmQgaW4gdGhlIHJldmVyc2Ugc2l0 dWF0aW9uLCBpbg0KPiA+PiBzZWN0aW9uDQo+ID4NCj4gPj4gMy4xLjEgKElQLVBvcnQtTGltaXQt SW5mbyBBdHRyaWJ1dGUpPw0KPiA+DQo+ID4+IE9MRDoNCj4gPg0KPiA+PiAgICBvICBhbiBvcHRp b25hbCBJUC1Qb3J0LUV4dC1JUHY0LUFkZHIgVExWIChzZWUgU2VjdGlvbiAzLjIuMykuDQo+ID4N Cj4gPj4NCj4gPg0KPiA+PiBORVc6DQo+ID4NCj4gPj4gICAgbyBUaGUgSVAtUG9ydC1MaW1pdC1J bmZvIEF0dHJpYnV0ZSBNQVkgY29udGFpbiB0aGUNCj4gPj4gSVAtUG9ydC1FeHQtSVB2NC0NCj4g Pg0KPiA+PiBBZGRyIChzZWUgU2VjdGlvbiAzLjIuMykuDQo+ID4NCj4gPj4NCj4gPg0KPiA+PiBU aGlzIGxvZ2ljIHdvdWxkIG5vdCBvbmx5IGJlIGNsZWFyZXIsIGJ1dCB3b3VsZCBhbHNvIGF2b2lk DQo+ID4NCj4gPj4gaW5jb25zaXN0ZW5jaWVzLg0KPiA+DQo+ID4+IFNlZSBzZWN0aW9uIDMuMS4z DQo+ID4NCj4gPj4gT0xEOg0KPiA+DQo+ID4+DQo+ID4NCj4gPj4gSXQgY29udGFpbnMgdGhlIGZv bGxvd2luZyBzdWItYXR0cmlidXRlczoNCj4gPg0KPiA+PiAgICAuLi4NCj4gPg0KPiA+PiAgICBv ICBhbiBJUC1Qb3J0LUV4dC1JUHY0LUFkZHIgVExWIChzZWUgU2VjdGlvbiAzLjIuMykuDQo+ID4N Cj4gPj4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+IE5FVzoNCj4gPg0KPiA+Pg0KPiA+DQo+ID4+IEl0 IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgc3ViLWF0dHJpYnV0ZXM6DQo+ID4NCj4gPj4NCj4gPg0K PiA+PiAgIC4uLg0KPiA+DQo+ID4+ICAgIG8gIGFuIG9wdGlvbmFsIElQLVBvcnQtRXh0LUlQdjQt QWRkciBUTFYgKHNlZSBTZWN0aW9uIDMuMi4zKS4NCj4gPg0KPiA+Pg0KPiA+DQo+ID4+IEV4YW1w bGUgMzoNCj4gPg0KPiA+Pg0KPiA+DQo+ID4+ICAgIG5hdEV2ZW50DQo+ID4NCj4gPj4NCj4gPg0K PiA+PiAgICAgICBJbnRlZ2VyLiAgVGhpcyBmaWVsZCBjb250YWlucyB0aGUgZGF0YSAodW5zaWdu ZWQ4KSBvZiBuYXRFdmVudA0KPiA+DQo+ID4+ICAgICAgICgyMzApIGRlZmluZWQgaW4gSVBGSVgs IHJpZ2h0IGp1c3RpZmllZCwgYW5kIHVudXNlZCBiaXRzIG11c3QNCj4gPj4gYmUNCj4gPg0KPiA+ PiAgICAgICBzZXQgdG8gemVyby4gIEl0IGluZGljYXRlcyB0aGUgYWxsb2NhdGlvbiBvciBkZWFs bG9jYXRpb24gb2YgYQ0KPiA+DQo+ID4+ICAgICAgIHJhbmdlIG9mIElQIHBvcnRzIGFzIGZvbGxv d3M6DQo+ID4NCj4gPj4NCj4gPg0KPiA+PiBNVVNUPw0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoYW5r cyEgV2UnbGwgdGFrZSB5b3VyIHByb3Bvc2FsIGJ1dCBhbHNvIGFwcGx5IGl0IHRvDQo+ID4NCj4g PiBvdGhlcnMgaW4gdGhlIHRleHQuDQo+ID4NCj4gPg0KPiA+DQo+ID4+DQo+ID4NCj4gPj4NCj4g Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+DQo+ID4+IHJhZGV4dCBtYWlsaW5nIGxpc3QNCj4gPg0KPiA+PiByYWRleHRAaWV0Zi5vcmcN Cj4gPg0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4dA0K PiANCj4gDQo+IA0KPiAtLQ0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBLYXRobGVlbg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcmFkZXh0 IG1haWxpbmcgbGlzdA0KPiByYWRleHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yYWRleHQNCg== From nobody Fri Sep 23 10:13:18 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BED12B2DD; Fri, 23 Sep 2016 10:13:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , "The IESG" , , X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147465079715.372.7512886268710341911.idtracker@ietfa.amsl.com> Date: Fri, 23 Sep 2016 10:13:17 -0700 From: IETF Secretariat Archived-At: Subject: [radext] Telechat update notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 17:13:17 -0000 Removed from agenda for telechat ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ From nobody Wed Sep 28 17:39:06 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB92E12B010; Wed, 28 Sep 2016 17:39:02 -0700 (PDT) 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.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147510954289.16660.2060568887990635936.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 17:39:02 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 00:39:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : RADIUS Extensions for IP Port Configuration and Reporting Authors : Dean Cheng Jouni Korhonen Mohamed Boucadair Senthil Sivakumar Filename : draft-ietf-radext-ip-port-radius-ext-12.txt Pages : 37 Date : 2016-09-28 Abstract: This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports, as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-12 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 Sep 28 17:39:11 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACF412B03D; Wed, 28 Sep 2016 17:39:03 -0700 (PDT) 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.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147510954303.16660.6144323548035499742.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 17:39:03 -0700 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-ip-port-radius-ext-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 00:39:03 -0000 A new version (-12) has been submitted for draft-ietf-radext-ip-port-radius-ext: https://www.ietf.org/internet-drafts/draft-ietf-radext-ip-port-radius-ext-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-12 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. IETF Secretariat. From nobody Wed Sep 28 23:44:51 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1E91288B8; Wed, 28 Sep 2016 23:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 4wmoQhrRuq7J; Wed, 28 Sep 2016 23:44:42 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E68C12B074; Wed, 28 Sep 2016 23:44:42 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 6C7151807A2; Thu, 29 Sep 2016 08:44:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 32C6F1A0059; Thu, 29 Sep 2016 08:44:40 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0301.000; Thu, 29 Sep 2016 08:44:39 +0200 From: To: Mirja Kuehlewind , The IESG Thread-Topic: =?utf-8?B?W3JhZGV4dF0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi1yYWRleHQtaXAtcG9ydC1yYWRpdXMtZXh0LTExOiAod2l0aCBESVND?= =?utf-8?Q?USS)?= Thread-Index: AQHR+JA5d7oiGsb1xEaeq+kXpLH22qCQPerQ Date: Thu, 29 Sep 2016 06:44:39 +0000 Message-ID: References: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> In-Reply-To: <147144264456.12177.17817646214313923394.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-radext-ip-port-radius-ext@ietf.org" , "radext@ietf.org" , "radext-chairs@ietf.org" , MORAND Lionel IMT/OLN Subject: Re: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-radext-ip-port-radius-ext-11=3A_=28with_DISCUSS=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 06:44:44 -0000 RGVhciBNaXJqYSwgDQoNClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IHJhZGV4dCBbbWFpbHRvOnJhZGV4 dC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1pcmphDQo+IEt1ZWhsZXdpbmQNCj4g RW52b3nDqcKgOiBtZXJjcmVkaSAxNyBhb8O7dCAyMDE2IDE2OjA0DQo+IMOAwqA6IFRoZSBJRVNH DQo+IENjwqA6IGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dEBpZXRmLm9yZzsg TU9SQU5EIExpb25lbCBJTVQvT0xOOw0KPiByYWRleHQtY2hhaXJzQGlldGYub3JnOyByYWRleHRA aWV0Zi5vcmcNCj4gT2JqZXTCoDogW3JhZGV4dF0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi1yYWRleHQtaXAtcG9ydC0NCj4gcmFkaXVzLWV4dC0xMTogKHdpdGggRElT Q1VTUykNCj4gDQo+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4 dC0xMTogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNs dWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGlu dHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0 byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0 bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5U IHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFs bG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC8NCj4gDQo+ IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K PiBJIGZ1bGx5IHN1cHBvcnQgQWxpc3NhJ3MgZGlzY3Vzc2lvbiBwb2ludHMgYW5kIGhhdmUgdHdv IG1vcmUgdG8gYWRkOg0KPiANCj4gMSkgSVAtUG9ydC1UeXBlIFRMViBvbmx5IGNvdmVycyBVRFAs IFRDUCBhbmQgSUNNUC4gVGhpcyBpcyBub3QgdmVyeQ0KPiBmdXR1cmUtcHJvb2Y6IHRoZXJlIGFy ZSBvdGhlciB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgaGF2ZSBwb3J0cyBvcg0KPiBpZGVudGlm aWVycyB0aGF0IG1heSB3YW50IHRvIGJlIHN1cHBvcnRlZCBpbiBmdXR1cmUuDQoNCltNZWRdIFRo aXMgaXMgYSBmYWlyIGNvbW1lbnQuIEZXSVcsIG9ubHkgVENQL1VEUC9JQ01QIGFyZSBjb3ZlcmVk IGluaXRpYWxseSBpbiB0aGUgZHJhZnQgYmVjYXVzZSB0aG9zZSBhcmUgY3VycmVudGx5IHRoZSBv bmx5IG9uZXMgc3VwcG9ydGVkIGJ5IHdpZGVseSBkZXBsb3llZCBDR05zLiANCg0KIEFsc28gaXQg aXMgbm90IGNsZWFyDQo+IHRvIG1lIGZyb20gdGhlIGRvY3VtZW50IHdoeSB0aGlzIGluZm9ybWF0 aW9uIGlzIG5lZWRlZCBhdCBhbGwgaW4gdGhlDQo+IGRlc2NyaWJlZCB1c2UgY2FzZXMuDQoNCltN ZWRdIEJlY2F1c2UgcG9ydHMgYXJlIGJvdW5kIHRvIGEgdHJhbnNwb3J0IHByb3RvY29sIChlLmcu LCBvZiB0aGUgcG9ydCBmb3J3YXJkaW5nIGluIFNlY3Rpb24gNC4xLjMpLiBJbiBtb2Rlcm4gTkFU cywgd2hlbiBhbiAoZXhwbGljaXQvaW1wbGljaXQpIG1hcHBpbmcgaXMgY3JlYXRlZCwgYSBwb3J0 IGlzIHJlc2VydmVkIG9ubHkgZm9yIGEgZ2l2ZW4gdHJhbnNwb3J0IHByb3RvY29sIG5vdCBmb3Ig YWxsIHRyYW5zcG9ydCBwcm90b2NvbHMuIA0KDQogVGhlcmVmb3JlIEkgc2VlIHR3byBwb3NzaWJs ZSB3YXlzIGZvcndhcmQ6IEVpdGhlcg0KPiByZW1vdmUgdGhlIElQLVBvcnQtVHlwZSBUTFYgb3Ig ZXh0ZW5kIGl0IHRvIGFsc28gY292ZXIgb3RoZXIgY2FzZXMuDQoNCltNZWRdIFRoZSBuZXcgdmVy c2lvbiBvZiB0aGUgZHJhZnQgZXh0ZW5kcyB0aGUgVExWIHRvIGJlIGFwcGxpY2FibGUgdG8gb3Ro ZXIgdHJhbnNwb3J0IHByb3RvY29scy4gV2UgYXJlIHVzaW5nIHRoZSBJQU5BIHByb3RvY29sIG51 bWJlcnMgKGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcHJvdG9jb2wtbnVtYmVycy9w cm90b2NvbC1udW1iZXJzLnhodG1sKS4gIA0KDQo+IA0KPiBSZWxhdGVkIHRvIHRoaXMgcG9pbnQg SSB3b3VsZCBsaWtlIHRvIG1lbnRpb24gdGhhdCBSRkM2ODg3IGlzIG5vdA0KPiByZXN0cmljdGVk IHRvIFVEUC9UQ1AgYW5kIHRoZXJlZm9yZSB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGluIHNlY3Rp b24gMg0KPiBpcyBub3QgY29ycmVjdDoNCj4gIk5vdGUgdGhhdCB0aGUgZGVmaW5pdGlvbnMgb2Yg Wy4uLl0gImludGVybmFsIHBvcnQiLCBbLi4uXSAiZXh0ZXJuYWwNCj4gcG9ydCIgWy4uLl0gYXJl IHRoZSBzYW1lIGFzIGRlZmluZWQgaW4gUG9ydCBDb250cm9sIFByb3RvY29sIChQQ1ApDQo+IFtS RkM2ODg3XSINCg0KW01lZF0gVGhpcyBpcyBub3QgYW4gaXNzdWUgZ2l2ZW4gdGhhdCB0aGUgbmV3 IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGlzIG5vdCByZXN0cmljdGVkIHRvIFRDUC9VRFAuDQo= From nobody Thu Sep 29 01:24:03 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B742012B08E; Thu, 29 Sep 2016 01:23:52 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABD412B08D; Thu, 29 Sep 2016 01:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ATl4uX1SItqz; Thu, 29 Sep 2016 01:23:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1AB12B0D5; Thu, 29 Sep 2016 01:23:50 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id B29C240CDB; Thu, 29 Sep 2016 10:23:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 7236C1C007A; Thu, 29 Sep 2016 10:23:48 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0301.000; Thu, 29 Sep 2016 10:23:48 +0200 From: To: Carl Wallace , "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" Thread-Topic: secdir review of draft-ietf-radext-ip-port-radius-ext-10 Thread-Index: AQHR9y8WtZ0vGD0hKEW1b5wyWWx0naCQT4TA Date: Thu, 29 Sep 2016 08:23:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E21F9D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160929082352.B742012B08E@ietfa.amsl.com> Resent-Date: Thu, 29 Sep 2016 01:23:52 -0700 (PDT) Archived-At: Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [radext] secdir review of draft-ietf-radext-ip-port-radius-ext-10 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 08:23:53 -0000 RGVhciBDYXJsLCANCg0KKEFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5IHRvIGFuc3dlciB0aGlzIG1l c3NhZ2UpLg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgcmV2aWV3Lg0KDQpQbGVhc2Ug c2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQo+IERlwqA6IENhcmwgV2FsbGFjZSBbbWFpbHRvOmNhcmxAcmVkaG91bmRzb2Z0d2FyZS5j b21dDQo+IEVudm95w6nCoDogbHVuZGkgMTUgYW/Du3QgMjAxNiAyMTo1Ng0KPiDDgMKgOiBkcmFm dC1pZXRmLXJhZGV4dC1pcC1wb3J0LXJhZGl1cy1leHQuYWxsQGlldGYub3JnDQo+IENjwqA6IGll c2dAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZw0KPiBPYmpldMKgOiBzZWNkaXIgcmV2aWV3IG9m IGRyYWZ0LWlldGYtcmFkZXh0LWlwLXBvcnQtcmFkaXVzLWV4dC0xMA0KPiANCj4gSSBoYXZlIHJl dmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUn cw0KPiBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZCBieSB0aGUgSUVTRy4NCj4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1h cmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCj4gZGlyZWN0b3JzLiBE b2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QNCj4gbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiANCj4gVGhpcyBk b2N1bWVudCBkZWZpbmVzIHRocmVlIG5ldyBSQURJVVMgYXR0cmlidXRlcy4gIEZvciBkZXZpY2Vz IHRoYXQNCj4gaW1wbGVtZW50IElQIHBvcnQgcmFuZ2VzLCB0aGVzZSBhdHRyaWJ1dGVzIGFyZSB1 c2VkIHRvIGNvbW11bmljYXRlIHdpdGggYQ0KPiBSQURJVVMgc2VydmVyIGluIG9yZGVyIHRvIGNv bmZpZ3VyZSBhbmQgcmVwb3J0IFRDUC9VRFAgcG9ydHMgYW5kIElDTVANCj4gaWRlbnRpZmllcnMs IGFzIHdlbGwgYXMgbWFwcGluZyBiZWhhdmlvciBmb3Igc3BlY2lmaWMgaG9zdHMuDQo+IA0KPiAN Cj4gSSd2ZSBhIGZldyBxdWVzdGlvbnMvY29tbWVudHM6DQo+IA0KPiAtIFRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIGN1cnJlbnRseSByZWZlcmVuY2VzIHRoZSBzZWN1cml0eQ0K PiBjb25zaWRlcmF0aW9ucyBmcm9tIDI4NjUgYW5kIDUxNzYuICBTaG91bGQgNjg4NyBiZSBpbmNs dWRlZCB0byBhZGRyZXNzDQo+IGNvbnNpZGVyYXRpb25zIHJlbGF0ZWQgdG8gdGhlIGZvcndhcmRp bmcgYXR0cmlidXRlPw0KDQpbTWVkXSBSZWZlcnJpbmcgdG8gdGhlIFBDUCBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBtYXkgbm90IGJlIGp1c3RpZmllZCBoZXJlIGdpdmVuIHRoYXQgdGhlIFJBRElV UyBjbGllbnQgYW5kIHNlcnZlciBhcmUgaW4gdGhlIHNhbWUgdHJ1c3QgZG9tYWluLiBXZSBoYXZl IHRoaXMgdGV4dCBpbiB0aGUgZHJhZnQgZm9yIHRoaXMgcG9pbnQ6DQoNCiAgIFRoaXMgZG9jdW1l bnQgdGFyZ2V0cyBkZXBsb3llZCB3aGVyZSBhIHRydXN0ZWQgcmVsYXRpb25zaGlwIGlzIGluDQog ICBwbGFjZSBiZXR3ZWVuIHRoZSBSQURJVVMgY2xpZW50IGFuZCBzZXJ2ZXIgd2l0aCBjb21tdW5p Y2F0aW9uDQogICBvcHRpb25hbGx5IHNlY3VyZWQgYnkgSVBzZWMgb3IgVHJhbnNwb3J0IExheWVy IFNlY3VyaXR5IChUTFMpDQogICBbUkZDNjYxNF0uDQoNCj4gLSBXaGVuIHRoZSBwb3J0IGxpbWl0 IGF0dHJpYnV0ZSBpcyB1c2VkLCBkb2VzIHByZXNlbnRhdGlvbiBvZiBhIG5ldw0KPiAiZ2xvYmFs IiBzZXR0aW5nIHVuZG8gcHJldmlvdXNseSBlc3RhYmxpc2hlZCBJUCBzcGVjaWZpYyBzZXR0aW5n cyAob3IgdmljZQ0KPiB2ZXJzYSk/DQoNCltNZWRdIEknbSBub3Qgc3VyZSB0byB1bmRlcnN0YW5k IHRoZSBxdWVzdGlvbiBoZXJlLiBCdXQsIA0KKiBpZiB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB0 aGUgbmV3IGxpbWl0IHJlcGxhY2VzIHRoZSBvbmUsIHRoZSBhbnN3ZXIgaXMgeWVzLiANCiogaWYg dGhlIHF1ZXN0aW9uIGlzIGhvdyB0aGUgbmV3IGxpbWl0IGlzIGFwcGxpZWQgaWYgYWxpdmUgc2Vz c2lvbnMgZm9yIGEgZ2l2ZW4gc3Vic2NyaWJlciBleGNlZWQgdGhlIG5ldyBsaW1pdCwgdGhlIGFu c3dlciBpcyB0aGlzIGlzIGltcGxlbWVudGF0aW9uLXNwZWNpZmljLiBBIENHTiBoYXMgdG8gZGVh bCB3aXRoIHRoYXQgYW55IHdheSAoc2VlIHRoaXMgUkVRIGZyb20gUkZDNjg4OCkuIFdlIGRlZmVy IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBiZWhhdmlvci4gDQoNCj09PQ0KDQogICBSRVEtNDogIEEg Q0dOIE1VU1Qgc3VwcG9ydCBsaW1pdGluZyB0aGUgbnVtYmVyIG9mIGV4dGVybmFsIHBvcnRzIChv ciwNCiAgICAgIGVxdWl2YWxlbnRseSwgImlkZW50aWZpZXJzIiBmb3IgSUNNUCkgdGhhdCBhcmUg YXNzaWduZWQgcGVyDQogICAgICBzdWJzY3JpYmVyLg0KDQogICAgICBhLiAgUGVyLXN1YnNjcmli ZXIgbGltaXRzIE1VU1QgYmUgY29uZmlndXJhYmxlIGJ5IHRoZSBDR04NCiAgICAgICAgICBhZG1p bmlzdHJhdG9yLg0KDQogICAgICBiLiAgUGVyLXN1YnNjcmliZXIgbGltaXRzIE1BWSBiZSBjb25m aWd1cmFibGUgaW5kZXBlbmRlbnRseSBwZXINCiAgICAgICAgICB0cmFuc3BvcnQgcHJvdG9jb2wu DQoNCiAgICAgIGMuICBBZGRpdGlvbmFsbHksIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIENH TiBpbmNsdWRlDQogICAgICAgICAgYWRtaW5pc3RyYXRvci1hZGp1c3RhYmxlIHRocmVzaG9sZHMg dG8gcHJldmVudCBhIHNpbmdsZQ0KICAgICAgICAgIHN1YnNjcmliZXIgZnJvbSBjb25zdW1pbmcg ZXhjZXNzaXZlIENQVSByZXNvdXJjZXMgZnJvbSB0aGUgQ0dODQogICAgICAgICAgKGUuZy4sIHJh dGUtbGltaXQgdGhlIHN1YnNjcmliZXIncyBjcmVhdGlvbiBvZiBuZXcgbWFwcGluZ3MpLg0KDQog ICBKdXN0aWZpY2F0aW9uOiAgQSBDR04gY2FuIGJlIGNvbnNpZGVyZWQgYSBuZXR3b3JrIHJlc291 cmNlIHRoYXQgaXMNCiAgICAgIHNoYXJlZCBieSBjb21wZXRpbmcgc3Vic2NyaWJlcnMuICBMaW1p dGluZyB0aGUgbnVtYmVyIG9mIGV4dGVybmFsDQogICAgICBwb3J0cyBhc3NpZ25lZCB0byBlYWNo IHN1YnNjcmliZXIgbWl0aWdhdGVzIHRoZSBkZW5pYWwtb2Ytc2VydmljZQ0KICAgICAgKERvUykg YXR0YWNrIHRoYXQgYSBzdWJzY3JpYmVyIGNvdWxkIGxhdW5jaCBhZ2FpbnN0IG90aGVyDQogICAg ICBzdWJzY3JpYmVycyB0aHJvdWdoIHRoZSBDR04gaW4gb3JkZXIgdG8gZ2V0IGEgbGFyZ2VyIHNo YXJlIG9mIHRoZQ0KICAgICAgcmVzb3VyY2UuICBJdCBlbnN1cmVzIGZhaXJuZXNzIGFtb25nIHN1 YnNjcmliZXJzLiAgTGltaXRpbmcgdGhlDQogICAgICByYXRlIG9mIGFsbG9jYXRpb24gbWl0aWdh dGVzIGEgc2ltaWxhciBhdHRhY2sgd2hlcmUgdGhlIENQVSBpcyB0aGUNCiAgICAgIHJlc291cmNl IGJlaW5nIHRhcmdldGVkIGluc3RlYWQgb2YgcG9ydCBudW1iZXJzLiAgSG93ZXZlciwgdGhpcw0K ICAgICAgcmVxdWlyZW1lbnQgaXMgbm90IGEgTVVTVCBiZWNhdXNlIGl0IGlzIHZlcnkgaGFyZCB0 byBleHBsaWNpdGx5DQogICAgICBjYWxsIG91dCBhbGwgQ1BVLWNvbnN1bWluZyBldmVudHMuDQo9 PQ0KDQo+IC0gU2hvdWxkIHRoZSBJUC1Qb3J0LVJhbmdlIGF0dHJpYnV0ZSByZXF1aXJlIGF0IGxl YXN0IG9uZSBvZg0KPiBJUC1Qb3J0LUV4dC1JUHY0LUFkZHIgb3IgSVAtUG9ydC1Mb2NhbC1JZCB0 byBiZSBwcmVzZW50Pw0KDQpbTWVkXSBOby4gVGhpcyBpcyBkZXBsb3ltZW50IHNwZWNpZmljLiBG b3IgZXhhbXBsZSwgYSBDUEUgdGhhdCByZXBvcnRzIHRoZSBhbGxvY2F0aW9uIG9mIGEgcG9ydCBy YW5nZSB0byBhIHZpc2l0aW5nIGhvc3QgaXMgbm90IHJlcXVpcmVkIHRvIGluY2x1ZGUgdGhlIGV4 dGVybmFsIElQIGFkZHJlc3MgZ2l2ZW4gdGhpcyBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IGtub3du IHRvIHRoZSBSQURJVVMgc2VydmVyIChlLmcuLCBGaWd1cmUgMjApLiBCdXQgYSBEUy1MaXRlIEFG VFIgdGhhdCBhbGxvY2F0ZXMgYSBwb3J0IHJhbmdlIG1heSBzZW5kIGEgbm90aWZpY2F0aW9uIG1l c3NhZ2UgdG8gaW5mb3JtIHRoZSBSQURJVVMgc2VydmVyIGFib3V0IGEgbmV3IGFsbG9jYXRlZCBw b3J0IHJhbmdlLCB0aGlzIG1lc3NhZ2Ugd2lsbCBpbmNsdWRlIHRoZSBleHRlcm5hbCBJUHY0IGFk ZHJlc3MgKElQLVBvcnQtRXh0LUlQdjQtQWRkcikgYW5kIHRoZSBzb2Z0d2lyZSBJUHY2IGFkZHJl c3MgKElQLVBvcnQtTG9jYWwtSWQpDQoNCiBIb3cgaXMgdGhlDQo+IGF0dHJpYnV0ZSB1c2VkIHdo ZW4gYm90aCBhcmUgYWJzZW50Pw0KDQpbTWVkXSBUaGUgdGV4dCBzYXlzIHRoZSBmb2xsb3dpbmc6 IA0KDQogICBJZiB0aGUgSVAtUG9ydC1FeHQtSVB2NC1BZGRyIFRMViBpcyBpbmNsdWRlZCBhcyBw YXJ0IG9mIHRoZSBJUC1Qb3J0LQ0KICAgUmFuZ2UgQXR0cmlidXRlLCB0aGUgcG9ydCByYW5nZSBh cyBzcGVjaWZpZWQgaXMgYXNzb2NpYXRlZCB3aXRoIElQdjQNCiAgIGFkZHJlc3MgYXMgaW5kaWNh dGVkLCBidXQgb3RoZXJ3aXNlIGlzIGZvciBhbGwgSVB2NCBhZGRyZXNzZXMgYnkgdGhlDQogICAg ICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXg0KICAgcG9ydCBkZXZpY2UgKGUuZy4sIGEgQ0dOIGRldmljZSkgZm9yIHRoZSBl bmQgdXNlci4NCiAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eDQoNCk5vIG5lZWQgdG8gaGF2ZSBleHBsaWNpdCB0ZXh0IGFib3V0IHRoZSBhYnNlbmNl IG9mIElQLVBvcnQtTG9jYWwtSWQgYXMgd2UgdGhvdWdodCB0aGlzIG9idmlvdXNseSBtZWFucyBu byBleHRyYSBpZGVudGlmaWVyIGlzIHJlcXVpcmVkLg0KDQo+IC0gVGhlIHN1bW1hcnkgc3RhdGVt ZW50IGFzc29jaWF0ZWQgd2l0aCB0aGUgYXR0cmlidXRlcyBpbiBzZWN0aW9uIDEgbWlnaHQNCj4g YmVuZWZpdCBmcm9tIGluZGljYXRpbmcgdGhlIHB1cnBvc2Ugb2YgdGhlIGF0dHJpYnV0ZSByZWxh dGl2ZSB0byBlYWNoDQo+IHBhY2tldCB0eXBlIGluIHdoaWNoIGl0IG1heSBhcHBlYXIgKGZvciBl eGFtcGxlLCB0aGUgcHVycG9zZSBvZiBhIHBvcnQNCj4gbGltaXQgaW5mbyBhdHRyaWJ1dGUgaXMg ZGlmZmVyZW50IHdoZW4gaW5jbHVkZWQgaW4gYW4gQWNjZXNzLVJlcXVlc3QgdGhhbg0KPiBpbiBh biBBY2Nlc3MtUmVzcG9uc2UpLg0KDQpbTWVkXSBJTUhPIHRoaXMgaXMgcmVkdW5kYW50IHdpdGgg dGhlIGNvbnRlbnQgb2YgU2VjdGlvbiA1LiANCg0KPiAtIEVhY2ggYXR0cmlidXRlIGxpc3RzIGFw cGxpY2FibGUgcGFja2V0IHR5cGVzIGFuZCBpbmRpY2F0ZXMgdGhlIGF0dHJpYnV0ZQ0KPiBtdXN0 IG5vdCBhcHBlYXIgaW4gYW55IG90aGVyIHBhY2tldCB0eXBlLiBJdCBtYXkgYmUgd29ydGggYWRk aW5nIGEgbm90ZSB0bw0KPiBjbGFyaWZ5IHdoYXQgc2hvdWxkIGhhcHBlbiBpZiB0aGUgYXR0cmli dXRlIGRvZXMgYXBwZWFyIChhc3N1bWluZyBpZ25vcmUpLg0KDQpbTWVkXSBUaGlzIGlzIGNvdmVy ZWQgaW4gU2VjdGlvbiA1LiANCg0KPiAtIFRoZSBVRSBhY3JvbnltIG9uIHBhZ2UgMzAgc2hvdWxk IGJlIGV4cGFuZGVkLg0KDQpbTWVkXSBXaWxsIGJlIGZpeGVkLg0KDQo+IC0gSW4gMy4xLjIsIGNo YW5nZSAiYXJlIHByZXZpb3VzbHkgYWxsb2NhdGVkIiB0byAid2VyZSBwcmV2aW91c2x5DQo+IGFs bG9jYXRlZCIuDQoNCltNZWRdIFdpbGwgYmUgZml4ZWQuIFRoYW5rIHlvdSBmb3IgY2F0Y2hpbmcg dGhpcy4NCg0KPiAtIEluIDQuMS4zLCBpcyAiUkFESVVTIGFzc29jaWF0ZSIgYSBjb21tb25seSB1 c2VkIHRlcm0/IFRoaXMgc2VlbXMgbGlrZSBhDQo+IHJlcXVpcmVtZW50IG9uIHVzZSB3aXRoIENv QS1SZXF1ZXN0cyB0aGF0IHNob3VsZCBiZSBtZW50aW9uZWQgZWFybGllci4NCj4gDQoNCltNZWRd IFdpbGwgYmUgY2hhbmdlZCB0byAiUkFESVVTIGFzc29jaWF0aW9uIi4NCg0K From nobody Thu Sep 29 05:17:31 2016 Return-Path: X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1EDA212B0E4; Thu, 29 Sep 2016 05:17:27 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BB512B42E; Thu, 29 Sep 2016 05:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.915 X-Spam-Level: X-Spam-Status: No, score=-4.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 EdmqDcEK54Of; Thu, 29 Sep 2016 05:17:22 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5361612B0E4; Thu, 29 Sep 2016 05:17:18 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id C6DB1204E6; Thu, 29 Sep 2016 14:17:16 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 7D66B1C006C; Thu, 29 Sep 2016 14:17:16 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0301.000; Thu, 29 Sep 2016 14:17:16 +0200 From: To: Tim Chown , "ops-dir@ietf.org" , "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 Thread-Index: AQHR+HEowS7Op1qTZUSXToLnElhR2aCQe3Bg Date: Thu, 29 Sep 2016 12:17:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E220CD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008E220CDOPEXCLILMA3corp_" MIME-Version: 1.0 Resent-From: Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org Resent-Message-Id: <20160929121727.1EDA212B0E4@ietfa.amsl.com> Resent-Date: Thu, 29 Sep 2016 05:17:27 -0700 (PDT) Archived-At: Cc: Kathleen Moriarty Subject: Re: [radext] OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 12:17:27 -0000 --_000_787AE7BB302AE849A7480A190F8B933008E220CDOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tim, (Apologies for the delay to answer the message) Thank you for the review. Please see inline. Cheers, Med De : Tim Chown [mailto:Tim.Chown@jisc.ac.uk] Envoy=E9 : mercredi 17 ao=FBt 2016 12:23 =C0 : ops-dir@ietf.org; draft-ietf-radext-ip-port-radius-ext.all@ietf.org Objet : OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. T= hese comments were written with the intent of improving the operational aspects = of the IETF drafts. Comments that are not addressed in last call may be included i= n AD reviews during the IESG review. Document editors and WG chairs should treat these = comments just like any other last call comments. This draft defines three new RADIUS attributes to be used when communicatin= g with a RADIUS server to facilitate the configuration or reporting of IP and port r= anges used with a network appliance, typically a CGN, where there is a need to constra= in the ports available per customer where IP address sharing is in use. The three RADIUS attributes are: IP-Port-Limit-Info - defines the maximum number of ports available IP-Port-Range - the specific range of port numbers available IP-Port-Forwarding-Map - to configure port forwarding on a NAT/CGN device I would consider the document to be "Ready with Issues". I have some general comments, followed by some specific comments. Note that= while I am familiar with RADIUS (from an eduroam context) the draft is not one I wa= s familiar with or followed prior to this review. Thus these comments may hav= e already been addressed. General comments: There are at least two areas in which this document has "creep". One is tha= t it is providing an alternative method to PCP to define port forwarding mappings o= n a device. So there is an open question as to whether PCP should be the method of choi= ce for this function, or whether we wish to create a new way to establish such map= pings. [Med] PCP targets a different deployment model where an application control= s its mapping in a CPE, CGN, Firewall, etc. This document targets a deploym= ent where a AAA server is responsible de instructing NAT mappings for a giv= en subscriber. Secondly, two of the new attributes support inclusion of a new TLV, IP-Port= -Local-Id, which allows user/device-specific information to be transmitted via RADIUS,= such as MAC address or VLAN ID. While this is intended to allow differentiation of = users for accounting/identification r, in doing so it adds an additional potential pr= ivacy concern into a new RADIUS attribute, depending on specific use cases of the= TLV. [Med] The main use case is the deployment where the internal IP address is = not sufficient to demux users. We introduced this NEW text in -12: The primary issue addressed by this TLV is that there are CGN deployments that do not distinguish internal hosts by their internal IP address alone, but use further identifiers for unique subscriber identification. For example, this is the case if a CGN supports overlapping private or shared IP address spaces (refer to [RFC1918] and [RFC6598]) for internal hosts o= f different subscribers. In such cases, different internal hosts are identified and mapped at the CGN by their IP address and/or another identifier, for example, the identifier of a tunnel between the CGN and the subscriber. In these scenarios (and similar ones), the internal IP address is not sufficient to demultiplex connections from internal hosts. An additional identifier needs to be present in the IP-Port-Range Attribute and IP-Port-Forwarding-Mapping Attribute in order to uniquely identify an internal host. The IP-Port-Local-Id TLV is used to carry this identifier. This is not discussed in the Security Considerations section, but probably = should be. [Med] Fair point. We added this text: The IP-Port-Local-Id TLV includes an identifier of which the type and length is deployment and implementation dependent. This identifier might carry privacy sensitive information. It is therefore RECOMMENDED to utilize identifiers that do not have such privacy concerns. I note the new attributes use a number of IPFIX information elements; has t= he draft considered its relationship to draft-ietf-behave-ipfix-nat-logging-09, whic= h says the "lack of a consistent way to log the data makes it difficult to write t= he collector applications that would receive this data and process it to prese= nt useful information"? This draft is introducing a new method to log such elements; = is this a concern at all? [Med] FWIW, one of the co-authors is the main editor of draft-ietf-behave-i= pfix-nat-logging. As a reminder, this draft reuses the IPFIX registry becau= se it offers a rich set of elements. Further, this draft does not focues on= NAT logging. Of course, some TLV can be used for notification purposes but= this is not logging per se. The examples of use cases of the new attributes include both NAT44 devices = and CGNs. The document could state more clearly the address sharing scenarios, perhap= s with a simplified network element diagram for each example, showing the user/host,= CPE/NAT44, and NAT444/CGN? [Med] I'm sure if this will add more clarity to the draft because there are= many deployment cases that can be cited. The draft explicitly calls out th= e CPE case and CGN. Some additional clarity here would be useful (see also comments below). Also, the term "the user" is used in many places in the document where in p= ractice "the customer's CPE" would be more appropriate. [Med] I agree that some occurrences can be replaced easily by subscriber or= customer but still "user" is accurate. For example, it is not a customer t= hat initiates a connection but a user (that may be the customer itself or a= nother person that uses the right to invoke the service). In order to avoid= overloading the document with such subtleties, we prefer to use "user" in = the whole document. Specific comments: NAT64 is mentioned as a use case at the start, but no example is given late= r in the document. This might add useful value. [Med] Happily! We will update the text accordingly. In Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elements = in the TLV are 16 bit values, but 32 bits are reserved for the element. Similarly = the NatEvent element is 8-bit, but has 32 bits reserved. It would be useful if = the document stated why these elements are being padded out to 32 bits. [Med] Please check https://tools.ietf.org/html/rfc6158#appendix-A.2.1 In Section 4.1.1, I don't think NAT64 is specifically designed to multiplex= users over a smaller number of shared IPv4 addresses, rather its primary design g= oal is to facilitate access to legacy IPv4 content from IPv6-only networks. Th= e text should be clarified. [Med] I guess you are referring to "over a smaller number of shared IPv4 ad= dresses". "Smaller" is used here to indicate that the external IP address p= ool is not sufficient to assign a full IPv4 address to each internal host. = NAT64 falls into such category. RFC6146 says: "One or more public IPv4 addr= esses assigned to a NAT64 translator are shared among several IPv6-only clients." Also in 4.1.1, do users really have service agreements that state port limi= ts? [Med] There is no assumption in the draft that SLAs include port limits. If they do, I doubt users are aware of them (or care...), and the issue is = beyond the scope of this document. [Med] Agree. In 4.1.2, I think you mean "block", not "bulk"? And the comment on "randomization" might fit better in the Security Conside= rations section if you discuss privacy there (which is presumably what you mean?) [Med] Can be added, indeed. Also in 4.1.2 you discuss the scenario as if it's CGN, but the flow diagram= shows only the NAT44 (presumably in the CPE) and not an ISP CGN. [Med] No, the diagram shows a NAT that is collocated with a BNG. This is a = CGN case. The same happens in 4.1.3; discussion of CGN and NAT44 interchangeably, wit= hout the diagram showing there may (presumably) be mappings to establish at both= the user's CPE and the ISP's CGN. [Med] Idem as above. And in 4.1.4 the example talks of NAT44 for Joe's CPE, but then also about = a CGN allocating more ports; is that at the NAT44, or at the CGN? [Med] The intent is CGN here. The text can be clarified. (These specific NAT44/CGN comments are examples of the general comment I ma= de earlier.) In Section 5, I found the format of the table with 0 and 0+ a little unintu= itive. [Med] This is not specific to this document. We are following the format in= https://tools.ietf.org/html/rfc2865#section-5.44. You can see, e.g.,: =B7 https://tools.ietf.org/html/rfc6911#section-3.6 =B7 https://tools.ietf.org/html/rfc7268#section-3 =B7 ... -- Tim --_000_787AE7BB302AE849A7480A190F8B933008E220CDOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tim,

 

(Apologies for the delay to ans= wer the message)

 

Thank you for the review.

 

Please see inline.

 

Cheers,

Med

 

De : Tim = Chown [mailto:Tim.Chown@jisc.ac.uk]
Envoy=E9 : mercredi 17 ao=FBt 2016 12:23
=C0 : ops-dir@ietf.org; draft-ietf-radext-ip-port-radius-ext.al= l@ietf.org
Objet : OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-= 11

 

Hi,

 =

I have reviewed t= his document as part of the Operational directorate's 

ongoing effort to= review all IETF documents being processed by the IESG.  These 

comments were wri= tten with the intent of improving the operational aspects of the =

IETF drafts. Comm= ents that are not addressed in last call may be included in AD reviews = ;

during the IESG r= eview.  Document editors and WG chairs should treat these comments&nbs= p;

just like any oth= er last call comments. 

 =

This draft define= s three new RADIUS attributes to be used when communicating with a 

RADIUS server to = facilitate the configuration or reporting of IP and port ranges used <= o:p>

with a network ap= pliance, typically a CGN, where there is a need to constrain 

the ports availab= le per customer where IP address sharing is in use.

 =

The three RADIUS = attributes are:

IP-Port-Limit-Inf= o - defines the maximum number of ports available

IP-Port-Range - t= he specific range of port numbers available

IP-Port-Forwardin= g-Map - to configure port forwarding on a NAT/CGN device<= /p>

 =

I would consider = the document to be "Ready with Issues".

 =

I have some gener= al comments, followed by some specific comments. Note that while I

am familiar with = RADIUS (from an eduroam context) the draft is not one I was 

familiar with or = followed prior to this review. Thus these comments may have already

been addressed.

 =

General comments:=

 =

There are at leas= t two areas in which this document has "creep". One is that it is=  

providing an alte= rnative method to PCP to define port forwarding mappings on a device.<= /o:p>

So there is an op= en question as to whether PCP should be the method of choice for=

this function, or= whether we wish to create a new way to establish such mappings.=

 

[Med= ] PCP targets a different deployment model where an application controls it= s mapping in a CPE, CGN, Firewall, etc. This document targets a deployment where a AAA server is responsible de instructing NAT = mappings for a given subscriber.

 

Secondly, two of = the new attributes support inclusion of a new TLV, IP-Port-Local-Id,

which allows user= /device-specific information to be transmitted via RADIUS, such as

MAC address or VL= AN ID. While this is intended to allow differentiation of users for

accounting/identi= fication r, in doing so it adds an additional potential privacy<= /span>

concern into a ne= w RADIUS attribute, depending on specific use cases of the TLV.<= /span>

 

[Med= ] The main use case is the deployment where the internal IP address is not = sufficient to demux users. We introduced this NEW text in -12:

 

   The primary issue addressed by this =
TLV is that there are CGN
   deployments that do not distinguish =
internal hosts by their internal
   IP address alone, but use further id=
entifiers for unique subscriber
   identification.  For example, t=
his is the case if a CGN supports
   overlapping private or shared IP add=
ress spaces (refer to [RFC1918]

   and [RFC6598]) for internal hosts of different subscribers.  In such


   cases, different internal hosts are =
identified and mapped at the CGN


   by their IP address and/or another i=
dentifier, for example, the


   identifier of a tunnel between the C=
GN and the subscriber.  In these


   scenarios (and similar ones), the in=
ternal IP address is not


   sufficient to demultiplex connection=
s from internal hosts.  An


   additional identifier needs to be pr=
esent in the IP-Port-Range


   Attribute and IP-Port-Forwarding-Map=
ping Attribute in order to


   uniquely identify an internal host.&=
nbsp; The IP-Port-Local-Id TLV is used


   to carry this identifier.


 


 

This is not discu= ssed in the Security Considerations section, but probably should be.

[Med= ] Fair point. We added this text:

 

   The IP-Port-Local-Id TLV includes an=
 identifier of which the type and
   length is deployment and implementat=
ion dependent.  This identifier
   might carry privacy sensitive inform=
ation.  It is therefore
   RECOMMENDED to utilize identifiers t=
hat do not have such privacy
   concerns.

 

I = note the new attributes use a number of IPFIX information elements; has the= draft

considered its re= lationship to draft-ietf-behave-ipfix-nat-logging-09, which says=

the "lack of= a consistent way to log the data makes it difficult to write the 

collector applica= tions that would receive this data and process it to present useful 

information"= ? This draft is introducing a new method to log such elements; is this=

a concern at all?=

 

[Med= ] FWIW, one of the co-authors is the main editor of draft-ietf-behave-ipfix= -nat-logging. As a reminder, this draft reuses the IPFIX registry because it offers a rich set of elements. Further, this dra= ft does not focues on NAT logging. Of course, some TLV can be used for noti= fication purposes but this is not logging per se.

 

The examples of u= se cases of the new attributes include both NAT44 devices and CGNs. 

The document coul= d state more clearly the address sharing scenarios, perhaps with a

simplified networ= k element diagram for each example, showing the user/host, CPE/NAT44,<= /o:p>

and NAT444/CGN?

 

[Med= ] I’m sure if this will add more clarity to the draft because there a= re many deployment cases that can be cited. The draft explicitly calls out the CPE case and CGN.  

 

So= me additional clarity here would be useful (see also comments below).<= /o:p>

Also, the term &q= uot;the user" is used in many places in the document where in practice=  

"the custome= r's CPE" would be more appropriate.

 

[Med= ] I agree that some occurrences can be replaced easily by subscriber or cus= tomer but still “user” is accurate. For example, it is not a customer that initiates a connection but a user (that may be the = customer itself or another person that uses the right to invoke the service= ). In order to avoid overloading the document with such subtleties, we pref= er to use “user” in the whole document.

 

 

Specific comments= :

 =

NAT64 is mentione= d as a use case at the start, but no example is given later in the 

document. This mi= ght add useful value.

 

[Med= ] Happily! We will update the text accordingly.

 

In= Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elements in= the 

TLV are 16 bit va= lues, but 32 bits are reserved for the element. Similarly the 

NatEvent element = is 8-bit, but has 32 bits reserved. It would be useful if the

document stated w= hy these elements are being padded out to 32 bits. <= /p>

 

[Med= ] Please check https://tool= s.ietf.org/html/rfc6158#appendix-A.2.1

 

In Section 4.1.1,= I don't think NAT64 is specifically designed to multiplex users=

over a smaller nu= mber of shared IPv4 addresses, rather its primary design goal

is to facilitate = access to legacy IPv4 content from IPv6-only networks.  The=

text should be cl= arified.

 

[Med] I guess you are refer=
ring to “over a smaller number of shared =
IPv4 addresses”. &#=
8220;Smaller” is used here to indicate that the external IP address p=
ool is not sufficient to assign a full IPv4 address to each internal host. =
NAT64 falls into such category. RFC6146 says: “One or more public IPv4 addresses assigned to a NAT64
   translator are shared among several =
IPv6-only clients.”=

 

Al= so in 4.1.1, do users really have service agreements that state port limits= ?

[Med= ] There is no assumption in the draft that SLAs include port limits.

 

If= they do, I doubt users are aware of them (or care...), and the issue is be= yond

the scope of this= document. 

[Med] Agree.

 =

In 4.1.2, I think= you mean "block", not "bulk"?  =

An= d the comment on "randomization" might fit better in the Security= Considerations

section if you di= scuss privacy there (which is presumably what you mean?)<= /p>

 

[Med= ] Can be added, indeed.

 

Also in 4.1.2 you= discuss the scenario as if it's CGN, but the flow diagram shows=

only the NAT44 (p= resumably in the CPE) and not an ISP CGN. 

 

[Med= ] No, the diagram shows a NAT that is collocated with a BNG. This is a CGN = case.

 

The same happens = in 4.1.3; discussion of CGN and NAT44 interchangeably, without

the diagram showi= ng there may (presumably) be mappings to establish at both the 

user's CPE and th= e ISP's CGN.

 

[Med] Idem as above= --_000_787AE7BB302AE849A7480A190F8B933008E220CDOPEXCLILMA3corp_--