From nobody Tue Jan 3 03:23:28 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359D7129569; Tue, 3 Jan 2017 03:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.302 X-Spam-Level: X-Spam-Status: No, score=-7.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, 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 E0gyg_ixUFzL; Tue, 3 Jan 2017 03:23:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B56B12956A; Tue, 3 Jan 2017 03:23:25 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 07E91B80120; Tue, 3 Jan 2017 03:23:25 -0800 (PST) To: misha.zaytsev.rus@gmail.com, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170103112325.07E91B80120@rfc-editor.org> Date: Tue, 3 Jan 2017 03:23:25 -0800 (PST) Archived-At: Cc: dime@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Errata Verified] RFC6733 (4887) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:23:27 -0000 The following errata report has been verified for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4887 -------------------------------------- Status: Verified Type: Technical Reported by: Mikhail Zaytsev Date Reported: 2016-12-13 Verified by: Benoit Claise (IESG) Section: 6.2 Original Text ------------- When a request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command: o The same Hop-by-Hop Identifier in the request is used in the answer. o The local host's identity is encoded in the Origin-Host AVP. o The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message. Corrected Text -------------- When a request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command: o The same Hop-by-Hop Identifier in the request is used in the answer. o The local host's identity is encoded in the Origin-Host AVP. o The local realm's identity is encoded in the Origin-Realm AVP. o The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message. Notes ----- Unlike Origin-Host AVP, it is not stated explicitly that Origin-Realm AVP MUST be encoded in the associated answer. While both these AVPs MUST be present in all Diameter messages according to their descriptions. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Jan 3 03:45:39 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91B01294EB; Tue, 3 Jan 2017 03:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.018 X-Spam-Level: X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, 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 Uyn_LudljQEN; Tue, 3 Jan 2017 03:45:36 -0800 (PST) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BE8129435; Tue, 3 Jan 2017 03:45:35 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 5232EC0958; Tue, 3 Jan 2017 12:45:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 33016180062; Tue, 3 Jan 2017 12:45:34 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 12:45:33 +0100 From: To: Benoit Claise , "aaa-doctors@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) Thread-Index: AQHSWeYdhHq35r8PM0yaMog4/GN22aEmqGdwgAAQ10A= Date: Tue, 3 Jan 2017 11:45:33 +0000 Message-ID: <17526_1483443934_586B8EDE_17526_11792_1_6B7134B31289DC4FAF731D844122B36E0BFC600A@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160913214213.4DBFAB80B89@rfc-editor.org> <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0BFC600AOPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: "dime@ietf.org" , "holger+ietf@freyther.de" Subject: Re: [Dime] [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:45:38 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0BFC600AOPEXCLILM43corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This errata report is correct on the inconsistency regarding the definition= of the command header and AVP header and how they are used in the rest of = the document in the ABNF description of commands and Grouped AVPs. For commands, the header is defined as follow: header =3D "" whereas "" whereas " In section 3.2. Command Code Format Specification OLD: header =3D "" NEW: header =3D "" --> And in section 4.4 OLD: header =3D "<" "AVP-Header:" avpcode [vendor] ">" NEW: header =3D "<" "AVP Header:" avpcode [vendor] ">" ******************* There are other issues pointed out in this report. For command-def =3D "<" command-name ">" "::=3D" diameter-message, I would= propose to simply correct the example as all the command definitions given= in the document are following the command-def definition. For the grouped-avp-def, I don't know what would be the best approach. We c= ould follow the same approach and require the addition of "<>" but I don't = know what would be the impacts on existing Grouped AVPs defined without. Regards, Lionel. -------- Forwarded Message -------- Subject: [Editorial Errata Reported] RFC6733 (4803) Date: Tue, 13 Sep 2016 14:42:13 -0700 From: RFC Errata System To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.no= spam@gmail.com, lionel.morand@orange.com CC: holger+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4803 -------------------------------------- Type: Editorial Reported by: Holger Freyther Section: 3.2 Original Text ------------- Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Corrected Text -------------- ::=3D < Diameter-Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Notes ----- I converted the BNF into a PetitParser parser in Smalltalk/Pharo and notice= d that example and grammar do not match. The first issue is with the exampl= e following the grammar but most definitions do not follow the BNF so maybe= it is best to update the BNF. header =3D "" But "Diameter-Header:" is not used throughout the text so maybe it is bette= r to update the grammar to "Diameter Header:". command-def =3D "<" command-name ">" "::=3D" diameter-message but the example is not using <> for the command-name ("Example-Request"). F= or the grouped-avp-def application is sometimes used with "<" name ">" and = sometimes just name. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG . ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_6B7134B31289DC4FAF731D844122B36E0BFC600AOPEXCLILM43corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This errat= a report is correct on the inconsistency regarding the definition of the co= mmand header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs.=

 = ;

For comman= ds, the header is defined as follow:

 = ;

 &nbs= p; header           =3D &= quot;<Diameter-Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 = ;

whereas &q= uot;<Diameter Header:" is used when defining commands.

 = ;

Same for G= rouped AVP. It is defined as follow:

 = ;

 &nbs= p;       header     =       =3D "<" "AVP-Header:"= avpcode [vendor] ">"

 = ;

whereas &q= uot;<AVP Header:" is used when defining Grouped AVPs.

 = ;

Considerin= g that most (if not all) the ABNF descriptions have been copied from the co= mmands and Grouped AVPs defined in the RFC3588 or RFC6733, I would be in favor to correct the specification by modifying the definiti= on of the headers, i.e.

 = ;

--> In = section 3.2.  Command Code Format Specification

 = ;

OLD:<= /o:p>

 = ;

 &nbs= p; header           = =3D "<Diameter-Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 = ;

NEW:<= /o:p>

 = ;

 &nbs= p; header           = =3D "<Diameter Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 = ;

 = ;

--> And= in section 4.4

 = ;

OLD:<= /o:p>

 = ;

 &nbs= p;       header     =       =3D "<" "AVP-Header:"= avpcode [vendor] ">"

 = ;

NEW:<= /o:p>

 = ;

 &nbs= p;       header     =       =3D "<" "AVP Header:"= avpcode [vendor] ">"

 = ;

**********= *********

There are = other issues pointed out in this report.

 = ;

For comman= d-def  =3D "<" command-name ">" "::=3D&= quot; diameter-message, I would propose to simply correct the example as al= l the command definitions given in the document are following the command-def definition.

For the gr= ouped-avp-def, I don't know what would be the best approach. We could follo= w the same approach and require the addition of "<>" but I don't know what would be the impacts on existing Grouped AVPs defined with= out.

 = ;

Regards,

 = ;

Lionel.

 <= /p>


-------- Forwarded Message --------

Subjec= t:

[Editorial Errata Reported] RFC6733 (4803)

Date: =

Tue, 13 Sep 2016 14:42:13 -0700

From: =

RFC Errata System <rfc-editor@rfc-editor.org>

To:

vf0213@gmail.com= , jari.arkko@ericsson.com, joh= n.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com= , jouni.nospam@gmail.com, lio= nel.morand@orange.com

CC:

holge= r+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC6733,=

"Diameter Base Protocol".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=
=3D4803
 
--------------------------------------
Type: Editorial
Reported by: Holger Freyther <holger+ietf@freyther.de>
 
Section: 3.2
 
Original Text
-------------
   Example-Request ::=3D < Diameter Header: 9999999, REQ,=
 PXY >
           &nbs=
p;           { User-Name =
}
           &nbs=
p;        1* { Origin-Host }<=
/pre>

           &nbs=
p;         * [ AVP ]

 


 


 


Corrected Text


--------------


   <Example-Request> ::=3D < Diameter-Header: 99999=
99, REQ, PXY >


           &nbs=
p;           { User-Name =
}


           &nbs=
p;        1* { Origin-Host }<=
/pre>

           &nbs=
p;         * [ AVP ]

 


 


 


Notes


-----


I converted the BNF into a PetitParser parser in Smalltalk/Pharo and n=
oticed that example and grammar do not match. The first issue is with the e=
xample following the grammar but most definitions do not follow the BNF so =
maybe it is best to update the BNF. 


 


  header         &nb=
sp; =3D "<Diameter-Header:" command-id


           &nbs=
p;             =
[r-bit] [p-bit] [e-bit] [application-id]">"


 


But "Diameter-Header:" is not used throughout the text so ma=
ybe it is better to update the grammar to "Diameter Header:".


 


 


 command-def      =3D "<" comman=
d-name ">" "::=3D" diameter-message


 


but the example is not using <> for the command-name ("Exam=
ple-Request"). For the grouped-avp-def application is sometimes used w=
ith "<" name ">" and sometimes just name.


 


Instructions:


-------------


This erratum is currently posted as "Reported". If necessary=
, please


use "Reply All" to discuss whether it should be verified or<=
o:p>


rejected. When a decision is reached, the verifying party (IESG)<=
/o:p>


can log in to change the status and edit the report, if necessary. 


 


--------------------------------------


RFC6733 (draft-ietf-dime-rfc3588bis-33)


--------------------------------------


Title           =
;    : Diameter Base Protocol


Publication Date    : October 2012


Author(s)           =
: V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.


Category          &n=
bsp; : PROPOSED STANDARD


Source          &nbs=
p;   : Diameter Maintenance and Extensions


Area           =
     : Operations and Management


Stream          &nbs=
p;   : IETF


Verifying Party     : IESG


 


.


 


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E0BFC600AOPEXCLILM43corp_-- From nobody Wed Jan 4 09:30:11 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A919129695; Wed, 4 Jan 2017 09:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.302 X-Spam-Level: X-Spam-Status: No, score=-7.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, 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 Jic5KfzbQn9C; Wed, 4 Jan 2017 09:30:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36982129669; Wed, 4 Jan 2017 09:30:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1940BB803C1; Wed, 4 Jan 2017 09:30:10 -0800 (PST) To: zbigniew.rapnicki@computaris.com, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170104173010.1940BB803C1@rfc-editor.org> Date: Wed, 4 Jan 2017 09:30:10 -0800 (PST) Archived-At: Cc: dime@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Errata Verified] RFC6733 (4808) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 17:30:11 -0000 The following errata report has been verified for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4808 -------------------------------------- Status: Verified Type: Technical Reported by: Zbigniew Rapnicki Date Reported: 2016-09-22 Verified by: Benoit Claise (IESG) Section: 1.1.3 Original Text ------------- This document obsoletes RFC 3588 but is fully backward compatible with that document. Corrected Text -------------- This document obsoletes RFC 3588. Notes ----- When comparing the BNF for the answer messages CEA, DPA, DWA, RAA, STA and ASA it can be seen that FAILED-AVP avp is no longer marked with the * which means it can be present only once in the diameter message. Previous specification (rfc3588) defines multiple FAILED-AVP avp usage in a single diameter message. Similar case is for Vendor-Specific-Application-Id AVP definition. Previous specification allows multiple usage of Vendor-Id avp in a single message while the new specification defines it as a single mandatory AVP: rfc3588: ::= < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } rfc6733: ::= < AVP Header: 260 > { Vendor-Id } [ Auth-Application-Id ] [ Acct-Application-Id ] How this facts applies to the sentence about fully backward compatibility in the section 1.1.3? -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Jan 6 08:33:29 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47AC1294C1 for ; Fri, 6 Jan 2017 08:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzobq981kVoh for ; Fri, 6 Jan 2017 08:33:25 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195C7129411 for ; Fri, 6 Jan 2017 08:33:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E6567BE51 for ; Fri, 6 Jan 2017 16:33:22 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu1OaoTdbhHs for ; Fri, 6 Jan 2017 16:33:22 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3AA78BE3E for ; Fri, 6 Jan 2017 16:33:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483720402; bh=y38HZDumP0ZHr+uNozZKC6qRIOYBG3bboWwyQTr13v0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QUiH9zgHzCwFVvZkO5U9TNjt8a//8rquXb+DDmPiHTIvPwHqK04w3IxxnWGooeH7u QMEXehvTYiYFhuYrZV3JDpAdiX5ac85O/b30ePwxeCLIORG+lCbf84QCDskHHrkM2O OZ6SIWHysECPFHO4zp1zqgnFr2BsayAyaCW7x5lU= To: "dime@ietf.org" References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> Date: Fri, 6 Jan 2017 16:33:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030608050004000004090204" Archived-At: Subject: Re: [Dime] AD evaluation of draft-ietf-dime-load-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 16:33:27 -0000 This is a cryptographically signed message in MIME format. --------------ms030608050004000004090204 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just bumping this, post holidays. I believe the ball is not in my court for this one:-) Cheers, S. On 16/12/16 17:38, Stephen Farrell wrote: >=20 > Hiya, >=20 > Thanks for getting this stuff progressed. I've done my > AD evaluation and have a few questions I'd like to ask > before starting IETF last call. Those are below along > with some more nitty comments that can be handled now or > later as the authors/WG prefer. >=20 > Cheers, > S. >=20 > Things to chat about before starting IETF LC: > --------------------------------------------- >=20 > (1) Is "server selection" sufficiently clear? Where is > that defined? I was a bit confused as to what this means > that is not next-hop selection. >=20 > (2) PEER reports that are first received at a > non-supporting node will be left in place and will reach > the destination of the message. If that destination is in a > different domain then that leaks some internal structure > (the SourceID) to outsiders. Is that desirable? Why not > have the first node that does support this AVP delete the > PEER report even if the node that added the PEER report is > not a peer of this node? (Note: I see this risk is ack'd > in section 8, I'm asking if we can avoid it almost > entirely by removing PEER reports that are useless.) >=20 > (3) This spec is a bit like RFC7944 (DRMP) in that it > defines some but not all of the things one needs to end up > with a workable system. That aspect of DRMP caused some > discussion during IESG evaluation. Have the authors of > this reviewed that discussion to see if we can avoid any > likely iterations being needed at that point? I'm hoping > that Steve, as an author of both, won't find this too > hard to do:-) If that's been done, great. If not, please > consider if there's any additional explanatory material > that could be added that might help us not to have to > iterate to discuss the same kinds of concern. >=20 > nits (fine to be considered last call comments): > ------------------------------------------------- >=20 > abstract: maybe put the 1st sentence last? that might read > better >=20 > 4.1: the "opinion of the authors" isn't really of interest > at this point - is this also the opinion of the WG? (I > assume it is) >=20 > section 5 says "The load report includes a value > indicating the load of the sending node relative load of > the sending node, specified in a manner consistent with > that defined for DNS SRV [RFC2782]." I can't parse that. >=20 > - 6.2: What is a Diameter "connection?" I thought that > Diameter could use UDP as well as TCP so is that really > the right term? Maybe "message sender" is a better way to > identify the peer? >=20 > - section 8: "might require a transitive trust model" is > far too coy IMO. I think you should say that DOIC and this > entirely require transitive trust because we have no > Diameter mechanism that allows authenticated adding and > removal of AVPs as messages transit a network. (We did try > develop that ages ago but it was too complex, so I'm not > arguing to try again, just that we clearly ack the fact > that this stuff requires transitive trust.) >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 --------------ms030608050004000004090204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDYx NjMzMjFaMC8GCSqGSIb3DQEJBDEiBCAhUDUOYJJVqJH9rmJ47ku2RYpPeLXqFRK5qBDRvT3v pjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAo2cUm64rQXIXZxQlz7dNHRxbjxnmZg2oBKBqEvJ4olxxR87Nj9tmH TthJk39F1ox2PbP6KRwaida0NdTTk2iFpIzqjhGp2u89G6TvlQKOGEfKY0uRuAFdYP49Jc3o 2K/FmmCdxfRnsCwUoEWXWfyZoUkF9PU9KASHAHfN4nooOXRZ9KJqepz9PNSIQ7pYlbWpHOHb +gsG/ZBu5l//mxa1PaeeQqDYIwm/yMdHnD4r+Pa7QXBpVgbt4sAGRWDtzhVU4zk06JLVwLUd FccX7Cla6ZrlqeiQe/U5FAkN2S6aXl6gIUn+nU6qUNZ7jK/Mbn1w+ChVZ+Dbu+33f+Z0QpnX AAAAAAAA --------------ms030608050004000004090204-- From nobody Mon Jan 9 05:46:46 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD71129CDC for ; Mon, 9 Jan 2017 05:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.144 X-Spam-Level: X-Spam-Status: No, score=0.144 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5] 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 mc5hKNxGOsIr for ; Mon, 9 Jan 2017 05:46:43 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69A01293FB for ; Mon, 9 Jan 2017 05:46:42 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d65 with ME id WDmf1u00H17Lgi403Dmfqb; Mon, 09 Jan 2017 14:46:40 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Mon, 09 Jan 2017 14:46:40 +0100 X-ME-IP: 92.170.5.52 To: dime@ietf.org From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <3f911981-962e-3a60-9fa5-a20ee1bb30fa@trigofacile.com> Date: Mon, 9 Jan 2017 14:46:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Dime] Obsolete TLS wording in Diameter protocol X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 13:46:45 -0000 Hi all, The Diameter specification (RFC 6733) mentions in Section 13.1 that the TLS_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_SHA cipher suites are required ("Diameter nodes MUST be able to negotiate [them]"), and Section 5.2 does not give latest recommendations for certificate validation. Shouldn't it be updated in favour of following RFC 7525 (BCP for TLS) and RFC 6125 (guideline for certificate validation)? -- Julien ÉLIE « The following two statements are usually both true: There's not enough documentation. There's too much documentation. » (Larry Wall) From nobody Mon Jan 9 06:22:19 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57635129D04 for ; Mon, 9 Jan 2017 06:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjdKyi4pnMQw for ; Mon, 9 Jan 2017 06:22:12 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22904129CF6 for ; Mon, 9 Jan 2017 06:21:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 72BBBBE49 for ; Mon, 9 Jan 2017 14:21:54 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54LZImZ3hcMS for ; Mon, 9 Jan 2017 14:21:53 +0000 (GMT) Received: from [172.28.172.2] (unknown [185.51.75.90]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 94246BE39 for ; Mon, 9 Jan 2017 14:21:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483971713; bh=ocDVbLFoOdhyIroSK0japMGoVx5iqRsmPy4tcDY368s=; h=Subject:To:From:Date:From; b=PY3aeNCyNOfwuR3pCNA4ill+F6yuRE54Lf5mwCplswMOsNPIMCwne4fV8YWJ7oyWy GrmG8cyU/PxvmNnOGZAKnJ8ZzDIX/elBLuoqFL3G0/krQ0DJ3ty0jk9W0AHbbHb/jJ WGtOoahzpkwcuD3S3xL80KFauFLNp3kWC1d284JQ= To: "dime@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 9 Jan 2017 14:21:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020800040909050404030402" Archived-At: Subject: [Dime] AD review of draft-ietf-dime-agent-overload-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:22:15 -0000 This is a cryptographically signed message in MIME format. --------------ms020800040909050404030402 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Sorry for the delay with this - it was mis-routed to Katheeen's queue somehow. I've done my AD review and will start IETF LC shortly. I agree with the shepherd that the i-d nits output can be ignored;-) My nitty comments below can be handled as part of IETF LC, Cheers, S. - section 2: might be nice to add "Diameter agent" to this section. Either that or just eliminte this section if these terms are defined already elsewhere. - 5.1.1: OC_PEER_REPORT is very abruptly introduced. A sentence to describe it or point to where it's defined (6.1.1 I guess) would maybe be good. --------------ms020800040909050404030402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDkx NDIxNTJaMC8GCSqGSIb3DQEJBDEiBCAT0BEVl7b7HTubYyurvtVbx02fERX468nu43gBQoOa tjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCzElb6lowengXsLiJ3L/WF4VkAFBk+mMfyER/BEP0+8fmHEpnRylaP FFln/mvBgHBYWh7OAPN1q9tx/Ci0BSG3H1zIzfWbUcVcOu1NPToU3wy5uOtUtO7wa6Ko93pb sRATHZSRcFpRMjtRMXk8bjxppg6A8DD5A2EEi3bFCo/B9jCILc+Ln2ineojrpeQSsNXDVxk6 6Jy9V9GMi45jsB/BQr5o42xF7fHKVyZAcQcWy9SlPTanLaRJkU6lCciyHZdlokhdCZXChpBY CRbAB6Qe/J0Hnf2Pg+CcP59AUYqKJBtCcBBZpQ4F0ksX1VdOc78tQRJ3x5AS1qGmxb6KHG60 AAAAAAAA --------------ms020800040909050404030402-- From nobody Mon Jan 9 06:35:22 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B361129CEB; Mon, 9 Jan 2017 06:35:17 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2017 06:35:17 -0800 Archived-At: Cc: dime@ietf.org, dime-chairs@ietf.org, draft-ietf-dime-agent-overload@ietf.org Subject: [Dime] Last Call: (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:35:17 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Agent Overload and the Peer Overload Report' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification documents an extension to RFC 7683 (Diameter Overload Indication Conveyance (DOIC)) base solution. The extension defines the Peer overload report type. The initial use case for the Peer report is the handling of occurrences of overload of a Diameter agent. Requirements The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload Control (None - ) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Mon Jan 9 06:59:34 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15889129D3E for ; Mon, 9 Jan 2017 06:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 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=-3.199, 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 I-KdPyLL_dUf for ; Mon, 9 Jan 2017 06:59:33 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.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 B153B129D37 for ; Mon, 9 Jan 2017 06:59:32 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 78A7720894; Mon, 9 Jan 2017 15:59:30 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 516992006E; Mon, 9 Jan 2017 15:59:30 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0319.002; Mon, 9 Jan 2017 15:59:30 +0100 From: To: =?utf-8?B?SnVsaWVuIMOJTElF?= , "dime@ietf.org" Thread-Topic: [Dime] Obsolete TLS wording in Diameter protocol Thread-Index: AQHSan7UF/6G98qxF0K6juZVPgkSPKEwMQ+g Date: Mon, 9 Jan 2017 14:59:29 +0000 Message-ID: <4987_1483973970_5873A552_4987_327_1_6B7134B31289DC4FAF731D844122B36E0BFDC80F@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <3f911981-962e-3a60-9fa5-a20ee1bb30fa@trigofacile.com> In-Reply-To: <3f911981-962e-3a60-9fa5-a20ee1bb30fa@trigofacile.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: Subject: Re: [Dime] Obsolete TLS wording in Diameter protocol X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 14:59:34 -0000 SGkgSnVsaWVuLA0KDQpUaGUgZmlyc3QgcG9pbnQgb24gY2lwaGVyIHN1aXRlcyBoYXMgYmVlbiBh bHJlYWR5IHJhaXNlZC4gVGhlIHByb2hpYml0aW9uIG9mIHRoZSB1c2Ugb2YgdGhlIFJDNC1iYXNl ZCBjaXBoZXIgc3VpdGVzIChSRkM3NDY1KSBjYW1lIGFmdGVyIHRoZSBwdWJsaWNhdGlvbiBvZiB0 aGUgUkZDNjczMy4gQnV0IHRoZSBSRkM3NDY1IGlzIGFueXdheSBhbiB1cGRhdGUgb2YgdGhlIFJG QzUyNDYgdGhhdCBpcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgaW4gdGhlIFJGQzY3MzMuIFNvIGFu eW9uZSBpbXBsZW1lbnRpbmcgVExTIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlzIHVwZGF0ZS4gVGhl cmUgaXMgbm8gbmVlZCBvZiBhbiBlcnJhdGEgcmVwb3J0IGJ1dCBpdCB3aWxsIGJlIGNvdmVyZWQg aW4gYSBmdXR1cmUgdXBkYXRlIG9mIHRoZSBSRkM2NzMzIGlmIGFueS4NCg0KRm9yIHRoZSBSRkM2 MTI1LCBpdCBzaG91bGQgYmUgZmlyc3Qgd29ydGh3aGlsZSB0byBtZW50aW9uIHRoYXQgdGhlIFJG QzY3MzMgaW5kaWNhdGVzIHRoYXQsIGZvciB0aGUgdGltZSBiZWluZywgdGhlcmUgaXMgbm8gRGlh bWV0ZXIgc2VydmVyIENlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMuIEhvd2V2ZXIsIHRoZSBSRkM1 MjgwIGlzIGdpdmVuIGFzIG5vcm1hdGl2ZSByZWZlcmVuY2UgYW5kIHRoaXMgb25lIGlzIG5vdCBz dXBlcnNlZGVkIGJ5IFJGQzYxMjUgc28gZmFyLiBBbmQgUkZDNjEyNSBjb3VsZCBiZSBhbHNvIHNl ZW4gYXMgb3J0aG9nb25hbCB0byB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIERpYW1ldGVyIGJh c2UgcHJvdG9jb2wuIEl0IGNvdWxkIGJlIHBhcnQgb2YgYW4gdXBkYXRlIGlmIHRoZXJlIHdvdWxk IGJlIGEgcmVhbCBuZWVkIHRvIGNsYXJpZnkgc29tZXRoaW5nIGxlZnQgb3V0c2lkZSBvZiBSRkM1 MjgwLg0KDQpBdCBsZWFzdCwgaXQgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5kaW5nLg0KSSBob3Bl IHRoYXQgaXQgY2xhcmlmaWVzIHlvdXIgY29uY2VybnMuDQoNClJlZ2FyZHMsDQoNCkxpb25lbCAg ICANCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRGlNRSBbbWFpbHRv OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKdWxpZW4gw4lMSUUNCj4gRW52 b3nDqcKgOiBsdW5kaSA5IGphbnZpZXIgMjAxNyAxNDo0Nw0KPiDDgMKgOiBkaW1lQGlldGYub3Jn DQo+IE9iamV0wqA6IFtEaW1lXSBPYnNvbGV0ZSBUTFMgd29yZGluZyBpbiBEaWFtZXRlciBwcm90 b2NvbA0KPiANCj4gSGkgYWxsLA0KPiANCj4gVGhlIERpYW1ldGVyIHNwZWNpZmljYXRpb24gKFJG QyA2NzMzKSBtZW50aW9ucyBpbiBTZWN0aW9uIDEzLjEgdGhhdCB0aGUNCj4gVExTX1JTQV9XSVRI X1JDNF8xMjhfTUQ1IGFuZCBUTFNfUlNBX1dJVEhfUkM0XzEyOF9TSEEgY2lwaGVyIHN1aXRlcw0K PiBhcmUgcmVxdWlyZWQgKCJEaWFtZXRlciBub2RlcyBNVVNUIGJlIGFibGUgdG8gbmVnb3RpYXRl IFt0aGVtXSIpLCBhbmQgU2VjdGlvbg0KPiA1LjIgZG9lcyBub3QgZ2l2ZSBsYXRlc3QgcmVjb21t ZW5kYXRpb25zIGZvciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uLg0KPiANCj4gU2hvdWxkbid0IGl0 IGJlIHVwZGF0ZWQgaW4gZmF2b3VyIG9mIGZvbGxvd2luZyBSRkMgNzUyNSAoQkNQIGZvciBUTFMp IGFuZCBSRkMNCj4gNjEyNSAoZ3VpZGVsaW5lIGZvciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uKT8N Cj4gDQo+IC0tDQo+IEp1bGllbiDDiUxJRQ0KPiANCj4gwqsgVGhlIGZvbGxvd2luZyB0d28gc3Rh dGVtZW50cyBhcmUgdXN1YWxseSBib3RoIHRydWU6DQo+ICAgIFRoZXJlJ3Mgbm90IGVub3VnaCBk b2N1bWVudGF0aW9uLg0KPiAgICBUaGVyZSdzIHRvbyBtdWNoIGRvY3VtZW50YXRpb24uIMK7IChM YXJyeSBXYWxsKQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gRGlNRUBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K Cg== From nobody Mon Jan 9 13:14:13 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484EA12958A for ; Mon, 9 Jan 2017 13:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5] 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 mpXkNTcvYUVV for ; Mon, 9 Jan 2017 13:14:09 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D58129522 for ; Mon, 9 Jan 2017 13:14:08 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d22 with ME id WME61u00117Lgi403ME6yK; Mon, 09 Jan 2017 22:14:06 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Mon, 09 Jan 2017 22:14:06 +0100 X-ME-IP: 92.170.5.52 To: "dime@ietf.org" References: <3f911981-962e-3a60-9fa5-a20ee1bb30fa@trigofacile.com> <4987_1483973970_5873A552_4987_327_1_6B7134B31289DC4FAF731D844122B36E0BFDC80F@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <0f30c8a6-d039-c2b5-da88-909428ed9f57@trigofacile.com> Date: Mon, 9 Jan 2017 22:14:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <4987_1483973970_5873A552_4987_327_1_6B7134B31289DC4FAF731D844122B36E0BFDC80F@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dime] Obsolete TLS wording in Diameter protocol X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:14:12 -0000 Hi Lionel, First of all, thanks for your answer. > The first point on cipher suites has been already raised. The > prohibition of the use of the RC4-based cipher suites (RFC7465) came > after the publication of the RFC6733. But the RFC7465 is anyway an > update of the RFC5246 that is a normative reference in the RFC6733. > So anyone implementing TLS should be aware of this update. There is > no need of an errata report but it will be covered in a future > update of the RFC6733 if any. I agree that TLS implementations are now required to follow the requirement of RFC 7465 "TLS clients MUST NOT include RC4 cipher suites in the ClientHello message", so using TLS with Diameter nodes should normally be safe. However, the consequence is that there is no longer any Diameter-compliant implementations with regards to nodes using TLS. As a matter of fact, without updating RFC 6733 that requires that "diameter nodes MUST be able to negotiate the following TLS/TCP and DTLS/SCTP cipher suites: TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA", that requirement can no longer be fulfilled. So, unfortunately, RFC-compliance for Diameter implementations using TLS no longer exists! As a side note, an erratum could be reported for the wording "the following TLS/TCP and DTLS/SCTP cipher suites" because RC4 does not exist for DTLS. It is specific to TLS according to RFC 4347, Section 4.1.2.2: "The only stream cipher described in TLS 1.1 is RC4, which cannot be randomly accessed. RC4 MUST NOT be used with DTLS." > For the RFC6125, it should be first worthwhile to mention that the > RFC6733 indicates that, for the time being, there is no Diameter > server Certification Authorities. However, the RFC5280 is given as > normative reference and this one is not superseded by RFC6125 so > far. The problem is that RFC 6733 references RFC 5280 only for the Extended Key Usage extension. (And for the time being, there is no CA for authorization.) But there are certificates for authentication and TLS negotiation. It is required by RFC 6733. See Section 13.1: "the Diameter node acting as the TLS/TCP and DTLS/SCTP server MUST request a certificate from the Diameter node acting as TLS/TCP and DTLS/SCTP client, and the Diameter node acting as the TLS/TCP and DTLS/SCTP client MUST be prepared to supply a certificate on request." That's why I suggested that RFC 6733 could reference RFC 5280 (Section 6) and RFC 6125 to make clear how to verify certificates. That's what is for instance done in: https://tools.ietf.org/html/rfc7817 > At least, it is my current understanding. I hope that it clarifies > your concerns. Well, I am not under the impression that all these points are limpid in RFC 6733. And for the first point about TLS, it means that there aren't any RFC-compliant Diameter implementations because a MUST is not fulfilled... -- Julien ÉLIE « Ambo florentes aetatibus, Arcades ambo » (Virgile, _Églogue VII_) From nobody Mon Jan 9 14:28:23 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32C512988F for ; Mon, 9 Jan 2017 14:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 3vkLRenHMzoJ for ; Mon, 9 Jan 2017 14:28:20 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 0187C129888 for ; Mon, 9 Jan 2017 14:28:20 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:57858 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cQiQF-002OLv-3X for dime@ietf.org; Mon, 09 Jan 2017 14:28:19 -0800 To: dime@ietf.org References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> From: Steve Donovan Message-ID: <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com> Date: Mon, 9 Jan 2017 16:28:10 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------4A5959659D215AC794AD3C0B" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] AD evaluation of draft-ietf-dime-load-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:28:21 -0000 This is a multi-part message in MIME format. --------------4A5959659D215AC794AD3C0B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Stephen, Thanks for the review and for the ping. Comments below. Regards, Steve On 1/6/17 10:33 AM, Stephen Farrell wrote: > Just bumping this, post holidays. I believe the > ball is not in my court for this one:-) > > Cheers, > S. > > On 16/12/16 17:38, Stephen Farrell wrote: >> Hiya, >> >> Thanks for getting this stuff progressed. I've done my >> AD evaluation and have a few questions I'd like to ask >> before starting IETF last call. Those are below along >> with some more nitty comments that can be handled now or >> later as the authors/WG prefer. >> >> Cheers, >> S. >> >> Things to chat about before starting IETF LC: >> --------------------------------------------- >> >> (1) Is "server selection" sufficiently clear? Where is >> that defined? I was a bit confused as to what this means >> that is not next-hop selection. SRD> Server selection is touched on in RFC7638 (DOIC) and the concept carries over to Load. It refers to selection of the specific server instance that will be handling the request. This is according to the Diameter Client, Server model. I think it is well understood what is meant by those who understand Diameter and would be implementing this spec. We can, if needed, add some definition. That would have been best do be in the DOIC RFC but it can go here if needed. >> >> (2) PEER reports that are first received at a >> non-supporting node will be left in place and will reach >> the destination of the message. If that destination is in a >> different domain then that leaks some internal structure >> (the SourceID) to outsiders. Is that desirable? Why not >> have the first node that does support this AVP delete the >> PEER report even if the node that added the PEER report is >> not a peer of this node? (Note: I see this risk is ack'd >> in section 8, I'm asking if we can avoid it almost >> entirely by removing PEER reports that are useless.) SRD> There is no formal mechanism in place in Diameter to do "topology hiding". There are many other places where topology information can leak, so it isn't an issue specific to Load. It is addressed today through proprietary implementations. SRD> Having a node that does not support would go against the Diameter extensibility strategy. Nodes that don't understand an AVP are required to pass it on. Nodes that do support the mechanism and see a Load report of type peer that isn't of type peer are supposed to remove it. Doing anything other than this would require a change to the base Diameter specification. >> >> (3) This spec is a bit like RFC7944 (DRMP) in that it >> defines some but not all of the things one needs to end up >> with a workable system. That aspect of DRMP caused some >> discussion during IESG evaluation. Have the authors of >> this reviewed that discussion to see if we can avoid any >> likely iterations being needed at that point? I'm hoping >> that Steve, as an author of both, won't find this too >> hard to do:-) If that's been done, great. If not, please >> consider if there's any additional explanatory material >> that could be added that might help us not to have to >> iterate to discuss the same kinds of concern. SRD> I'll go back and review that discussion and see if there is something that needs to be added. I'm hoping that the fact that we made it through the discussion with DRMP will make it easier to do so with Load (and maybe agent overload). I'm doubtful that we can fully inoculate the draft from some of this level of discussion as we are dealing with Diameter here. >> >> nits (fine to be considered last call comments): >> ------------------------------------------------- SRD> I'll deal with these as part of last call. >> >> abstract: maybe put the 1st sentence last? that might read >> better >> >> 4.1: the "opinion of the authors" isn't really of interest >> at this point - is this also the opinion of the WG? (I >> assume it is) >> >> section 5 says "The load report includes a value >> indicating the load of the sending node relative load of >> the sending node, specified in a manner consistent with >> that defined for DNS SRV [RFC2782]." I can't parse that. >> >> - 6.2: What is a Diameter "connection?" I thought that >> Diameter could use UDP as well as TCP so is that really >> the right term? Maybe "message sender" is a better way to >> identify the peer? >> >> - section 8: "might require a transitive trust model" is >> far too coy IMO. I think you should say that DOIC and this >> entirely require transitive trust because we have no >> Diameter mechanism that allows authenticated adding and >> removal of AVPs as messages transit a network. (We did try >> develop that ages ago but it was too complex, so I'm not >> arguing to try again, just that we clearly ack the fact >> that this stuff requires transitive trust.) >> >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------4A5959659D215AC794AD3C0B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Stephen,

Thanks for the review and for the ping.  Comments below.

Regards,

Steve

On 1/6/17 10:33 AM, Stephen Farrell wrote:
Just bumping this, post holidays. I believe the
ball is not in my court for this one:-)

Cheers,
S.

On 16/12/16 17:38, Stephen Farrell wrote:

Hiya,

Thanks for getting this stuff progressed. I've done my
AD evaluation and have a few questions I'd like to ask
before starting IETF last call. Those are below along
with some more nitty comments that can be handled now or
later as the authors/WG prefer.

Cheers,
S.

Things to chat about before starting IETF LC:
---------------------------------------------

(1) Is "server selection" sufficiently clear? Where is
that defined? I was a bit confused as to what this means
that is not next-hop selection.
SRD> Server selection is touched on in RFC7638 (DOIC) and the concept carries over to Load.  It refers to selection of the specific server instance that will be handling the request.  This is according to the Diameter Client, Server model.  I think it is well understood what is meant by those who understand Diameter and would be implementing this spec.  We can, if needed, add some definition.  That would have been best do be in the DOIC RFC but it can go here if needed.

(2) PEER reports that are first received at a
non-supporting node will be left in place and will reach
the destination of the message. If that destination is in a
different domain then that leaks some internal structure
(the SourceID) to outsiders. Is that desirable?  Why not
have the first node that does support this AVP delete the
PEER report even if the node that added the PEER report is
not a peer of this node? (Note: I see this risk is ack'd
in section 8, I'm asking if we can avoid it almost
entirely by removing PEER reports that are useless.)
SRD> There is no formal mechanism in place in Diameter to do "topology hiding".  There are many other places where topology information can leak, so it isn't an issue specific to Load.  It is addressed today through proprietary implementations.

SRD> Having a node that does not support would go against the Diameter extensibility strategy.  Nodes that don't understand an AVP are required to pass it on.  Nodes that do support the mechanism and see a Load report of type peer that isn't of type peer are supposed to remove it.  Doing anything other than this would require a change to the base Diameter specification.

(3) This spec is a bit like RFC7944 (DRMP) in that it
defines some but not all of the things one needs to end up
with a workable system. That aspect of DRMP caused some
discussion during IESG evaluation. Have the authors of
this reviewed that discussion to see if we can avoid any
likely iterations being needed at that point? I'm hoping
that Steve, as an author of both, won't find this too
hard to do:-) If that's been done, great. If not, please
consider if there's any additional explanatory material
that could be added that might help us not to have to
iterate to discuss the same kinds of concern.
SRD> I'll go back and review that discussion and see if there is something that needs to be added.  I'm hoping that the fact that we made it through the discussion with DRMP will make it easier to do so with Load (and maybe agent overload).  I'm doubtful that we can fully inoculate the draft from some of this level of discussion as we are dealing with Diameter here.

nits (fine to be considered last call comments):
-------------------------------------------------
SRD> I'll deal with these as part of last call.

abstract: maybe put the 1st sentence last? that might read
better

4.1: the "opinion of the authors" isn't really of interest
at this point - is this also the opinion of the WG? (I
assume it is)

section 5 says "The load report includes a value
indicating the load of the sending node relative load of
the sending node, specified in a manner consistent with
that defined for DNS SRV [RFC2782]." I can't parse that.

- 6.2: What is a Diameter "connection?" I thought that
Diameter could use UDP as well as TCP so is that really
the right term? Maybe "message sender" is a better way to
identify the peer?

- section 8: "might require a transitive trust model" is
far too coy IMO. I think you should say that DOIC and this
entirely require transitive trust because we have no
Diameter mechanism that allows authenticated adding and
removal of AVPs as messages transit a network. (We did try
develop that ages ago but it was too complex, so I'm not
arguing to try again, just that we clearly ack the fact
that this stuff requires transitive trust.)




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



      

      

      

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


    

    

  


--------------4A5959659D215AC794AD3C0B--


From nobody Wed Jan 11 10:16:35 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C00129793 for ; Wed, 11 Jan 2017 10:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 rhtzjBzbt1VK for ; Wed, 11 Jan 2017 10:16:33 -0800 (PST)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7A51296EF for ; Wed, 11 Jan 2017 10:16:33 -0800 (PST)
Received: by mail-pg0-x22a.google.com with SMTP id 14so38777275pgg.1 for ; Wed, 11 Jan 2017 10:16:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=8l4YJvS5Y1qOOZcbSxtEL1v7ubvL/e9zkoRjwUFGORE=; b=VkB/FDRGjHBXtkgFL0cw9Z75Ib58FTr3abSp3YH/KsGlRia9sTY9yMcjPDl50mrLPB jVtjgaA5WXm//uP1Vzb4rUbDLdSW+XTy9mLTQSVKBzf4M1RYb/wsviX7AznxlnMmQ8H2 57GVX1YiHxCiBwb6Edn7T8HreE9cP5orSUD85RS9dGSs6qYUvZ9H/4IiigO2Y1ORrDgx oZ9gFH5Z5IQ4E810dsh3pflu3c7st4TCFpYOhKBG1aiCsX3qE9uvtiB3F9JFrimxf61N 76CL4z1tGLp4tqPeUECoAKQe9fyae5o7E4tzSIhMBWWig+WtEYF5KD/Hy4C1gBs9C4GT G4iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=8l4YJvS5Y1qOOZcbSxtEL1v7ubvL/e9zkoRjwUFGORE=; b=Cg+hUNhmgpLawPUEwYG5etP0QUq4gVC6X4d059xnDKeajmeIYxGQIonJ2LhoDBpeBu uEX/v7molCA3hH7aagDKK5LTZxEul27yRX0SWe0CMgWX6hko7hnNLb2aFVEkKXUBYShi YUNJUsqHYmYjFzvpi883+wVx3nX1PX4l06CXmK+EkhLEKxVWA/HQIKtl4tCJwoVT+n9w 88KWo5WG0BMHa2ybEP9VVJ0CCo3uafyvM54jfFZ3q+005OV8QpcggSLvuSljfg4Iu+E6 5wmHvyxVdVKZgp1IG/nkqI+QEiMeEkUqgSwTOalZkjbfVE6vMov5dp8liukaqEulxXxX 938A==
X-Gm-Message-State: AIkVDXIqorkn9su8qumYzFFqxn5qkQADuVvDy6Ofdk9LE/IiEWMWzr4C6s2TAtasIbwXfQ==
X-Received: by 10.98.16.7 with SMTP id y7mr11715747pfi.55.1484158592516; Wed, 11 Jan 2017 10:16:32 -0800 (PST)
Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id g70sm11428196pfb.50.2017.01.11.10.16.31 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 10:16:31 -0800 (PST)
From: "jouni.nospam" 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 11 Jan 2017 10:16:31 -0800
References: 
To: dime@ietf.org
In-Reply-To: 
Message-Id: <9A75B441-2FE2-4691-A7C1-A785B5816F5A@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: Re: [Dime] WGLC #2 for draft-ietf-dime-doic-rate-control-04
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Jan 2017 18:16:34 -0000

Folks,

The WGLC #2 concluded a while ago. According to my book keeping the =
draft received no comments and no reviews.

Either the draft is so good that it leaves everybody speechless or then =
no one bothered to read the draft. Anyway, I am going to run one WGLCs =
until I receive a serious indication/response that someone (other than =
me) reviewed the draft and also checked the dependencies with other load =
related documents.

The announcement for the WGLC #3 is coming soon in another mail.

- Jouni


> On Dec 12, 2016, at 9:02 AM, jouni.nospam  =
wrote:
>=20
> Folks,
>=20
> This mail starts the WGLC #2 for draft-ietf-dime-doic-rate-control-04.
> The WGLC ends next Monday 19/12/2016 EOB (PDT).
>=20
> Please, read & review the draft, provide your support or opposition =
and/or comments to the list.
>=20
> Regards,
> 	Jouni


From nobody Thu Jan 12 03:54:16 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB9A1293DC for ; Thu, 12 Jan 2017 03:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.5
X-Spam-Level: 
X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ybLlZ7ESxiH for ; Thu, 12 Jan 2017 03:54:12 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A361279EB for ; Thu, 12 Jan 2017 03:54:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3DA5DBE4C; Thu, 12 Jan 2017 11:54:08 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQzm5E2Ntzbm; Thu, 12 Jan 2017 11:54:04 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D987BE49; Thu, 12 Jan 2017 11:54:03 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484222044; bh=D4KHV1tmLPLHuqiSyit1eQxpAtd6BIPIEJcyifnFC4M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=h5qKc3Sn5GO7I0+miR3yHNfbJ7jQUjL2lSRIlZwSJnd0UIKEU5SNYqQUwPVcUVcq+ DEFckX/pZwTHI7PBGZTT4I090iT1i9J4DVa3QOmYaffaC07pK3LdvF4frlZTxEH/fT Y1pl9PV/1R4hmGjFZoGq5tNO6EG1hvFj907RgU20=
To: Steve Donovan , dime@ietf.org
References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <86f38e04-292f-2463-95ac-a25bad4a51e6@cs.tcd.ie>
Date: Thu, 12 Jan 2017 11:54:02 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070803010904000501060303"
Archived-At: 
Subject: Re: [Dime] AD evaluation of draft-ietf-dime-load-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jan 2017 11:54:14 -0000

This is a cryptographically signed message in MIME format.

--------------ms070803010904000501060303
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

Just one thing below I'd like to figure out before
IETF LC...

On 09/01/17 22:28, Steve Donovan wrote:
> Stephen,
>=20
> Thanks for the review and for the ping.  Comments below.
>=20
> Regards,
>=20
> Steve
>=20
> On 1/6/17 10:33 AM, Stephen Farrell wrote:
>> Just bumping this, post holidays. I believe the
>> ball is not in my court for this one:-)
>>
>> Cheers,
>> S.
>>
>> On 16/12/16 17:38, Stephen Farrell wrote:
>>> Hiya,
>>>
>>> Thanks for getting this stuff progressed. I've done my
>>> AD evaluation and have a few questions I'd like to ask
>>> before starting IETF last call. Those are below along
>>> with some more nitty comments that can be handled now or
>>> later as the authors/WG prefer.
>>>
>>> Cheers,
>>> S.
>>>
>>> Things to chat about before starting IETF LC:
>>> ---------------------------------------------
>>>
>>> (1) Is "server selection" sufficiently clear? Where is
>>> that defined? I was a bit confused as to what this means
>>> that is not next-hop selection.
> SRD> Server selection is touched on in RFC7638 (DOIC) and the concept
> carries over to Load.  It refers to selection of the specific server
> instance that will be handling the request.  This is according to the
> Diameter Client, Server model.  I think it is well understood what is
> meant by those who understand Diameter and would be implementing this
> spec.  We can, if needed, add some definition. That would have been bes=
t
> do be in the DOIC RFC but it can go here if needed.

Ok, let's handle that as an IETF LC comment. If others
think a definition would be good you can add it later.
If it's just me, don't bother.

>>>
>>> (2) PEER reports that are first received at a
>>> non-supporting node will be left in place and will reach
>>> the destination of the message. If that destination is in a
>>> different domain then that leaks some internal structure
>>> (the SourceID) to outsiders. Is that desirable?  Why not
>>> have the first node that does support this AVP delete the
>>> PEER report even if the node that added the PEER report is
>>> not a peer of this node? (Note: I see this risk is ack'd
>>> in section 8, I'm asking if we can avoid it almost
>>> entirely by removing PEER reports that are useless.)
> SRD> There is no formal mechanism in place in Diameter to do "topology
> hiding".  There are many other places where topology information can
> leak, so it isn't an issue specific to Load.  It is addressed today
> through proprietary implementations.

Sure, that's not a good reason to make it harder though.
But see below...

>=20
> SRD> Having a node that does not support would go against the Diameter
> extensibility strategy.  Nodes that don't understand an AVP are require=
d
> to pass it on.  Nodes that do support the mechanism and see a Load
> report of type peer that isn't of type peer are supposed to remove it.

I don't understand what " a Load report of type peer that
isn't of type peer" can mean.

> Doing anything other than this would require a change to the base
> Diameter specification.

Either I'm mis-remembering the draft or we're talking at
cross purposes. My reading was that nodes that do support
the mechanism could delete a peer report that actually
comes via a node that does not support the mechanism. Am
I wrong? If so maybe there's a clarity issue. If not, I
don't see why that makes sense.

Cheers,
S.

PS: The rest below is fine to handle later as you suggest.

>>>
>>> (3) This spec is a bit like RFC7944 (DRMP) in that it
>>> defines some but not all of the things one needs to end up
>>> with a workable system. That aspect of DRMP caused some
>>> discussion during IESG evaluation. Have the authors of
>>> this reviewed that discussion to see if we can avoid any
>>> likely iterations being needed at that point? I'm hoping
>>> that Steve, as an author of both, won't find this too
>>> hard to do:-) If that's been done, great. If not, please
>>> consider if there's any additional explanatory material
>>> that could be added that might help us not to have to
>>> iterate to discuss the same kinds of concern.
> SRD> I'll go back and review that discussion and see if there is
> something that needs to be added.  I'm hoping that the fact that we mad=
e
> it through the discussion with DRMP will make it easier to do so with
> Load (and maybe agent overload).  I'm doubtful that we can fully
> inoculate the draft from some of this level of discussion as we are
> dealing with Diameter here.
>>>
>>> nits (fine to be considered last call comments):
>>> -------------------------------------------------
> SRD> I'll deal with these as part of last call.
>>>
>>> abstract: maybe put the 1st sentence last? that might read
>>> better
>>>
>>> 4.1: the "opinion of the authors" isn't really of interest
>>> at this point - is this also the opinion of the WG? (I
>>> assume it is)
>>>
>>> section 5 says "The load report includes a value
>>> indicating the load of the sending node relative load of
>>> the sending node, specified in a manner consistent with
>>> that defined for DNS SRV [RFC2782]." I can't parse that.
>>>
>>> - 6.2: What is a Diameter "connection?" I thought that
>>> Diameter could use UDP as well as TCP so is that really
>>> the right term? Maybe "message sender" is a better way to
>>> identify the peer?
>>>
>>> - section 8: "might require a transitive trust model" is
>>> far too coy IMO. I think you should say that DOIC and this
>>> entirely require transitive trust because we have no
>>> Diameter mechanism that allows authenticated adding and
>>> removal of AVPs as messages transit a network. (We did try
>>> develop that ages ago but it was too complex, so I'm not
>>> arguing to try again, just that we clearly ack the fact
>>> that this stuff requires transitive trust.)
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
>=20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20


--------------ms070803010904000501060303
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMTIx
MTU0MDJaMC8GCSqGSIb3DQEJBDEiBCCBULxFlokw4Z/AUJoAXiG1LrBrVkNKAtYOu2b3jrDE
NzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQAk4jaz2C0mMLOcT3BHfJ83BYLNsG5qoO1fPLwRSh6I2kmtZ3qqkk5O
URcXGmnzQxcdyeEPLAY9d1Dmuk1nsHn9sH8wUIxD60bv9rQrV0b7b+8eba25ukBInNNZ2BOl
/PxMVbJQOjpN13mAPJWIM8IUG0nnHHKcSQ3RVvfzBq3kLviCdRRwxdo2yeGKXfafymqB4O17
HanpvpqoEXbBLCyTKtStAbluhHB/+1aLSEciNxYnqXJhfSK7mJU9hX4ZDsQx6sIvYFi5przF
HBGouEb8/cSM3L9D6Xb+3ediG6DQ/fuJX2OaOIf9zLvFk8+3tr7HD/cKPHFzOjQWyGqbsnkk
AAAAAAAA
--------------ms070803010904000501060303--


From nobody Thu Jan 12 07:34:19 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3545C12949A for ; Thu, 12 Jan 2017 07:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 ssrwQAzA_Lss for ; Thu, 12 Jan 2017 07:34:15 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 D59C4129468 for ; Thu, 12 Jan 2017 07:34:15 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:58813 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cRhOE-0007YZ-IU; Thu, 12 Jan 2017 07:34:15 -0800
To: Stephen Farrell , dime@ietf.org
References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com> <86f38e04-292f-2463-95ac-a25bad4a51e6@cs.tcd.ie>
From: Steve Donovan 
Message-ID: <4539dd06-54bb-8b4f-a597-c4846349728f@usdonovans.com>
Date: Thu, 12 Jan 2017 09:34:09 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <86f38e04-292f-2463-95ac-a25bad4a51e6@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [Dime] AD evaluation of draft-ietf-dime-load-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jan 2017 15:34:17 -0000

Stephen,

I think that what you are proposing is for the following network:

A' ---- B' ----- C ----- D --|-- E'
                                               ^
                                 Administrative boundary

Where A', B' and E' support load and C and D do not.

I think you are proposing that node D strips a peer load report inserted 
by B'.  Is this correct?

The issue is that this is load-specific functionality, requiring D to 
understand at least some of the Load mechanism.  But, by definition,  D 
does not support or understand anything about the load mechanism.

I don't see a way of achieving what you propose without adding load 
specific functionality to D.

Steve

On 1/12/17 5:54 AM, Stephen Farrell wrote:
> Hiya,
>
> Just one thing below I'd like to figure out before
> IETF LC...
>
> On 09/01/17 22:28, Steve Donovan wrote:
>> Stephen,
>>
>> Thanks for the review and for the ping.  Comments below.
>>
>> Regards,
>>
>> Steve
>>
>> On 1/6/17 10:33 AM, Stephen Farrell wrote:
>>> Just bumping this, post holidays. I believe the
>>> ball is not in my court for this one:-)
>>>
>>> Cheers,
>>> S.
>>>
>>> On 16/12/16 17:38, Stephen Farrell wrote:
>>>> Hiya,
>>>>
>>>> Thanks for getting this stuff progressed. I've done my
>>>> AD evaluation and have a few questions I'd like to ask
>>>> before starting IETF last call. Those are below along
>>>> with some more nitty comments that can be handled now or
>>>> later as the authors/WG prefer.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> Things to chat about before starting IETF LC:
>>>> ---------------------------------------------
>>>>
>>>> (1) Is "server selection" sufficiently clear? Where is
>>>> that defined? I was a bit confused as to what this means
>>>> that is not next-hop selection.
>> SRD> Server selection is touched on in RFC7638 (DOIC) and the concept
>> carries over to Load.  It refers to selection of the specific server
>> instance that will be handling the request.  This is according to the
>> Diameter Client, Server model.  I think it is well understood what is
>> meant by those who understand Diameter and would be implementing this
>> spec.  We can, if needed, add some definition. That would have been best
>> do be in the DOIC RFC but it can go here if needed.
> Ok, let's handle that as an IETF LC comment. If others
> think a definition would be good you can add it later.
> If it's just me, don't bother.
>
>>>> (2) PEER reports that are first received at a
>>>> non-supporting node will be left in place and will reach
>>>> the destination of the message. If that destination is in a
>>>> different domain then that leaks some internal structure
>>>> (the SourceID) to outsiders. Is that desirable?  Why not
>>>> have the first node that does support this AVP delete the
>>>> PEER report even if the node that added the PEER report is
>>>> not a peer of this node? (Note: I see this risk is ack'd
>>>> in section 8, I'm asking if we can avoid it almost
>>>> entirely by removing PEER reports that are useless.)
>> SRD> There is no formal mechanism in place in Diameter to do "topology
>> hiding".  There are many other places where topology information can
>> leak, so it isn't an issue specific to Load.  It is addressed today
>> through proprietary implementations.
> Sure, that's not a good reason to make it harder though.
> But see below...
>
>> SRD> Having a node that does not support would go against the Diameter
>> extensibility strategy.  Nodes that don't understand an AVP are required
>> to pass it on.  Nodes that do support the mechanism and see a Load
>> report of type peer that isn't of type peer are supposed to remove it.
> I don't understand what " a Load report of type peer that
> isn't of type peer" can mean.
>
>> Doing anything other than this would require a change to the base
>> Diameter specification.
> Either I'm mis-remembering the draft or we're talking at
> cross purposes. My reading was that nodes that do support
> the mechanism could delete a peer report that actually
> comes via a node that does not support the mechanism. Am
> I wrong? If so maybe there's a clarity issue. If not, I
> don't see why that makes sense.
>
> Cheers,
> S.
>
> PS: The rest below is fine to handle later as you suggest.
>
>>>> (3) This spec is a bit like RFC7944 (DRMP) in that it
>>>> defines some but not all of the things one needs to end up
>>>> with a workable system. That aspect of DRMP caused some
>>>> discussion during IESG evaluation. Have the authors of
>>>> this reviewed that discussion to see if we can avoid any
>>>> likely iterations being needed at that point? I'm hoping
>>>> that Steve, as an author of both, won't find this too
>>>> hard to do:-) If that's been done, great. If not, please
>>>> consider if there's any additional explanatory material
>>>> that could be added that might help us not to have to
>>>> iterate to discuss the same kinds of concern.
>> SRD> I'll go back and review that discussion and see if there is
>> something that needs to be added.  I'm hoping that the fact that we made
>> it through the discussion with DRMP will make it easier to do so with
>> Load (and maybe agent overload).  I'm doubtful that we can fully
>> inoculate the draft from some of this level of discussion as we are
>> dealing with Diameter here.
>>>> nits (fine to be considered last call comments):
>>>> -------------------------------------------------
>> SRD> I'll deal with these as part of last call.
>>>> abstract: maybe put the 1st sentence last? that might read
>>>> better
>>>>
>>>> 4.1: the "opinion of the authors" isn't really of interest
>>>> at this point - is this also the opinion of the WG? (I
>>>> assume it is)
>>>>
>>>> section 5 says "The load report includes a value
>>>> indicating the load of the sending node relative load of
>>>> the sending node, specified in a manner consistent with
>>>> that defined for DNS SRV [RFC2782]." I can't parse that.
>>>>
>>>> - 6.2: What is a Diameter "connection?" I thought that
>>>> Diameter could use UDP as well as TCP so is that really
>>>> the right term? Maybe "message sender" is a better way to
>>>> identify the peer?
>>>>
>>>> - section 8: "might require a transitive trust model" is
>>>> far too coy IMO. I think you should say that DOIC and this
>>>> entirely require transitive trust because we have no
>>>> Diameter mechanism that allows authenticated adding and
>>>> removal of AVPs as messages transit a network. (We did try
>>>> develop that ages ago but it was too complex, so I'm not
>>>> arguing to try again, just that we clearly ack the fact
>>>> that this stuff requires transitive trust.)
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>


From nobody Thu Jan 12 09:16:42 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39985128BA2 for ; Thu, 12 Jan 2017 09:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 BoV2jgERGXpq for ; Thu, 12 Jan 2017 09:16:35 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 5201F1294F5 for ; Thu, 12 Jan 2017 09:16:35 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:59494 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cRizE-001bHa-Tz; Thu, 12 Jan 2017 09:16:35 -0800
To: Misha Zaytsev , "dime@ietf.org" 
References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com> 
From: Steve Donovan 
Message-ID: <6c28f017-612e-3a17-8e23-5b4626d0f341@usdonovans.com>
Date: Thu, 12 Jan 2017 11:16:28 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------066A52F42180502C479FFCDA"
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [Dime] AD evaluation of draft-ietf-dime-load-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jan 2017 17:16:37 -0000

This is a multi-part message in MIME format.
--------------066A52F42180502C479FFCDA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Misha,

I've added the DIME WG mailing list.

See my comments inline.

Regars,

Steve

On 1/11/17 12:03 PM, Misha Zaytsev wrote:
> Hi Steve,
>
> I'm a newcomer in DiME working group - so, may not be familiar with 
> all rules.
> So, excuse me in advance if it is not a good manner to comment the 
> ongoing draft review.
SRD> Welcome to the working group!
>
> But let me still put my 5 cents here.
>
> Regarding this question from Stephen:
>
> - 6.2: What is a Diameter "connection?" I thought that
> Diameter could use UDP as well as TCP so is that really
> the right term? Maybe "message sender" is a better way to
> identify the peer?
>
> Why can't we re-phrase the related statement in the following way?
>
> This is achieved by comparing Origin-Host AVP with SourceID AVP in the Load report.
>
SRD> This actually doesn't work for the peer report case.  The 
Origin-Host AVP is inserted by the Diameter client and it remains the 
same as the request passes through Diameter agents.  For peer reports, 
it is necessary to know the peer that sent the request, not the client.  
Thus the need to look at the DiameterID associated with the Diameter 
connection.

> Also if it does not bother you, could you explain what is the official 
> way to comment DiME drafts?
SRD> The official way is to do exactly what you are doing, but by 
sending the questions and comments to the DIME WG mailing list.
>
> Thanks a lot in advance!
>
> /Misha
>
>
>
> 2017-01-10 1:28 GMT+03:00 Steve Donovan  >:
>
>     Stephen,
>
>     Thanks for the review and for the ping.  Comments below.
>
>     Regards,
>
>     Steve
>
>     On 1/6/17 10:33 AM, Stephen Farrell wrote:
>>     Just bumping this, post holidays. I believe the
>>     ball is not in my court for this one:-)
>>
>>     Cheers,
>>     S.
>>
>>     On 16/12/16 17:38, Stephen Farrell wrote:
>>>     Hiya,
>>>
>>>     Thanks for getting this stuff progressed. I've done my
>>>     AD evaluation and have a few questions I'd like to ask
>>>     before starting IETF last call. Those are below along
>>>     with some more nitty comments that can be handled now or
>>>     later as the authors/WG prefer.
>>>
>>>     Cheers,
>>>     S.
>>>
>>>     Things to chat about before starting IETF LC:
>>>     ---------------------------------------------
>>>
>>>     (1) Is "server selection" sufficiently clear? Where is
>>>     that defined? I was a bit confused as to what this means
>>>     that is not next-hop selection.
>     SRD> Server selection is touched on in RFC7638 (DOIC) and the
>     concept carries over to Load.  It refers to selection of the
>     specific server instance that will be handling the request.  This
>     is according to the Diameter Client, Server model.  I think it is
>     well understood what is meant by those who understand Diameter and
>     would be implementing this spec.  We can, if needed, add some
>     definition. That would have been best do be in the DOIC RFC but it
>     can go here if needed.
>>>     (2) PEER reports that are first received at a
>>>     non-supporting node will be left in place and will reach
>>>     the destination of the message. If that destination is in a
>>>     different domain then that leaks some internal structure
>>>     (the SourceID) to outsiders. Is that desirable?  Why not
>>>     have the first node that does support this AVP delete the
>>>     PEER report even if the node that added the PEER report is
>>>     not a peer of this node? (Note: I see this risk is ack'd
>>>     in section 8, I'm asking if we can avoid it almost
>>>     entirely by removing PEER reports that are useless.)
>     SRD> There is no formal mechanism in place in Diameter to do
>     "topology hiding".  There are many other places where topology
>     information can leak, so it isn't an issue specific to Load.  It
>     is addressed today through proprietary implementations. SRD>
>     Having a node that does not support would go against the Diameter
>     extensibility strategy.  Nodes that don't understand an AVP are
>     required to pass it on.  Nodes that do support the mechanism and
>     see a Load report of type peer that isn't of type peer are
>     supposed to remove it.  Doing anything other than this would
>     require a change to the base Diameter specification.
>>>     (3) This spec is a bit like RFC7944 (DRMP) in that it
>>>     defines some but not all of the things one needs to end up
>>>     with a workable system. That aspect of DRMP caused some
>>>     discussion during IESG evaluation. Have the authors of
>>>     this reviewed that discussion to see if we can avoid any
>>>     likely iterations being needed at that point? I'm hoping
>>>     that Steve, as an author of both, won't find this too
>>>     hard to do:-) If that's been done, great. If not, please
>>>     consider if there's any additional explanatory material
>>>     that could be added that might help us not to have to
>>>     iterate to discuss the same kinds of concern.
>     SRD> I'll go back and review that discussion and see if there is
>     something that needs to be added.  I'm hoping that the fact that
>     we made it through the discussion with DRMP will make it easier to
>     do so with Load (and maybe agent overload).  I'm doubtful that we
>     can fully inoculate the draft from some of this level of
>     discussion as we are dealing with Diameter here.
>>>     nits (fine to be considered last call comments):
>>>     -------------------------------------------------
>     SRD> I'll deal with these as part of last call.
>>>     abstract: maybe put the 1st sentence last? that might read
>>>     better
>>>
>>>     4.1: the "opinion of the authors" isn't really of interest
>>>     at this point - is this also the opinion of the WG? (I
>>>     assume it is)
>>>
>>>     section 5 says "The load report includes a value
>>>     indicating the load of the sending node relative load of
>>>     the sending node, specified in a manner consistent with
>>>     that defined for DNS SRV [RFC2782]." I can't parse that.
>>>
>>>     - 6.2: What is a Diameter "connection?" I thought that
>>>     Diameter could use UDP as well as TCP so is that really
>>>     the right term? Maybe "message sender" is a better way to
>>>     identify the peer?
>>>
>>>     - section 8: "might require a transitive trust model" is
>>>     far too coy IMO. I think you should say that DOIC and this
>>>     entirely require transitive trust because we have no
>>>     Diameter mechanism that allows authenticated adding and
>>>     removal of AVPs as messages transit a network. (We did try
>>>     develop that ages ago but it was too complex, so I'm not
>>>     arguing to try again, just that we clearly ack the fact
>>>     that this stuff requires transitive trust.)
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     DiME mailing list
>>>     DiME@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/dime
>>>     
>>>
>>     _______________________________________________
>>     DiME mailing list
>>     DiME@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/dime
>>     
>     _______________________________________________ DiME mailing list
>     DiME@ietf.org 
>     https://www.ietf.org/mailman/listinfo/dime
>      
>

--------------066A52F42180502C479FFCDA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Misha,

    

    I've added the DIME WG mailing list.

    

    See my comments inline.

    

    Regars,

    

    Steve

    

    
On 1/11/17 12:03 PM, Misha Zaytsev
      wrote:

    

    

      
Hi Steve,
        


        

        
I'm a newcomer in DiME working group - so, may not be
          familiar with all rules.

        
So, excuse me in advance if it is not a good manner to
          comment the ongoing draft review.

      

    

    SRD> Welcome to the working group!

    

      

        


        

        
But let me still put my 5 cents here.

        


        

        
Regarding this question from Stephen:

        


        

        
- 6.2: What is a Diameter
            "connection?" I thought that

          Diameter could use UDP as well
            as TCP so is that really

          the right term? Maybe "message
            sender" is a better way to

          identify the peer?

        

        


          

        
Why can't we re-phrase the
            related statement in the following way?

        


          

        

          
This is achieved by comparing Origin-Host AVP with SourceID AVP in the Load report.

        

        


        

      

    

    SRD> This actually doesn't work for the peer report case.  The
    Origin-Host AVP is inserted by the Diameter client and it remains
    the same as the request passes through Diameter agents.  For peer
    reports, it is necessary to know the peer that sent the request, not
    the client.  Thus the need to look at the DiameterID associated with
    the Diameter connection.

    

    

      

        
Also if it does not bother you, could
          you explain what is the official way to comment DiME drafts?

      

    

    SRD> The official way is to do exactly what you are doing, but by
    sending the questions and comments to the DIME WG mailing list.

    

      

        


        

        
Thanks a lot in advance!

        


        

        
/Misha

        


        

        


        

        


          
2017-01-10 1:28 GMT+03:00 Steve
            Donovan <srdonovan@usdonovans.com>:

            

              
 Stephen,

                

                Thanks for the review and for the ping.  Comments below.

                

                Regards,

                

                Steve

                  

                  
On
                    1/6/17 10:33 AM, Stephen Farrell wrote:

                  

                  

                    
Just bumping this, post holidays. I believe the
ball is not in my court for this one:-)

Cheers,
S.

On 16/12/16 17:38, Stephen Farrell wrote:


                    

                      
Hiya,

Thanks for getting this stuff progressed. I've done my
AD evaluation and have a few questions I'd like to ask
before starting IETF last call. Those are below along
with some more nitty comments that can be handled now or
later as the authors/WG prefer.

Cheers,
S.

Things to chat about before starting IETF LC:
---------------------------------------------

(1) Is "server selection" sufficiently clear? Where is
that defined? I was a bit confused as to what this means
that is not next-hop selection.

      

    

    SRD> Server selection is touched on in RFC7638 (DOIC) and the
    concept carries over to Load.  It refers to selection of the
    specific server instance that will be handling the request.  This is
    according to the Diameter Client, Server model.  I think it is well
    understood what is meant by those who understand Diameter and would
    be implementing this spec.  We can, if needed, add some definition. 
    That would have been best do be in the DOIC RFC but it can go here
    if needed.

    

      

        
(2) PEER reports that are first received at a
non-supporting node will be left in place and will reach
the destination of the message. If that destination is in a
different domain then that leaks some internal structure
(the SourceID) to outsiders. Is that desirable?  Why not
have the first node that does support this AVP delete the
PEER report even if the node that added the PEER report is
not a peer of this node? (Note: I see this risk is ack'd
in section 8, I'm asking if we can avoid it almost
entirely by removing PEER reports that are useless.)

      

    

    SRD> There is no formal mechanism in place in Diameter to do
    "topology hiding".  There are many other places where topology
    information can leak, so it isn't an issue specific to Load.  It is
    addressed today through proprietary implementations.

    

    SRD> Having a node that does not support would go against the
    Diameter extensibility strategy.  Nodes that don't understand an AVP
    are required to pass it on.  Nodes that do support the mechanism and
    see a Load report of type peer that isn't of type peer are supposed
    to remove it.  Doing anything other than this would require a change
    to the base Diameter specification.

    

      

        
(3) This spec is a bit like RFC7944 (DRMP) in that it
defines some but not all of the things one needs to end up
with a workable system. That aspect of DRMP caused some
discussion during IESG evaluation. Have the authors of
this reviewed that discussion to see if we can avoid any
likely iterations being needed at that point? I'm hoping
that Steve, as an author of both, won't find this too
hard to do:-) If that's been done, great. If not, please
consider if there's any additional explanatory material
that could be added that might help us not to have to
iterate to discuss the same kinds of concern.

      

    

    SRD> I'll go back and review that discussion and see if there is
    something that needs to be added.  I'm hoping that the fact that we
    made it through the discussion with DRMP will make it easier to do
    so with Load (and maybe agent overload).  I'm doubtful that we can
    fully inoculate the draft from some of this level of discussion as
    we are dealing with Diameter here.

    

      

        
nits (fine to be considered last call comments):
-------------------------------------------------

      

    

    SRD> I'll deal with these as part of last call.


    

      

        
abstract: maybe put the 1st sentence last? that might read
better

4.1: the "opinion of the authors" isn't really of interest
at this point - is this also the opinion of the WG? (I
assume it is)

section 5 says "The load report includes a value
indicating the load of the sending node relative load of
the sending node, specified in a manner consistent with
that defined for DNS SRV [RFC2782]." I can't parse that.

- 6.2: What is a Diameter "connection?" I thought that
Diameter could use UDP as well as TCP so is that really
the right term? Maybe "message sender" is a better way to
identify the peer?

- section 8: "might require a transitive trust model" is
far too coy IMO. I think you should say that DOIC and this
entirely require transitive trust because we have no
Diameter mechanism that allows authenticated adding and
removal of AVPs as messages transit a network. (We did try
develop that ages ago but it was too complex, so I'm not
arguing to try again, just that we clearly ack the fact
that this stuff requires transitive trust.)




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



      

      
      

      

      

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


    

    

  



_______________________________________________

DiME mailing list

DiME@ietf.org

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












--------------066A52F42180502C479FFCDA--


From nobody Thu Jan 12 09:51:22 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC1B128E19 for ; Thu, 12 Jan 2017 09:51:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6LQqTqiw6mE for ; Thu, 12 Jan 2017 09:51:18 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E689C1294BF for ; Thu, 12 Jan 2017 09:51:17 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id m78so18862149lfg.2 for ; Thu, 12 Jan 2017 09:51:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fOVrxgJTVa8TwsqEQU6gwyxCY8QvFoV/cGJ9ApqYK8c=; b=g2bPBLl/Wyr7YM8f5TWzltbg8e1B8RLnLDVpLjrH5WMjCpXPFnjxKCxPqK24Makb1/ OrhPyrNoikx74VKWNVicvZganiIh9Qve5piYtFxK/i/4VRqQ3fV6XBfJKRSuFD03S+Ms iridFZj3GQ5Qxfh0vmhxF4vylz/BSoyW0WravTa5x5IOYj9cBREcyWbiMXrZKDCjcFJH ODMxKnAzAXbsUXVSB5EFsk6ljMVtOq4JuRfwyvlP6TDWv/4VW+1PvfHZ44ARZQI47pZ1 yR+/errF+EgUhLCLBKe7m4c225/Yi0ji1BKNrZZ8Zwkdc9DzFwRifFRVe+oSRXy4fVzE l5mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fOVrxgJTVa8TwsqEQU6gwyxCY8QvFoV/cGJ9ApqYK8c=; b=MLbFnVww7kiarEM31H8fzIx/ehb0BzQv5NsVHowKKLIhZuFfBWXtxD05Xdx32BaCCz ybUsJt0U/U8X6M2eB6COM0xWNPorw87ym47bOUa//Rke8DFC7TizVFz9LBYrJnSTQ9mV XV/wYFZM6o+fQK1oDMeudWKVlJ9rvlTq1Xk/cfFtVdsaLT26+jU3rfrmNnyufi9vev8Y UCtY3/r1FyCDeaAsxzfN1WAAIx99JLvqDz21EDM8aklC2ZC/0v4Qvdf6FkHdhAzkU/vP deoaMUNaLJrO7sn1bhW4cx99+k/Hi5/Qf83ykQluPLSR7Rp+63LpkJCZ0R8jqnf933gm BdWA==
X-Gm-Message-State: AIkVDXJVL87YP9BH6KvnZl5ERXMR9RICmyTkLPLShm8/X99gIAFENjDw4+YeUee8aVom+3KlFdM7iywGkCe3Fg==
X-Received: by 10.46.76.1 with SMTP id z1mr1897176lja.48.1484243475438; Thu, 12 Jan 2017 09:51:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Thu, 12 Jan 2017 09:51:14 -0800 (PST)
In-Reply-To: <6c28f017-612e-3a17-8e23-5b4626d0f341@usdonovans.com>
References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com>  <6c28f017-612e-3a17-8e23-5b4626d0f341@usdonovans.com>
From: Misha Zaytsev 
Date: Thu, 12 Jan 2017 20:51:14 +0300
Message-ID: 
To: Steve Donovan 
Content-Type: multipart/alternative; boundary=f403045ea6da1d22db0545e95d60
Archived-At: 
Cc: "dime@ietf.org" 
Subject: Re: [Dime] AD evaluation of draft-ietf-dime-load-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jan 2017 17:51:21 -0000

--f403045ea6da1d22db0545e95d60
Content-Type: text/plain; charset=UTF-8

Hi Steve,

Thanks a lot for your explanation!
My bad that I have not read the draft more carefully - will try to avoid
this next time.

Then I can propose another version of statement that will exclude confusing
"connection" term.

This is achieved by comparing SourceID AVP in the Load report with
host identity field of the entries from peer table defined in RFC6733.


If SourceID AVP contains the identity of one of the peer nodes (that our
node has a direct connection to), then this is what we are looking for,
right?

However, I find the term "connection" legal as it is defined in RFC6733,
for instance section 5.1 "Peer Connections".

Or it can be easily re-phrased in this way, the term "peer" should not
confuse anyone, I guess :)

This is achieved by comparing the DiameterIdentity of the peer from
which the message was received with the
DiameterIdentity included in the SourceID AVP in the Load report.


Btw, what is the due date for providing the comments for this draft?

Best regards,

/Misha

2017-01-12 20:16 GMT+03:00 Steve Donovan :

> Misha,
>
> I've added the DIME WG mailing list.
>
> See my comments inline.
>
> Regars,
>
> Steve
>
> On 1/11/17 12:03 PM, Misha Zaytsev wrote:
>
> Hi Steve,
>
> I'm a newcomer in DiME working group - so, may not be familiar with all
> rules.
> So, excuse me in advance if it is not a good manner to comment the ongoing
> draft review.
>
> SRD> Welcome to the working group!
>
>
> But let me still put my 5 cents here.
>
> Regarding this question from Stephen:
>
> - 6.2: What is a Diameter "connection?" I thought that
> Diameter could use UDP as well as TCP so is that really
> the right term? Maybe "message sender" is a better way to
> identify the peer?
>
> Why can't we re-phrase the related statement in the following way?
>
> This is achieved by comparing Origin-Host AVP with SourceID AVP in the Load report.
>
>
> SRD> This actually doesn't work for the peer report case.  The Origin-Host
> AVP is inserted by the Diameter client and it remains the same as the
> request passes through Diameter agents.  For peer reports, it is necessary
> to know the peer that sent the request, not the client.  Thus the need to
> look at the DiameterID associated with the Diameter connection.
>
> Also if it does not bother you, could you explain what is the official way
> to comment DiME drafts?
>
> SRD> The official way is to do exactly what you are doing, but by sending
> the questions and comments to the DIME WG mailing list.
>
>
> Thanks a lot in advance!
>
> /Misha
>
>
>
> 2017-01-10 1:28 GMT+03:00 Steve Donovan :
>
>> Stephen,
>>
>> Thanks for the review and for the ping.  Comments below.
>>
>> Regards,
>>
>> Steve
>>
>> On 1/6/17 10:33 AM, Stephen Farrell wrote:
>>
>> Just bumping this, post holidays. I believe the
>> ball is not in my court for this one:-)
>>
>> Cheers,
>> S.
>>
>> On 16/12/16 17:38, Stephen Farrell wrote:
>>
>> Hiya,
>>
>> Thanks for getting this stuff progressed. I've done my
>> AD evaluation and have a few questions I'd like to ask
>> before starting IETF last call. Those are below along
>> with some more nitty comments that can be handled now or
>> later as the authors/WG prefer.
>>
>> Cheers,
>> S.
>>
>> Things to chat about before starting IETF LC:
>> ---------------------------------------------
>>
>> (1) Is "server selection" sufficiently clear? Where is
>> that defined? I was a bit confused as to what this means
>> that is not next-hop selection.
>>
>> SRD> Server selection is touched on in RFC7638 (DOIC) and the concept
>> carries over to Load.  It refers to selection of the specific server
>> instance that will be handling the request.  This is according to the
>> Diameter Client, Server model.  I think it is well understood what is meant
>> by those who understand Diameter and would be implementing this spec.  We
>> can, if needed, add some definition.  That would have been best do be in
>> the DOIC RFC but it can go here if needed.
>>
>> (2) PEER reports that are first received at a
>> non-supporting node will be left in place and will reach
>> the destination of the message. If that destination is in a
>> different domain then that leaks some internal structure
>> (the SourceID) to outsiders. Is that desirable?  Why not
>> have the first node that does support this AVP delete the
>> PEER report even if the node that added the PEER report is
>> not a peer of this node? (Note: I see this risk is ack'd
>> in section 8, I'm asking if we can avoid it almost
>> entirely by removing PEER reports that are useless.)
>>
>> SRD> There is no formal mechanism in place in Diameter to do "topology
>> hiding".  There are many other places where topology information can leak,
>> so it isn't an issue specific to Load.  It is addressed today through
>> proprietary implementations. SRD> Having a node that does not support would
>> go against the Diameter extensibility strategy.  Nodes that don't
>> understand an AVP are required to pass it on.  Nodes that do support the
>> mechanism and see a Load report of type peer that isn't of type peer are
>> supposed to remove it.  Doing anything other than this would require a
>> change to the base Diameter specification.
>>
>> (3) This spec is a bit like RFC7944 (DRMP) in that it
>> defines some but not all of the things one needs to end up
>> with a workable system. That aspect of DRMP caused some
>> discussion during IESG evaluation. Have the authors of
>> this reviewed that discussion to see if we can avoid any
>> likely iterations being needed at that point? I'm hoping
>> that Steve, as an author of both, won't find this too
>> hard to do:-) If that's been done, great. If not, please
>> consider if there's any additional explanatory material
>> that could be added that might help us not to have to
>> iterate to discuss the same kinds of concern.
>>
>> SRD> I'll go back and review that discussion and see if there is
>> something that needs to be added.  I'm hoping that the fact that we made it
>> through the discussion with DRMP will make it easier to do so with Load
>> (and maybe agent overload).  I'm doubtful that we can fully inoculate the
>> draft from some of this level of discussion as we are dealing with Diameter
>> here.
>>
>> nits (fine to be considered last call comments):
>> -------------------------------------------------
>>
>> SRD> I'll deal with these as part of last call.
>>
>> abstract: maybe put the 1st sentence last? that might read
>> better
>>
>> 4.1: the "opinion of the authors" isn't really of interest
>> at this point - is this also the opinion of the WG? (I
>> assume it is)
>>
>> section 5 says "The load report includes a value
>> indicating the load of the sending node relative load of
>> the sending node, specified in a manner consistent with
>> that defined for DNS SRV [RFC2782]." I can't parse that.
>>
>> - 6.2: What is a Diameter "connection?" I thought that
>> Diameter could use UDP as well as TCP so is that really
>> the right term? Maybe "message sender" is a better way to
>> identify the peer?
>>
>> - section 8: "might require a transitive trust model" is
>> far too coy IMO. I think you should say that DOIC and this
>> entirely require transitive trust because we have no
>> Diameter mechanism that allows authenticated adding and
>> removal of AVPs as messages transit a network. (We did try
>> develop that ages ago but it was too complex, so I'm not
>> arguing to try again, just that we clearly ack the fact
>> that this stuff requires transitive trust.)
>>
>>
>>
>>
>> _______________________________________________
>> DiME mailing listDiME@ietf.orghttps://www.ietf.org/mailman/listinfo/dime
>>
>> _______________________________________________
>> DiME mailing listDiME@ietf.orghttps://www.ietf.org/mailman/listinfo/dime
>>
>> _______________________________________________ DiME mailing list
>> DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime
>
>

--f403045ea6da1d22db0545e95d60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Steve,

Thanks a l=
ot for your explanation!
My bad that I=
 have not read the draft more carefully - will try to avoid this next time.=


Then I can propose another version of statement that will exclude conf=
using "connection" term.
This is achieved by comparing SourceID AVP in the Load report with=
 host identity field of the entries from peer table defined in RFC6733.

If SourceID AVP contains the identity of one of t=
he peer nodes (that our node has a direct connection to), then this is what=
 we are looking for, right?

=

However, I find the term "connection&q=
uot; legal as it is defined in RFC6733, for instance section 5.1 "Peer=
 Connections".

Or it can be easily re-phrased in this way, the ter=
m "peer" should not confuse anyone, I guess :)

This is achieved by comparing the Diamete=
rIdentity of the peer from which the message was received with the
DiameterIdentity included in the SourceID AVP in the Load report.

Btw, what is the due date for providing the comments for this draft?
=


B=
est regards,

/Misha

2017-01-12 20:16 GMT+03:00 Steve Donovan <srdonov=
an@usdonovans.com>:

 =20
   =20
 =20
  

    Misha,

    

    I've added the DIME WG mailing list.

    

    See my comments inline.

    

    Regars,

    

    Steve

    

    
On 1/11/17 12:03 PM=
, Misha Zaytsev
      wrote:

    

    

      
Hi Steve,
        


        

        
I'm a newcomer in DiME working group - so, may not be
          familiar with all rules.

        
So, excuse me in advance if it is not a good manner to
          comment the ongoing draft review.

      

    

    SRD> Welcome to the working group!

    

      

        


        

        
But let me still put my 5 cents here.

        


        

        
Regarding this question from Stephen:

        


        

        
- 6.2: What is a Diameter
            "connection?" I thought that

          Diameter could use UDP as well
            as TCP so is that really

          the right term? Maybe "mess=
age
            sender" is a better way to

          identify the peer?

        

        


          

        
Why can't we re-phrase th=
e
            related statement in the following way?

        


          

        

          
This is achieved by comparing Origin-H=
ost AVP with SourceID AVP in the Load report.

        

        


        

      

    

    SRD> This actually doesn't work for the peer report case.=C2=A0 =
The
    Origin-Host AVP is inserted by the Diameter client and it remains
    the same as the request passes through Diameter agents.=C2=A0 For peer
    reports, it is necessary to know the peer that sent the request, not
    the client.=C2=A0 Thus the need to look at the DiameterID associated wi=
th
    the Diameter connection.

    

    

      

        
Also if it does not bother you, could
          you explain what is the official way to comment DiME drafts?
      

    

    SRD> The official way is to do exactly what you are doing, but by
    sending the questions and comments to the DIME WG mailing list.


    

      

        


        

        
Thanks a lot in advance!

        


        

        
/Misha

        


        

        


        

        


          
2017-01-10 1:28 GMT+03:00 Steve
            Donovan <srdonovan@usdonovans.com>:

            

              
 Stephen,

                

                Thanks for the review and for the ping.=C2=A0 Comments belo=
w.

                

                Regards,

                

                Steve

                  

                  
On
                    1/6/17 10:33 AM, Stephen Farrell wrote:

                  

                  

                    
Just bumping this, post holidays. I believe the
ball is not in my court for this one:-)

Cheers,
S.

On 16/12/16 17:38, Stephen Farrell wrote:


                    

                      
Hiya,

Thanks for getting this stuff progressed. I've done my
AD evaluation and have a few questions I'd like to ask
before starting IETF last call. Those are below along
with some more nitty comments that can be handled now or
later as the authors/WG prefer.

Cheers,
S.

Things to chat about before starting IETF LC:
---------------------------------------------

(1) Is "server selection" sufficiently clear? Where is
that defined? I was a bit confused as to what this means
that is not next-hop selection.

      

    

    SRD> Server selection is touched on in RFC7638 (DOIC) and the
    concept carries over to Load.=C2=A0 It refers to selection of the
    specific server instance that will be handling the request.=C2=A0 This =
is
    according to the Diameter Client, Server model.=C2=A0 I think it is wel=
l
    understood what is meant by those who understand Diameter and would
    be implementing this spec.=C2=A0 We can, if needed, add some definition=
.=C2=A0
    That would have been best do be in the DOIC RFC but it can go here
    if needed.

    

      

        
(2) PEER reports that are first received at a
non-supporting node will be left in place and will reach
the destination of the message. If that destination is in a
different domain then that leaks some internal structure
(the SourceID) to outsiders. Is that desirable?  Why not
have the first node that does support this AVP delete the
PEER report even if the node that added the PEER report is
not a peer of this node? (Note: I see this risk is ack'd
in section 8, I'm asking if we can avoid it almost
entirely by removing PEER reports that are useless.)

      

    

    SRD> There is no formal mechanism in place in Diameter to do
    "topology hiding".=C2=A0 There are many other places where to=
pology
    information can leak, so it isn't an issue specific to Load.=C2=A0 =
It is
    addressed today through proprietary implementations.

   =20

    SRD> Having a node that does not support would go against the
    Diameter extensibility strategy.=C2=A0 Nodes that don't understand =
an AVP
    are required to pass it on.=C2=A0 Nodes that do support the mechanism a=
nd
    see a Load report of type peer that isn't of type peer are supposed
    to remove it.=C2=A0 Doing anything other than this would require a chan=
ge
    to the base Diameter specification.

    

      

        
(3) This spec is a bit like RFC7944 (DRMP) in that it
defines some but not all of the things one needs to end up
with a workable system. That aspect of DRMP caused some
discussion during IESG evaluation. Have the authors of
this reviewed that discussion to see if we can avoid any
likely iterations being needed at that point? I'm hoping
that Steve, as an author of both, won't find this too
hard to do:-) If that's been done, great. If not, please
consider if there's any additional explanatory material
that could be added that might help us not to have to
iterate to discuss the same kinds of concern.

      

    

    SRD> I'll go back and review that discussion and see if there is
    something that needs to be added.=C2=A0 I'm hoping that the fact th=
at we
    made it through the discussion with DRMP will make it easier to do
    so with Load (and maybe agent overload).=C2=A0 I'm doubtful that we=
 can
    fully inoculate the draft from some of this level of discussion as
    we are dealing with Diameter here.

    

      

        
nits (fine to be considered last call comments):
-------------------------------------------------

      

    

    SRD> I'll deal with these as part of last call.


    

      

        
abstract: maybe put the 1st sentence last? that might read
better

4.1: the "opinion of the authors" isn't really of interest
at this point - is this also the opinion of the WG? (I
assume it is)

section 5 says "The load report includes a value
indicating the load of the sending node relative load of
the sending node, specified in a manner consistent with
that defined for DNS SRV [RFC2782]." I can't parse that.

- 6.2: What is a Diameter "connection?" I thought that
Diameter could use UDP as well as TCP so is that really
the right term? Maybe "message sender" is a better way to
identify the peer?

- section 8: "might require a transitive trust model" is
far too coy IMO. I think you should say that DOIC and this
entirely require transitive trust because we have no
Diameter mechanism that allows authenticated adding and
removal of AVPs as messages transit a network. (We did try
develop that ages ago but it was too complex, so I'm not
arguing to try again, just that we clearly ack the fact
that this stuff requires transitive trust.)




_______________________________________________
DiME mailing list
DiME@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/dime



      

     =20
     =20

      

     =20

      
_______________________________________________
DiME mailing list
DiME@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/dime


    

   =20

  



_______________________________________________

DiME mailing list

DiME@ietf.org

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















--f403045ea6da1d22db0545e95d60--


From nobody Thu Jan 12 10:05:39 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8D4128AB0; Thu, 12 Jan 2017 10:05:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Level: 
X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqBdt7eT5nhS; Thu, 12 Jan 2017 10:05:34 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804D6129421; Thu, 12 Jan 2017 10:05:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34560; q=dns/txt; s=iport; t=1484244333; x=1485453933; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=So2MHZZp8xX4aKQApkCWj/zF96eG5NPBC8W+CpyK8Sk=; b=NE+SoE1/cQo1T30Ko7LK94NgdfyDThl9hxqyuPFAFy0Wt0kzI+EtBz1P Z8bJH78jlOC8YGxuPyAEJV1spfoPPpYtRm2rh2DIXplbj9snImR+sRNQH gVsjYJZx7IQiKwBZmgMN1U+FLH+UQvWgFNVLzyAeTO7lQuD86CD2RU8AW U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQB8xHdY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJyOw8BAQEBAX4DgQaNWHKRIogCixmCD4INKoV4AoJFFAECAQE?= =?us-ascii?q?BAQEBAWMohGkBAQEEJwZMEAsRAwECIQEGByElCQgGAQwGAgEBiGEDGA4tsiU6K?= =?us-ascii?q?4cXDYJJAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZFggIIgVGBBoE7gRM7gQQLEQE?= =?us-ascii?q?8DAqFDx8FiHYRhheBRYRFhUw4jVWEAYF3hQ6DKoY7iBOBfVmDaIQTHzgQYSQSC?= =?us-ascii?q?BUVGIRWDQ+BYD01AROGJIIuAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,219,1477958400";  d="scan'208,217";a="651569988"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 18:05:29 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0CI5ROO003507; Thu, 12 Jan 2017 18:05:27 GMT
To: lionel.morand@orange.com, "aaa-doctors@ietf.org" , "sec-ads@ietf.org" 
References: <20160913214213.4DBFAB80B89@rfc-editor.org> <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> <17526_1483443934_586B8EDE_17526_11792_1_6B7134B31289DC4FAF731D844122B36E0BFC600A@OPEXCLILM43.corporate.adroot.infra.ftgroup>
From: Benoit Claise 
Message-ID: <909d02b4-3f2e-4839-ac0e-7519e5efb8aa@cisco.com>
Date: Thu, 12 Jan 2017 19:05:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <17526_1483443934_586B8EDE_17526_11792_1_6B7134B31289DC4FAF731D844122B36E0BFC600A@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------CC8BC7BF956EE68156085C4C"
Archived-At: 
Cc: "dime@ietf.org" , "holger+ietf@freyther.de" 
Subject: Re: [Dime] [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jan 2017 18:05:38 -0000

This is a multi-part message in MIME format.
--------------CC8BC7BF956EE68156085C4C
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

I would appreciate if others would share their views.

Regards, B.
>
> This errata report is correct on the inconsistency regarding the 
> definition of the command header and AVP header and how they are used 
> in the rest of the document in the ABNF description of commands and 
> Grouped AVPs.
>
> For commands, the header is defined as follow:
>
>    header           = "
>                          [r-bit] [p-bit] [e-bit] [application-id]">"
>
> whereas "
> Same for Grouped AVP. It is defined as follow:
>
>          header           = "<" "AVP-Header:" avpcode [vendor] ">"
>
> whereas "
> Considering that most (if not all) the ABNF descriptions have been 
> copied from the commands and Grouped AVPs defined in the RFC3588 or 
> RFC6733, I would be in favor to correct the specification by modifying 
> the definition of the headers, i.e.
>
> --> In section 3.2.  Command Code Format Specification
>
> OLD:
>
>    header           = "
>                          [r-bit] [p-bit] [e-bit] [application-id]">"
>
> NEW:
>
>    header           = "
>                          [r-bit] [p-bit] [e-bit] [application-id]">"
>
> --> And in section 4.4
>
> OLD:
>
>          header           = "<" "AVP-Header:" avpcode [vendor] ">"
>
> NEW:
>
>          header           = "<" "AVP Header:" avpcode [vendor] ">"
>
> *******************
>
> There are other issues pointed out in this report.
>
> For command-def  = "<" command-name ">" "::=" diameter-message, I 
> would propose to simply correct the example as all the command 
> definitions given in the document are following the command-def 
> definition.
>
> For the grouped-avp-def, I don't know what would be the best approach. 
> We could follow the same approach and require the addition of "<>" but 
> I don't know what would be the impacts on existing Grouped AVPs 
> defined without.
>
> Regards,
>
> Lionel.
>
>
> -------- Forwarded Message --------
>
> *Subject: *
>
> 	
>
> [Editorial Errata Reported] RFC6733 (4803)
>
> *Date: *
>
> 	
>
> Tue, 13 Sep 2016 14:42:13 -0700
>
> *From: *
>
> 	
>
> RFC Errata System  
> 
>
> *To: *
>
> 	
>
> vf0213@gmail.com , jari.arkko@ericsson.com 
> , john.loughney@nokia.com 
> , glenzorn@gmail.com 
> , bclaise@cisco.com 
> , joelja@bogus.com 
> , jouni.nospam@gmail.com 
> , lionel.morand@orange.com 
> 
>
> *CC: *
>
> 	
>
> holger+ietf@freyther.de , 
> dime@ietf.org , rfc-editor@rfc-editor.org 
> 
>
> The following errata report has been submitted for RFC6733,
> "Diameter Base Protocol".
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803
> --------------------------------------
> Type: Editorial
> Reported by: Holger Freyther 
> Section: 3.2
> Original Text
> -------------
>     Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
>                         { User-Name }
>                      1* { Origin-Host }
>                       * [ AVP ]
> Corrected Text
> --------------
>      ::= < Diameter-Header: 9999999, REQ, PXY >
>                         { User-Name }
>                      1* { Origin-Host }
>                       * [ AVP ]
> Notes
> -----
> I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF.
>    header           = "                           [r-bit] [p-bit] [e-bit] [application-id]">"
> But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:".
>   command-def      = "<" command-name ">" "::=" diameter-message
> but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name.
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
> --------------------------------------
> RFC6733 (draft-ietf-dime-rfc3588bis-33)
> --------------------------------------
> Title               : Diameter Base Protocol
> Publication Date    : October 2012
> Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
> Category            : PROPOSED STANDARD
> Source              : Diameter Maintenance and Extensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> .
> _________________________________________________________________________________________________________________________
> 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.
> 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.
> _________________________________________________________________________________________________________________________
>
> 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.
>
> 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.


--------------CC8BC7BF956EE68156085C4C
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Dear all,

      

      I would appreciate if others would share their views.

      

      Regards, B.

    

    

      
      
      
      

        
This errata report is correct on the
            inconsistency regarding the definition of the command header
            and AVP header and how they are used in the rest of the
            document in the ABNF description of commands and Grouped
            AVPs.

        
 

        
For commands, the header is defined as follow:

        
 

        
   header           = "<Diameter-Header:"
            command-id

        
                         [r-bit] [p-bit]
            [e-bit] [application-id]">"

        
 

        
whereas "<Diameter Header:" is used when
            defining commands.

        
 

        
Same for Grouped AVP. It is defined as follow:

        
 

        
         header           = "<"
            "AVP-Header:" avpcode [vendor] ">"

        
 

        
whereas "<AVP Header:" is used when defining
            Grouped AVPs.

        
 

        
Considering that most (if not all) the ABNF
            descriptions have been copied from the commands and Grouped
            AVPs defined in the RFC3588 or RFC6733, I would be in favor
            to correct the specification by modifying the definition of
            the headers, i.e.

        
 

        
--> In section 3.2.  Command Code Format
            Specification

        
 

        
OLD:

        
 

        
   header           = "<Diameter-Header:"
            command-id

        
                         [r-bit] [p-bit]
            [e-bit] [application-id]">"

        
 

        
NEW:

        
 

        
   header           = "<Diameter Header:"
            command-id

        
                         [r-bit] [p-bit]
            [e-bit] [application-id]">"

        
 

        
 

        
--> And in section 4.4

        
 

        
OLD:

        
 

        
         header           = "<"
            "AVP-Header:" avpcode [vendor] ">"

        
 

        
NEW:

        
 

        
         header           = "<" "AVP
            Header:" avpcode [vendor] ">"

        
 

        
*******************

        
There are other issues pointed out in this
            report.

        
 

        
For command-def  = "<" command-name ">"
            "::=" diameter-message, I would propose to simply correct
            the example as all the command definitions given in the
            document are following the command-def definition.

        
For the grouped-avp-def, I don't know what
            would be the best approach. We could follow the same
            approach and require the addition of "<>" but I don't
            know what would be the impacts on existing Grouped AVPs
            defined without.

        
 

        
Regards,

        
 

        
Lionel.

        
 

        

          

            

              


                -------- Forwarded Message -------- 

              

                
                  

                    
                      
Subject: 

                    		
                    
                      
[Editorial Errata Reported]
                        RFC6733 (4803)

                    		
                  

                  

                    
                      
Date: 

                    		
                    
                      
Tue, 13 Sep 2016 14:42:13
                        -0700

                    		
                  

                  

                    
                      
From: 

                    		
                    
                      
RFC Errata System 
                          <rfc-editor@rfc-editor.org>

                    		
                  

                  

                    
                      
To: 

                    		
                    
                      
vf0213@gmail.com,
                        
                          jari.arkko@ericsson.com, john.loughney@nokia.com,
                        glenzorn@gmail.com,
                        
                          bclaise@cisco.com, joelja@bogus.com,
                        
                          jouni.nospam@gmail.com, lionel.morand@orange.com

                    		
                  

                  

                    
                      
CC: 

                    		
                    
                      
holger+ietf@freyther.de,
                        dime@ietf.org,
                        
                          rfc-editor@rfc-editor.org

                    		
                  

                
              

              
 

              
The following errata report has been submitted for RFC6733,

              
"Diameter Base Protocol".

              
 

              
--------------------------------------

              
You may review the report below and at:

              
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803

              
 

              
--------------------------------------

              
Type: Editorial

              
Reported by: Holger Freyther <holger+ietf@freyther.de>

              
 

              
Section: 3.2

              
 

              
Original Text

              
-------------

              
   Example-Request ::= < Diameter Header: 9999999, REQ, PXY >

              
                       { User-Name }

              
                    1* { Origin-Host }

              
                     * [ AVP ]

              
 

              
 

              
 

              
Corrected Text

              
--------------

              
   <Example-Request> ::= < Diameter-Header: 9999999, REQ, PXY >

              
                       { User-Name }

              
                    1* { Origin-Host }

              
                     * [ AVP ]

              
 

              
 

              
 

              
Notes

              
-----

              
I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. 

              
 

              
  header           = "<Diameter-Header:" command-id

              
                         [r-bit] [p-bit] [e-bit] [application-id]">"

              
 

              
But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:".

              
 

              
 

              
 command-def      = "<" command-name ">" "::=" diameter-message

              
 

              
but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name.

              
 

              
Instructions:

              
-------------

              
This erratum is currently posted as "Reported". If necessary, please

              
use "Reply All" to discuss whether it should be verified or

              
rejected. When a decision is reached, the verifying party (IESG)

              
can log in to change the status and edit the report, if necessary. 

              
 

              
--------------------------------------

              
RFC6733 (draft-ietf-dime-rfc3588bis-33)

              
--------------------------------------

              
Title               : Diameter Base Protocol

              
Publication Date    : October 2012

              
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.

              
Category            : PROPOSED STANDARD

              
Source              : Diameter Maintenance and Extensions

              
Area                : Operations and Management

              
Stream              : IETF

              
Verifying Party     : IESG

              
 

              
.

              
 

            

          

          
_________________________________________________________________________________________________________________________

          
 

          
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.

          
 

          
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.

        

      

      
_________________________________________________________________________________________________________________________

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.

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.


    

    

  


--------------CC8BC7BF956EE68156085C4C--


From nobody Thu Jan 12 12:57:09 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F631294F7 for ; Thu, 12 Jan 2017 12:57:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 LrhF68EhK-Qi for ; Thu, 12 Jan 2017 12:57:06 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 79949129499 for ; Thu, 12 Jan 2017 12:57:06 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:61143 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cRmQc-00092E-TL for dime@ietf.org; Thu, 12 Jan 2017 12:57:06 -0800
To: dime@ietf.org
References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com> <86f38e04-292f-2463-95ac-a25bad4a51e6@cs.tcd.ie> <4539dd06-54bb-8b4f-a597-c4846349728f@usdonovans.com>
From: Steve Donovan 
Message-ID: <5b286655-ff55-0474-76b2-093a64931580@usdonovans.com>
Date: Thu, 12 Jan 2017 14:56:58 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <4539dd06-54bb-8b4f-a597-c4846349728f@usdonovans.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [Dime] AD evaluation of draft-ietf-dime-load-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jan 2017 20:57:07 -0000

Stephen correctly pointed out that there is missing language in the 
normative portion of the draft.  It is explained in section 5 that and 
agent removes all load reports that it receives in an answer message.  
The normative text for this requirement did not make it into section 
6.2.  As such, I will be submitting a new version of the draft with the 
following added to section 6.2:

"In all cases, a Diameter Agent MUST strip all load reports of type peer
received in answer messages.

     Note: This ensures that there will be precisely one load report of
type peer, that of the Diameter node sending the message, in any answer
messages sent by the Diameter agent. "

Let me know if there are any issues with this wording.

Regards,

Steve

On 1/12/17 9:34 AM, Steve Donovan wrote:
> Stephen,
>
> I think that what you are proposing is for the following network:
>
> A' ---- B' ----- C ----- D --|-- E'
>                                               ^
>                                 Administrative boundary
>
> Where A', B' and E' support load and C and D do not.
>
> I think you are proposing that node D strips a peer load report 
> inserted by B'.  Is this correct?
>
> The issue is that this is load-specific functionality, requiring D to 
> understand at least some of the Load mechanism.  But, by definition,  
> D does not support or understand anything about the load mechanism.
>
> I don't see a way of achieving what you propose without adding load 
> specific functionality to D.
>
> Steve
>
> On 1/12/17 5:54 AM, Stephen Farrell wrote:
>> Hiya,
>>
>> Just one thing below I'd like to figure out before
>> IETF LC...
>>
>> On 09/01/17 22:28, Steve Donovan wrote:
>>> Stephen,
>>>
>>> Thanks for the review and for the ping.  Comments below.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>> On 1/6/17 10:33 AM, Stephen Farrell wrote:
>>>> Just bumping this, post holidays. I believe the
>>>> ball is not in my court for this one:-)
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> On 16/12/16 17:38, Stephen Farrell wrote:
>>>>> Hiya,
>>>>>
>>>>> Thanks for getting this stuff progressed. I've done my
>>>>> AD evaluation and have a few questions I'd like to ask
>>>>> before starting IETF last call. Those are below along
>>>>> with some more nitty comments that can be handled now or
>>>>> later as the authors/WG prefer.
>>>>>
>>>>> Cheers,
>>>>> S.
>>>>>
>>>>> Things to chat about before starting IETF LC:
>>>>> ---------------------------------------------
>>>>>
>>>>> (1) Is "server selection" sufficiently clear? Where is
>>>>> that defined? I was a bit confused as to what this means
>>>>> that is not next-hop selection.
>>> SRD> Server selection is touched on in RFC7638 (DOIC) and the concept
>>> carries over to Load.  It refers to selection of the specific server
>>> instance that will be handling the request.  This is according to the
>>> Diameter Client, Server model.  I think it is well understood what is
>>> meant by those who understand Diameter and would be implementing this
>>> spec.  We can, if needed, add some definition. That would have been 
>>> best
>>> do be in the DOIC RFC but it can go here if needed.
>> Ok, let's handle that as an IETF LC comment. If others
>> think a definition would be good you can add it later.
>> If it's just me, don't bother.
>>
>>>>> (2) PEER reports that are first received at a
>>>>> non-supporting node will be left in place and will reach
>>>>> the destination of the message. If that destination is in a
>>>>> different domain then that leaks some internal structure
>>>>> (the SourceID) to outsiders. Is that desirable?  Why not
>>>>> have the first node that does support this AVP delete the
>>>>> PEER report even if the node that added the PEER report is
>>>>> not a peer of this node? (Note: I see this risk is ack'd
>>>>> in section 8, I'm asking if we can avoid it almost
>>>>> entirely by removing PEER reports that are useless.)
>>> SRD> There is no formal mechanism in place in Diameter to do "topology
>>> hiding".  There are many other places where topology information can
>>> leak, so it isn't an issue specific to Load.  It is addressed today
>>> through proprietary implementations.
>> Sure, that's not a good reason to make it harder though.
>> But see below...
>>
>>> SRD> Having a node that does not support would go against the Diameter
>>> extensibility strategy.  Nodes that don't understand an AVP are 
>>> required
>>> to pass it on.  Nodes that do support the mechanism and see a Load
>>> report of type peer that isn't of type peer are supposed to remove it.
>> I don't understand what " a Load report of type peer that
>> isn't of type peer" can mean.
>>
>>> Doing anything other than this would require a change to the base
>>> Diameter specification.
>> Either I'm mis-remembering the draft or we're talking at
>> cross purposes. My reading was that nodes that do support
>> the mechanism could delete a peer report that actually
>> comes via a node that does not support the mechanism. Am
>> I wrong? If so maybe there's a clarity issue. If not, I
>> don't see why that makes sense.
>>
>> Cheers,
>> S.
>>
>> PS: The rest below is fine to handle later as you suggest.
>>
>>>>> (3) This spec is a bit like RFC7944 (DRMP) in that it
>>>>> defines some but not all of the things one needs to end up
>>>>> with a workable system. That aspect of DRMP caused some
>>>>> discussion during IESG evaluation. Have the authors of
>>>>> this reviewed that discussion to see if we can avoid any
>>>>> likely iterations being needed at that point? I'm hoping
>>>>> that Steve, as an author of both, won't find this too
>>>>> hard to do:-) If that's been done, great. If not, please
>>>>> consider if there's any additional explanatory material
>>>>> that could be added that might help us not to have to
>>>>> iterate to discuss the same kinds of concern.
>>> SRD> I'll go back and review that discussion and see if there is
>>> something that needs to be added.  I'm hoping that the fact that we 
>>> made
>>> it through the discussion with DRMP will make it easier to do so with
>>> Load (and maybe agent overload).  I'm doubtful that we can fully
>>> inoculate the draft from some of this level of discussion as we are
>>> dealing with Diameter here.
>>>>> nits (fine to be considered last call comments):
>>>>> -------------------------------------------------
>>> SRD> I'll deal with these as part of last call.
>>>>> abstract: maybe put the 1st sentence last? that might read
>>>>> better
>>>>>
>>>>> 4.1: the "opinion of the authors" isn't really of interest
>>>>> at this point - is this also the opinion of the WG? (I
>>>>> assume it is)
>>>>>
>>>>> section 5 says "The load report includes a value
>>>>> indicating the load of the sending node relative load of
>>>>> the sending node, specified in a manner consistent with
>>>>> that defined for DNS SRV [RFC2782]." I can't parse that.
>>>>>
>>>>> - 6.2: What is a Diameter "connection?" I thought that
>>>>> Diameter could use UDP as well as TCP so is that really
>>>>> the right term? Maybe "message sender" is a better way to
>>>>> identify the peer?
>>>>>
>>>>> - section 8: "might require a transitive trust model" is
>>>>> far too coy IMO. I think you should say that DOIC and this
>>>>> entirely require transitive trust because we have no
>>>>> Diameter mechanism that allows authenticated adding and
>>>>> removal of AVPs as messages transit a network. (We did try
>>>>> develop that ages ago but it was too complex, so I'm not
>>>>> arguing to try again, just that we clearly ack the fact
>>>>> that this stuff requires transitive trust.)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Jan 12 13:06:39 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981291294D8 for ; Thu, 12 Jan 2017 13:06:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 8hOF5Yp5k5yx for ; Thu, 12 Jan 2017 13:06:36 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 E7F101294BB for ; Thu, 12 Jan 2017 13:06:36 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:61194 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cRmZp-000IY2-M2; Thu, 12 Jan 2017 13:06:36 -0800
To: Misha Zaytsev 
References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com>  <6c28f017-612e-3a17-8e23-5b4626d0f341@usdonovans.com> 
From: Steve Donovan 
Message-ID: <6b755a56-6183-97ff-d306-978a9dce8b3c@usdonovans.com>
Date: Thu, 12 Jan 2017 15:06:28 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------26456B06B945E93880DCB4FF"
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Cc: "dime@ietf.org" 
Subject: Re: [Dime] AD evaluation of draft-ietf-dime-load-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Jan 2017 21:06:38 -0000

This is a multi-part message in MIME format.
--------------26456B06B945E93880DCB4FF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Misha,

This draft has completed working group last call, so to some degree the 
comment period has passed.  That said, there are no hard and fast rules 
and we can certainly make changes that improve the draft.  However, once 
it gets into IESG review, which is the next step, it will be more 
difficult to make significant changes.

On your comment below, I don't see the need for the change.  I am 
willing, however, to qualify the word connection to say "Diameter 
connection".

Regards,

Steve

On 1/12/17 11:51 AM, Misha Zaytsev wrote:
> Hi Steve,
>
> Thanks a lot for your explanation!
> My bad that I have not read the draft more carefully - will try to 
> avoid this next time.
>
> Then I can propose another version of statement that will exclude 
> confusing "connection" term.
>
>> This is achieved by comparing SourceID AVP in the Load report with host identity field of the entries from peer table defined in RFC6733.
>
> If SourceID AVP contains the identity of one of the peer nodes (that 
> our node has a direct connection to), then this is what we are looking 
> for, right?
>
> However, I find the term "connection" legal as it is defined in 
> RFC6733, for instance section 5.1 "Peer Connections".
>
> Or it can be easily re-phrased in this way, the term "peer" should not 
> confuse anyone, I guess :)
>
> This is achieved by comparing the DiameterIdentity of the peer from which the message was received with the
> DiameterIdentity included in the SourceID AVP in the Load report.
>
> Btw, what is the due date for providing the comments for this draft?
>
> Best regards,
>
> /Misha
>
> 2017-01-12 20:16 GMT+03:00 Steve Donovan  >:
>
>     Misha,
>
>     I've added the DIME WG mailing list.
>
>     See my comments inline.
>
>     Regars,
>
>     Steve
>
>     On 1/11/17 12:03 PM, Misha Zaytsev wrote:
>>     Hi Steve,
>>
>>     I'm a newcomer in DiME working group - so, may not be familiar
>>     with all rules.
>>     So, excuse me in advance if it is not a good manner to comment
>>     the ongoing draft review.
>     SRD> Welcome to the working group!
>>
>>     But let me still put my 5 cents here.
>>
>>     Regarding this question from Stephen:
>>
>>     - 6.2: What is a Diameter "connection?" I thought that
>>     Diameter could use UDP as well as TCP so is that really
>>     the right term? Maybe "message sender" is a better way to
>>     identify the peer?
>>
>>     Why can't we re-phrase the related statement in the following way?
>>
>>     This is achieved by comparing Origin-Host AVP with SourceID AVP in the Load report.
>>
>     SRD> This actually doesn't work for the peer report case.  The
>     Origin-Host AVP is inserted by the Diameter client and it remains
>     the same as the request passes through Diameter agents.  For peer
>     reports, it is necessary to know the peer that sent the request,
>     not the client.  Thus the need to look at the DiameterID
>     associated with the Diameter connection.
>
>>     Also if it does not bother you, could you explain what is the
>>     official way to comment DiME drafts?
>     SRD> The official way is to do exactly what you are doing, but by
>     sending the questions and comments to the DIME WG mailing list.
>
>>
>>     Thanks a lot in advance!
>>
>>     /Misha
>>
>>
>>
>>     2017-01-10 1:28 GMT+03:00 Steve Donovan >     >:
>>
>>         Stephen,
>>
>>         Thanks for the review and for the ping. Comments below.
>>
>>         Regards,
>>
>>         Steve
>>
>>         On 1/6/17 10:33 AM, Stephen Farrell wrote:
>>>         Just bumping this, post holidays. I believe the
>>>         ball is not in my court for this one:-)
>>>
>>>         Cheers,
>>>         S.
>>>
>>>         On 16/12/16 17:38, Stephen Farrell wrote:
>>>>         Hiya,
>>>>
>>>>         Thanks for getting this stuff progressed. I've done my
>>>>         AD evaluation and have a few questions I'd like to ask
>>>>         before starting IETF last call. Those are below along
>>>>         with some more nitty comments that can be handled now or
>>>>         later as the authors/WG prefer.
>>>>
>>>>         Cheers,
>>>>         S.
>>>>
>>>>         Things to chat about before starting IETF LC:
>>>>         ---------------------------------------------
>>>>
>>>>         (1) Is "server selection" sufficiently clear? Where is
>>>>         that defined? I was a bit confused as to what this means
>>>>         that is not next-hop selection.
>>         SRD> Server selection is touched on in RFC7638 (DOIC) and the
>>         concept carries over to Load.  It refers to selection of the
>>         specific server instance that will be handling the request. 
>>         This is according to the Diameter Client, Server model.  I
>>         think it is well understood what is meant by those who
>>         understand Diameter and would be implementing this spec.  We
>>         can, if needed, add some definition. That would have been
>>         best do be in the DOIC RFC but it can go here if needed.
>>>>         (2) PEER reports that are first received at a
>>>>         non-supporting node will be left in place and will reach
>>>>         the destination of the message. If that destination is in a
>>>>         different domain then that leaks some internal structure
>>>>         (the SourceID) to outsiders. Is that desirable?  Why not
>>>>         have the first node that does support this AVP delete the
>>>>         PEER report even if the node that added the PEER report is
>>>>         not a peer of this node? (Note: I see this risk is ack'd
>>>>         in section 8, I'm asking if we can avoid it almost
>>>>         entirely by removing PEER reports that are useless.)
>>         SRD> There is no formal mechanism in place in Diameter to do
>>         "topology hiding".  There are many other places where
>>         topology information can leak, so it isn't an issue specific
>>         to Load.  It is addressed today through proprietary
>>         implementations. SRD> Having a node that does not support
>>         would go against the Diameter extensibility strategy.  Nodes
>>         that don't understand an AVP are required to pass it on. 
>>         Nodes that do support the mechanism and see a Load report of
>>         type peer that isn't of type peer are supposed to remove it. 
>>         Doing anything other than this would require a change to the
>>         base Diameter specification.
>>>>         (3) This spec is a bit like RFC7944 (DRMP) in that it
>>>>         defines some but not all of the things one needs to end up
>>>>         with a workable system. That aspect of DRMP caused some
>>>>         discussion during IESG evaluation. Have the authors of
>>>>         this reviewed that discussion to see if we can avoid any
>>>>         likely iterations being needed at that point? I'm hoping
>>>>         that Steve, as an author of both, won't find this too
>>>>         hard to do:-) If that's been done, great. If not, please
>>>>         consider if there's any additional explanatory material
>>>>         that could be added that might help us not to have to
>>>>         iterate to discuss the same kinds of concern.
>>         SRD> I'll go back and review that discussion and see if there
>>         is something that needs to be added.  I'm hoping that the
>>         fact that we made it through the discussion with DRMP will
>>         make it easier to do so with Load (and maybe agent
>>         overload).  I'm doubtful that we can fully inoculate the
>>         draft from some of this level of discussion as we are dealing
>>         with Diameter here.
>>>>         nits (fine to be considered last call comments):
>>>>         -------------------------------------------------
>>         SRD> I'll deal with these as part of last call.
>>>>         abstract: maybe put the 1st sentence last? that might read
>>>>         better
>>>>
>>>>         4.1: the "opinion of the authors" isn't really of interest
>>>>         at this point - is this also the opinion of the WG? (I
>>>>         assume it is)
>>>>
>>>>         section 5 says "The load report includes a value
>>>>         indicating the load of the sending node relative load of
>>>>         the sending node, specified in a manner consistent with
>>>>         that defined for DNS SRV [RFC2782]." I can't parse that.
>>>>
>>>>         - 6.2: What is a Diameter "connection?" I thought that
>>>>         Diameter could use UDP as well as TCP so is that really
>>>>         the right term? Maybe "message sender" is a better way to
>>>>         identify the peer?
>>>>
>>>>         - section 8: "might require a transitive trust model" is
>>>>         far too coy IMO. I think you should say that DOIC and this
>>>>         entirely require transitive trust because we have no
>>>>         Diameter mechanism that allows authenticated adding and
>>>>         removal of AVPs as messages transit a network. (We did try
>>>>         develop that ages ago but it was too complex, so I'm not
>>>>         arguing to try again, just that we clearly ack the fact
>>>>         that this stuff requires transitive trust.)
>>>>
>>>>
>>>>
>>>>
>>>>         _______________________________________________
>>>>         DiME mailing list
>>>>         DiME@ietf.org 
>>>>         https://www.ietf.org/mailman/listinfo/dime
>>>>         
>>>>
>>>         _______________________________________________
>>>         DiME mailing list
>>>         DiME@ietf.org 
>>>         https://www.ietf.org/mailman/listinfo/dime
>>>         
>>         _______________________________________________ DiME mailing
>>         list DiME@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/dime
>>          
>>

--------------26456B06B945E93880DCB4FF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Misha,

    

    This draft has completed working group last call, so to some degree
    the comment period has passed.  That said, there are no hard and
    fast rules and we can certainly make changes that improve the
    draft.  However, once it gets into IESG review, which is the next
    step, it will be more difficult to make significant changes.

    

    On your comment below, I don't see the need for the change.  I am
    willing, however, to qualify the word connection to say "Diameter
    connection".

    

    Regards,

    

    Steve  

    

    
On 1/12/17 11:51 AM, Misha Zaytsev
      wrote:

    

    

      
Hi Steve,
        


        

        
Thanks a lot for your explanation!

        
My bad that I have not read the
          draft more carefully - will try to avoid this next time.

        


        

        
Then I can propose another version
          of statement that will exclude confusing "connection" term.

        


        

        

          

            

              
This is achieved by comparing SourceID AVP in the Load report with host identity field of the entries from peer table defined in RFC6733.

            

          

        

        


        

        
If SourceID AVP contains the
          identity of one of the peer nodes (that our node has a direct
          connection to), then this is what we are looking for, right?

        


        

        
However, I find the term
          "connection" legal as it is defined in RFC6733, for instance
          section 5.1 "Peer Connections".

        


        

        
Or it can be easily re-phrased in
          this way, the term "peer" should not confuse anyone, I guess
          :)

        


        

        

          
This is achieved by comparing the DiameterIdentity of the peer from which the message was received with the
DiameterIdentity included in the SourceID AVP in the Load report.

        

        


        

        
Btw, what is the due date for
          providing the comments for this draft?

        


        

        
Best regards,

        


        

        
/Misha

      

      


        
2017-01-12 20:16 GMT+03:00 Steve
          Donovan <srdonovan@usdonovans.com>:

          

            
 Misha,

              

              I've added the DIME WG mailing list.

              

              See my comments inline.

              

              Regars,

              

              Steve

                

                
On
                  1/11/17 12:03 PM, Misha Zaytsev wrote:

                

                

                  
Hi Steve,
                    


                    

                    
I'm a newcomer in DiME working group - so, may
                      not be familiar with all rules.

                    
So, excuse me in advance if it is not a good
                      manner to comment the ongoing draft review.

                  

                

               SRD> Welcome to the working group!

                

                  

                    


                    

                    
But let me still put my 5 cents here.

                    


                    

                    
Regarding this question from Stephen:

                    


                    

                    
- 6.2: What is a
                        Diameter "connection?" I thought that

                      Diameter could use
                        UDP as well as TCP so is that really

                      the right term?
                        Maybe "message sender" is a better way to

                      identify the peer?

                    

                    


                      

                    
Why can't we
                        re-phrase the related statement in the following
                        way?

                    


                      

                    

                      
This is achieved by comparing Origin-Host AVP with SourceID AVP in the Load report.

                    

                    


                    

                  

                

               SRD> This actually doesn't work for the peer
              report case.  The Origin-Host AVP is inserted by the
              Diameter client and it remains the same as the request
              passes through Diameter agents.  For peer reports, it is
              necessary to know the peer that sent the request, not the
              client.  Thus the need to look at the DiameterID
              associated with the Diameter connection.

                

                

                  

                    
Also if it does not bother
                      you, could you explain what is the official way to
                      comment DiME drafts?

                  

                

               SRD> The official way is to do exactly what you
              are doing, but by sending the questions and comments to
              the DIME WG mailing list.
              

                


                  

                    

                      


                      

                      
Thanks a lot in advance!

                      


                      

                      
/Misha

                      


                      

                      


                      

                      


                        
2017-01-10 1:28
                          GMT+03:00 Steve Donovan <srdonovan@usdonovans.com>:

                          

                            

                              Stephen,

                              

                              Thanks for the review and for the ping. 
                              Comments below.

                              

                              Regards,

                              

                              Steve

                                

                                
On
                                  1/6/17 10:33 AM, Stephen Farrell
                                  wrote:

                                

                                

                                  
Just bumping this, post holidays. I believe the
ball is not in my court for this one:-)

Cheers,
S.

On 16/12/16 17:38, Stephen Farrell wrote:


                                  

                                    
Hiya,

Thanks for getting this stuff progressed. I've done my
AD evaluation and have a few questions I'd like to ask
before starting IETF last call. Those are below along
with some more nitty comments that can be handled now or
later as the authors/WG prefer.

Cheers,
S.

Things to chat about before starting IETF LC:
---------------------------------------------

(1) Is "server selection" sufficiently clear? Where is
that defined? I was a bit confused as to what this means
that is not next-hop selection.

      

    

    SRD> Server selection is touched on in RFC7638 (DOIC) and the
    concept carries over to Load.  It refers to selection of the
    specific server instance that will be handling the request.  This is
    according to the Diameter Client, Server model.  I think it is well
    understood what is meant by those who understand Diameter and would
    be implementing this spec.  We can, if needed, add some definition. 
    That would have been best do be in the DOIC RFC but it can go here
    if needed.

    

      

        
(2) PEER reports that are first received at a
non-supporting node will be left in place and will reach
the destination of the message. If that destination is in a
different domain then that leaks some internal structure
(the SourceID) to outsiders. Is that desirable?  Why not
have the first node that does support this AVP delete the
PEER report even if the node that added the PEER report is
not a peer of this node? (Note: I see this risk is ack'd
in section 8, I'm asking if we can avoid it almost
entirely by removing PEER reports that are useless.)

      

    

    SRD> There is no formal mechanism in place in Diameter to do
    "topology hiding".  There are many other places where topology
    information can leak, so it isn't an issue specific to Load.  It is
    addressed today through proprietary implementations.

    

    SRD> Having a node that does not support would go against the
    Diameter extensibility strategy.  Nodes that don't understand an AVP
    are required to pass it on.  Nodes that do support the mechanism and
    see a Load report of type peer that isn't of type peer are supposed
    to remove it.  Doing anything other than this would require a change
    to the base Diameter specification.

    

      

        
(3) This spec is a bit like RFC7944 (DRMP) in that it
defines some but not all of the things one needs to end up
with a workable system. That aspect of DRMP caused some
discussion during IESG evaluation. Have the authors of
this reviewed that discussion to see if we can avoid any
likely iterations being needed at that point? I'm hoping
that Steve, as an author of both, won't find this too
hard to do:-) If that's been done, great. If not, please
consider if there's any additional explanatory material
that could be added that might help us not to have to
iterate to discuss the same kinds of concern.

      

    

    SRD> I'll go back and review that discussion and see if there is
    something that needs to be added.  I'm hoping that the fact that we
    made it through the discussion with DRMP will make it easier to do
    so with Load (and maybe agent overload).  I'm doubtful that we can
    fully inoculate the draft from some of this level of discussion as
    we are dealing with Diameter here.

    

      

        
nits (fine to be considered last call comments):
-------------------------------------------------

      

    

    SRD> I'll deal with these as part of last call.


    

      

        
abstract: maybe put the 1st sentence last? that might read
better

4.1: the "opinion of the authors" isn't really of interest
at this point - is this also the opinion of the WG? (I
assume it is)

section 5 says "The load report includes a value
indicating the load of the sending node relative load of
the sending node, specified in a manner consistent with
that defined for DNS SRV [RFC2782]." I can't parse that.

- 6.2: What is a Diameter "connection?" I thought that
Diameter could use UDP as well as TCP so is that really
the right term? Maybe "message sender" is a better way to
identify the peer?

- section 8: "might require a transitive trust model" is
far too coy IMO. I think you should say that DOIC and this
entirely require transitive trust because we have no
Diameter mechanism that allows authenticated adding and
removal of AVPs as messages transit a network. (We did try
develop that ages ago but it was too complex, so I'm not
arguing to try again, just that we clearly ack the fact
that this stuff requires transitive trust.)




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



      

      
      

      

      

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


    

    

  



_______________________________________________

DiME mailing list

DiME@ietf.org

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





















--------------26456B06B945E93880DCB4FF--


From nobody Fri Jan 13 06:24:31 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2818812945E for ; Fri, 13 Jan 2017 06:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Level: 
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro0XaJJQivHS for ; Fri, 13 Jan 2017 06:24:28 -0800 (PST)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B47212007C for ; Fri, 13 Jan 2017 06:24:28 -0800 (PST)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([fe80::68ac:f071:19ff:3455%19]) with mapi id 14.03.0319.002; Fri, 13 Jan 2017 09:24:26 -0500
From: Yuval Lifshitz 
To: "dime@ietf.org" 
Thread-Topic: RFC4006bis - Subscription-Id-Extension AVP
Thread-Index: AdJtpzBPVPEgVuSXSxiP12VbbHIMng==
Date: Fri, 13 Jan 2017 14:24:25 +0000
Message-ID: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.132.3]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE497000AF59wtlexchp1sandvi_"
MIME-Version: 1.0
Archived-At: 
Subject: [Dime] RFC4006bis - Subscription-Id-Extension AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Jan 2017 14:24:30 -0000

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

Hi All,
As part of the RFC4006bis work there are several AVPs that we plan on makin=
g future proof (See also: https://trac.ietf.org/trac/dime/ticket/95). For e=
xample, Subscription-Id AVP cannot be extended to new types without changin=
g the enumeration in Subscription-Id-Type AVP, which in turn requires a new=
 application ID (something we really want to avoid).
To solve this issue we propose adding a new, extendable AVP. In this exampl=
e:

Subscription-Id-Extension ::=3D < AVP Header: XXX >
                             [ Subscription-Id-E164 ]
                             [ Subscription-Id-IMSI ]
                             [ Subscription-Id-SIP-URI ]
                             [ Subscription-Id-NAI ]
                             [ Subscription-Id-Private ]
                            *[ AVP ]

When looking into Subscription-ID-Extension AVP  header flags I ran into a =
problem. The existing Subscription-ID AVP (and its sub-AVPs) are all marked=
 with the M-bit as a "must", probably because they hold the subscriber's na=
me which is critical information.
However, in order for a RFC4006bis CC client to be able to communicate with=
 an RFC4006 CC-server, they will have to be marked as "may".

Would appreciate your point of view on that topic?

Best Regards,

Yuval


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











Hi All,


As part of the RFC4006bis work there are several AVP=
s that we plan on making future proof (See also:
https://trac.ietf.org=
/trac/dime/ticket/95). For example, Subscription-Id AVP cannot be exten=
ded to new types without changing the enumeration in Subscription-Id-Type A=
VP, which in turn requires a new application
 ID (something we really want to avoid).


To solve this issue we propose adding a new, extenda=
ble AVP. In this example:


 


Subscription-Id-Extension ::=3D < AVP Heade=
r: XXX >


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-E164 ]


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-IMSI ]


        &nb=
sp;            =
        [ Subscription-Id-SIP-URI ]=



       &nbs=
p;            &=
nbsp;        [ Subscription-Id-NAI ]


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-Private ]=



       &nbs=
p;            &=
nbsp;       *[ AVP ]


 


When looking into Subscription-ID-Extension AVP &nbs=
p;header flags I ran into a problem. The existing Subscription-ID AVP (and =
its sub-AVPs) are all marked with the M-bit as a “must”, probab=
ly because they hold the subscriber’s name which is
 critical information.


However, in order for a RFC4006bis CC client to be a=
ble to communicate with an RFC4006 CC-server, they will have to be marked a=
s “may”.



 


Would appreciate your point of view on that topic?


 


Best Regards,


 


Yuval


 






--_000_C43C255C7106314F8D13D03FA20CFE497000AF59wtlexchp1sandvi_--


From nobody Sun Jan 15 02:00:41 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA4E12945C for ; Sun, 15 Jan 2017 02:00:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt1Kax9Cutm2 for ; Sun, 15 Jan 2017 02:00:37 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9C0129415 for ; Sun, 15 Jan 2017 02:00:37 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id z134so60635121lff.3 for ; Sun, 15 Jan 2017 02:00:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zd6Amu57xlZbm36NUWS5DsYY1vbHrZbcLQTZaN+apwk=; b=m9xwtDiH2S+IDoOalJ9EGtYwJlitn65Zb1huy2UrxVY8TAsX2Ba1X1qwCVMPuPoHVe 6KGWmy4v7AmNsPlZlbUc3WacXLif8IvFbVDpSFeV02/Tjuf7NMddrjYoGMT9sRjuJ2sj F7KLSYyag0M4Njx7Q96L2Qkz4+95JE/M2GscMeZViHIHNTqNUM1uIss6HBJLEvhc1OUn Z2D51rfgU+bbGoyzBMIlJSusA1yManJbP2eor7O0Fj9Zixhg0JOJKridSLF9TUZE5Z9Q UWf5bX6BEk83MGyr30EfCQ/db3fo7e8YwiKhs9hfqtTaO+tU6GZ9h2H1XISnyJKNMW7n BnOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zd6Amu57xlZbm36NUWS5DsYY1vbHrZbcLQTZaN+apwk=; b=TMJ7YhUSSHyB+hljewrMwtgLB/Y9wHAvdag5G7rpkVsVo0kj2BKGY1B3jQ+G7/joNm xC7bicnhvCBuVrBgjd5D6gvj2/fzZNxVt3yoW1IQ5rCDjraPyzQusnpiYSSrVzUpb+CD TPUEJIK8t4+lVxn1cvXZibsDOtwkkRxiezXfv8NmXid3KmK31jDcGdnhosnFyb90OL2h GSbqW4DTRjD3CXdfRczZS+2PmDfqT1cS7KppesJnGIPjfotgSEOuJjTQ1dAga9+/zXu6 VqbmsBVwuAPlfe2gUT1c++HVLX6MSzuQkkcKyCQWbYh/6a94elnkHLzlgvawMi8J+bs6 XtpA==
X-Gm-Message-State: AIkVDXJT7ZdB2HUdA/mbeo8mB+oHjy7jGwTV5xH6P6586LeRWREgq/bLWA+pV4Szk8waS2Wj7mMGZdgx7pzwCA==
X-Received: by 10.25.37.80 with SMTP id l77mr8697219lfl.152.1484474435140; Sun, 15 Jan 2017 02:00:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Sun, 15 Jan 2017 02:00:34 -0800 (PST)
In-Reply-To: <6b755a56-6183-97ff-d306-978a9dce8b3c@usdonovans.com>
References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com>  <6c28f017-612e-3a17-8e23-5b4626d0f341@usdonovans.com>  <6b755a56-6183-97ff-d306-978a9dce8b3c@usdonovans.com>
From: Misha Zaytsev 
Date: Sun, 15 Jan 2017 13:00:34 +0300
Message-ID: 
To: Steve Donovan 
Content-Type: multipart/alternative; boundary=001a114102d86280a105461f23ce
Archived-At: 
Cc: "dime@ietf.org" 
Subject: Re: [Dime] AD evaluation of draft-ietf-dime-load-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Jan 2017 10:00:41 -0000

--001a114102d86280a105461f23ce
Content-Type: text/plain; charset=UTF-8

Hi Steve,

Sure, you can treat it as you wish since it is just a minor comment from my
side.
However, I have other comments/questions to address:

0. general (editorial) Proposals regarding wording in the spec:
- Use either "fulfil" or "fulfill" even if both forms are possible
- Use "remove"/"discard" instead of "strip" since it seems to be more formal

1. section 4.1 (editorial)
-  "did not had" -> "did not have"
- "reacting node reduce" -> "reacting node reduce*s*"

2. general (question): Why is different writing used for the same terms
through the spec?
Example#1, "Load report" and "load report"
Example#2, "report of type peer" and "load report of PEER"
Example#3, "Diameter agent" and "Diameter Agent"
Is this intentional? If yes, please clarify the intention.

3. section 5 (editorial)

The load report includes a value indicating the load of the sending
   node relative load of the sending node, specified in a manner
   consistent with that defined for DNS SRV [RFC2782].

Should not be re-phrased a little bit in this way  - "...a value indicating
the relative load of the sending node, specified..."?

4. section 5 (editorial): "weigh" -> "weigh*t*"

The distribution algorithm used by Diameter nodes supporting the
   Diameter Load mechanism is an implementation decision but it needs to
   result in similar behavior to the algorithm described for the use of
   weight values specified in [RFC2782].


5. section 5 (question)

The second type of load report is a peer report.  This report is used
   by Diameter nodes as part of the logic to select the next-hop
   Diameter node and, as such, does not have significance beyond the
   peer node.  These load reports are removed by the first supporting
   Diameter node to receive the report.

Under "These load reports are removed..." the report of type PEER is meant,
right?
Probably it is better to re-phrase this statement saying more explicitly:
"The report of type PEER is removed by the first Diameter node supporting
Load mechanism."

6. section 6.1.2 (editorial) "insures" -> "*e*nsures"

Note: In the case of peer load reports it is only necessary to
      include load reports when the load value has changed by some
      meaningful value, as long as the agent *e*nsures that all peers
      receive the report.  It is also acceptable to include the load
      report in every answer message handled by the Diameter agent.


7. section 6.2 (editorial) "weigth" -> "weight"

How a Diameter node uses load information for making routing
   decisions is an implementation decision.  However, the distribution
   algorithm MUST result in similar behavior as the algorithm described
   for the use of weig*ht* values in [RFC2782].


8. section 6.4 (editorial) "Addition and removal of Nodes" -> "Addition and
Removal of Nodes"

9. general. I'm voting for that the term "server selection" would be
defined explicitly in the spec.
You answered on the comment from Stephen that this term came from RFC7683.
But I have found only one place where it is mentioned: Appendix B,
"Non-supporting Agents".

Thanks a lot in advance.

/Misha

2017-01-13 0:06 GMT+03:00 Steve Donovan :

> Misha,
>
> This draft has completed working group last call, so to some degree the
> comment period has passed.  That said, there are no hard and fast rules and
> we can certainly make changes that improve the draft.  However, once it
> gets into IESG review, which is the next step, it will be more difficult to
> make significant changes.
>
> On your comment below, I don't see the need for the change.  I am willing,
> however, to qualify the word connection to say "Diameter connection".
>
> Regards,
>
> Steve
>
> On 1/12/17 11:51 AM, Misha Zaytsev wrote:
>
> Hi Steve,
>
> Thanks a lot for your explanation!
> My bad that I have not read the draft more carefully - will try to avoid
> this next time.
>
> Then I can propose another version of statement that will exclude
> confusing "connection" term.
>
> This is achieved by comparing SourceID AVP in the Load report with host identity field of the entries from peer table defined in RFC6733.
>
>
> If SourceID AVP contains the identity of one of the peer nodes (that our
> node has a direct connection to), then this is what we are looking for,
> right?
>
> However, I find the term "connection" legal as it is defined in RFC6733,
> for instance section 5.1 "Peer Connections".
>
> Or it can be easily re-phrased in this way, the term "peer" should not
> confuse anyone, I guess :)
>
> This is achieved by comparing the DiameterIdentity of the peer from which the message was received with the
> DiameterIdentity included in the SourceID AVP in the Load report.
>
>
> Btw, what is the due date for providing the comments for this draft?
>
> Best regards,
>
> /Misha
>
> 2017-01-12 20:16 GMT+03:00 Steve Donovan :
>
>> Misha,
>>
>> I've added the DIME WG mailing list.
>>
>> See my comments inline.
>>
>> Regars,
>>
>> Steve
>>
>> On 1/11/17 12:03 PM, Misha Zaytsev wrote:
>>
>> Hi Steve,
>>
>> I'm a newcomer in DiME working group - so, may not be familiar with all
>> rules.
>> So, excuse me in advance if it is not a good manner to comment the
>> ongoing draft review.
>>
>> SRD> Welcome to the working group!
>>
>>
>> But let me still put my 5 cents here.
>>
>> Regarding this question from Stephen:
>>
>> - 6.2: What is a Diameter "connection?" I thought that
>> Diameter could use UDP as well as TCP so is that really
>> the right term? Maybe "message sender" is a better way to
>> identify the peer?
>>
>> Why can't we re-phrase the related statement in the following way?
>>
>> This is achieved by comparing Origin-Host AVP with SourceID AVP in the Load report.
>>
>>
>> SRD> This actually doesn't work for the peer report case.  The
>> Origin-Host AVP is inserted by the Diameter client and it remains the same
>> as the request passes through Diameter agents.  For peer reports, it is
>> necessary to know the peer that sent the request, not the client.  Thus the
>> need to look at the DiameterID associated with the Diameter connection.
>>
>> Also if it does not bother you, could you explain what is the official
>> way to comment DiME drafts?
>>
>> SRD> The official way is to do exactly what you are doing, but by sending
>> the questions and comments to the DIME WG mailing list.
>>
>>
>> Thanks a lot in advance!
>>
>> /Misha
>>
>>
>>
>> 2017-01-10 1:28 GMT+03:00 Steve Donovan :
>>
>>> Stephen,
>>>
>>> Thanks for the review and for the ping.  Comments below.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>> On 1/6/17 10:33 AM, Stephen Farrell wrote:
>>>
>>> Just bumping this, post holidays. I believe the
>>> ball is not in my court for this one:-)
>>>
>>> Cheers,
>>> S.
>>>
>>> On 16/12/16 17:38, Stephen Farrell wrote:
>>>
>>> Hiya,
>>>
>>> Thanks for getting this stuff progressed. I've done my
>>> AD evaluation and have a few questions I'd like to ask
>>> before starting IETF last call. Those are below along
>>> with some more nitty comments that can be handled now or
>>> later as the authors/WG prefer.
>>>
>>> Cheers,
>>> S.
>>>
>>> Things to chat about before starting IETF LC:
>>> ---------------------------------------------
>>>
>>> (1) Is "server selection" sufficiently clear? Where is
>>> that defined? I was a bit confused as to what this means
>>> that is not next-hop selection.
>>>
>>> SRD> Server selection is touched on in RFC7638 (DOIC) and the concept
>>> carries over to Load.  It refers to selection of the specific server
>>> instance that will be handling the request.  This is according to the
>>> Diameter Client, Server model.  I think it is well understood what is meant
>>> by those who understand Diameter and would be implementing this spec.  We
>>> can, if needed, add some definition.  That would have been best do be in
>>> the DOIC RFC but it can go here if needed.
>>>
>>> (2) PEER reports that are first received at a
>>> non-supporting node will be left in place and will reach
>>> the destination of the message. If that destination is in a
>>> different domain then that leaks some internal structure
>>> (the SourceID) to outsiders. Is that desirable?  Why not
>>> have the first node that does support this AVP delete the
>>> PEER report even if the node that added the PEER report is
>>> not a peer of this node? (Note: I see this risk is ack'd
>>> in section 8, I'm asking if we can avoid it almost
>>> entirely by removing PEER reports that are useless.)
>>>
>>> SRD> There is no formal mechanism in place in Diameter to do "topology
>>> hiding".  There are many other places where topology information can leak,
>>> so it isn't an issue specific to Load.  It is addressed today through
>>> proprietary implementations. SRD> Having a node that does not support would
>>> go against the Diameter extensibility strategy.  Nodes that don't
>>> understand an AVP are required to pass it on.  Nodes that do support the
>>> mechanism and see a Load report of type peer that isn't of type peer are
>>> supposed to remove it.  Doing anything other than this would require a
>>> change to the base Diameter specification.
>>>
>>> (3) This spec is a bit like RFC7944 (DRMP) in that it
>>> defines some but not all of the things one needs to end up
>>> with a workable system. That aspect of DRMP caused some
>>> discussion during IESG evaluation. Have the authors of
>>> this reviewed that discussion to see if we can avoid any
>>> likely iterations being needed at that point? I'm hoping
>>> that Steve, as an author of both, won't find this too
>>> hard to do:-) If that's been done, great. If not, please
>>> consider if there's any additional explanatory material
>>> that could be added that might help us not to have to
>>> iterate to discuss the same kinds of concern.
>>>
>>> SRD> I'll go back and review that discussion and see if there is
>>> something that needs to be added.  I'm hoping that the fact that we made it
>>> through the discussion with DRMP will make it easier to do so with Load
>>> (and maybe agent overload).  I'm doubtful that we can fully inoculate the
>>> draft from some of this level of discussion as we are dealing with Diameter
>>> here.
>>>
>>> nits (fine to be considered last call comments):
>>> -------------------------------------------------
>>>
>>> SRD> I'll deal with these as part of last call.
>>>
>>> abstract: maybe put the 1st sentence last? that might read
>>> better
>>>
>>> 4.1: the "opinion of the authors" isn't really of interest
>>> at this point - is this also the opinion of the WG? (I
>>> assume it is)
>>>
>>> section 5 says "The load report includes a value
>>> indicating the load of the sending node relative load of
>>> the sending node, specified in a manner consistent with
>>> that defined for DNS SRV [RFC2782]." I can't parse that.
>>>
>>> - 6.2: What is a Diameter "connection?" I thought that
>>> Diameter could use UDP as well as TCP so is that really
>>> the right term? Maybe "message sender" is a better way to
>>> identify the peer?
>>>
>>> - section 8: "might require a transitive trust model" is
>>> far too coy IMO. I think you should say that DOIC and this
>>> entirely require transitive trust because we have no
>>> Diameter mechanism that allows authenticated adding and
>>> removal of AVPs as messages transit a network. (We did try
>>> develop that ages ago but it was too complex, so I'm not
>>> arguing to try again, just that we clearly ack the fact
>>> that this stuff requires transitive trust.)
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> DiME mailing listDiME@ietf.orghttps://www.ietf.org/mailman/listinfo/dime
>>>
>>> _______________________________________________
>>> DiME mailing listDiME@ietf.orghttps://www.ietf.org/mailman/listinfo/dime
>>>
>>> _______________________________________________ DiME mailing list
>>> DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime
>>
>>

--001a114102d86280a105461f23ce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Steve,

Sure, you can treat it as you=
 wish since it is just a minor comment from my side.
However, I h=
ave other comments/questions to address:

0. genera=
l (editorial) Proposals regarding wording in the spec:
- Use eith=
er "fulfil" or "fulfill" even if both forms are possibl=
e
- Use "remove"/"discard" instead of "s=
trip" since it seems to be more formal

1. sec=
tion 4.1 (editorial)
- =C2=A0"did not had" -> "=
did not have"
- "reacting node reduce" -> "=
;reacting node reduces"

2. general (qu=
estion): Why is different writing used for the same terms through the spec?=

Example#1, "Load report" and "load report"
Example#2, "report of type peer" and "load report o=
f PEER"
Example#3, "Diameter agent" and "Diam=
eter Agent"
Is this intentional? If yes, please clarify the =
intention.=C2=A0

3. section 5 (editorial)

The load report includes a valu=
e indicating the load of the sending
   node relative load of the sending node, specified in a manner
   consistent with that defined for DNS SRV [RFC2782].
Shou=
ld not be re-phrased a little bit in this way =C2=A0- "...a value indi=
cating the relative load of the sending node, specified..."?

4. section 5 (editorial): "weigh" -> "wei=
ght"

The di=
stribution algorithm used by Diameter nodes supporting the
   Diameter Load mechanism is an implementation decision but it needs to
   result in similar behavior to the algorithm described for the use of
   weight values specified in [RFC2782].

5. =
section 5 (question)

Th=
e second type of load report is a peer report.  This report is used
   by Diameter nodes as part of the logic to select the next-hop
   Diameter node and, as such, does not have significance beyond the
   peer node.  These load reports are removed by the first supporting
   Diameter node to receive the report.
Under "These l=
oad reports are removed..." the report of type PEER is meant, right?
Probably it is better to re-phrase this statement saying more expl=
icitly:
"The report of type PEER is removed by the first Dia=
meter node supporting Load mechanism."

6. sec=
tion 6.1.2 (editorial) "insures" -> "ensures"=


Note: In the case of p=
eer load reports it is only necessary to
      include load reports when the load value has changed by some
      meaningful value, as long as the agent ensures that all peers
      receive the report.  It is also acceptable to include the load
      report in every answer message handled by the Diameter agent.

7. section 6.2 (editorial) "weigth" ->=
 "weight"

How=
 a Diameter node uses load information for making routing
   decisions is an implementation decision.  However, the distribution
   algorithm MUST result in similar behavior as the algorithm described
   for the use of weight values in [RFC2782].

8. section 6.4 (editorial) "Addition and removal of Nodes&quo=
t; -> "Addition and Removal of Nodes"

9. general. I'm voting for that the term "server selection" =
would be defined explicitly in the spec.
You answered on the comm=
ent from Stephen that this term came from RFC7683.
But I have fou=
nd only one place where it is mentioned: Appendix B, "Non-supporting A=
gents".

Thanks a lot in advance.
/Misha

2017-01-13 0:06 GMT+03:00 Steve Donovan <=
;srdonovan@us=
donovans.com>:

 =20
   =20
 =20
  

    Misha,

    

    This draft has completed working group last call, so to some degree
    the comment period has passed.=C2=A0 That said, there are no hard and
    fast rules and we can certainly make changes that improve the
    draft.=C2=A0 However, once it gets into IESG review, which is the next
    step, it will be more difficult to make significant changes.

    

    On your comment below, I don't see the need for the change.=C2=A0 I=
 am
    willing, however, to qualify the word connection to say "Diameter
    connection".

    

    Regards,

    

    Steve=C2=A0 

    

    
On 1/12/17 11:51 AM=
, Misha Zaytsev
      wrote:

    

    

      
Hi Steve,
        


        

        
Thanks a lot for your explanation!<=
/div>
        
My bad that I have not read the
          draft more carefully - will try to avoid this next time.

        


        

        
Then I can propose another version
          of statement that will exclude confusing "connection" t=
erm.

        


        

        

          

            

              
This is achieved by comparing =
SourceID AVP in the Load report with host identity field of the entries fro=
m peer table defined in RFC6733.

            

          

        

        


        

        
If SourceID AVP contains the
          identity of one of the peer nodes (that our node has a direct
          connection to), then this is what we are looking for, right?
        


        

        
However, I find the term
          "connection" legal as it is defined in RFC6733, for ins=
tance
          section 5.1 "Peer Connections".

        


        

        
Or it can be easily re-phrased in
          this way, the term "peer" should not confuse anyone, I =
guess
          :)

        


        

        

          
This is achieved =
by comparing the DiameterIdentity of the peer from which the message was re=
ceived with the
DiameterIdentity included in the SourceID AVP in the Load report.

        

        


        

        
Btw, what is the due date for
          providing the comments for this draft?

        


        

        
Best regards,

        


        

        
/Misha

      

      


        
2017-01-12 20:16 GMT+03:00 Steve
          Donovan <srdonovan@usdonovans.com>:

          

            
 Misha,

              

              I've added the DIME WG mailing list.

              

              See my comments inline.

              

              Regars,

              

              Steve

                

                
On
                  1/11/17 12:03 PM, Misha Zaytsev wrote:

                

                

                  
Hi Steve,
                    


                    

                    
I'm a newcomer in DiME working group - so, may
                      not be familiar with all rules.

                    
So, excuse me in advance if it is not a good
                      manner to comment the ongoing draft review.

                  

                

               SRD> Welcome to the working group!

                

                  

                    


                    

                    
But let me still put my 5 cents here.

                    


                    

                    
Regarding this question from Stephen:

                    


                    

                    
- 6.2: What is a
                        Diameter "connection?" I thought that

                      Diameter could use
                        UDP as well as TCP so is that really

                      the right term?
                        Maybe "message sender" is a better way to=


                      identify the peer?

                    

                    


                      

                    
Why can't we
                        re-phrase the related statement in the following
                        way?

                    


                      

                    

                      
This is achieved by compar=
ing Origin-Host AVP with SourceID AVP in the Load report.

                    

                    


                    

                  

                

               SRD> This actually doesn't work for the peer
              report case.=C2=A0 The Origin-Host AVP is inserted by the
              Diameter client and it remains the same as the request
              passes through Diameter agents.=C2=A0 For peer reports, it is
              necessary to know the peer that sent the request, not the
              client.=C2=A0 Thus the need to look at the DiameterID
              associated with the Diameter connection.

                

                

                  

                    
Also if it does not bother
                      you, could you explain what is the official way to
                      comment DiME drafts?

                  

                

               SRD> The official way is to do exactly what you
              are doing, but by sending the questions and comments to
              the DIME WG mailing list.
              

                


                  

                    

                      


                      

                      
Thanks a lot in advance!
                      


                      

                      
/Misha

                      


                      

                      


                      

                      


                        
2017-01-10 1:28
                          GMT+03:00 Steve Donovan <srdonovan@usdono=
vans.com>:

                          

                            

                              Stephen,

                              

                              Thanks for the review and for the ping.=C2=A0
                              Comments below.

                              

                              Regards,

                              

                              Steve

                                

                                
On
                                  1/6/17 10:33 AM, Stephen Farrell
                                  wrote:

                                

                                

                                  
Just bumping this, post holidays. I =
believe the
ball is not in my court for this one:-)

Cheers,
S.

On 16/12/16 17:38, Stephen Farrell wrote:


                                  

                                    
Hiya,

Thanks for getting this stuff progressed. I've done my
AD evaluation and have a few questions I'd like to ask
before starting IETF last call. Those are below along
with some more nitty comments that can be handled now or
later as the authors/WG prefer.

Cheers,
S.

Things to chat about before starting IETF LC:
---------------------------------------------

(1) Is "server selection" sufficiently clear? Where is
that defined? I was a bit confused as to what this means
that is not next-hop selection.

      

    

    SRD> Server selection is touched on in RFC7638 (DOIC) and the
    concept carries over to Load.=C2=A0 It refers to selection of the
    specific server instance that will be handling the request.=C2=A0 This =
is
    according to the Diameter Client, Server model.=C2=A0 I think it is wel=
l
    understood what is meant by those who understand Diameter and would
    be implementing this spec.=C2=A0 We can, if needed, add some definition=
.=C2=A0
    That would have been best do be in the DOIC RFC but it can go here
    if needed.

    

      

        
(2) PEER reports that are first received at a
non-supporting node will be left in place and will reach
the destination of the message. If that destination is in a
different domain then that leaks some internal structure
(the SourceID) to outsiders. Is that desirable?  Why not
have the first node that does support this AVP delete the
PEER report even if the node that added the PEER report is
not a peer of this node? (Note: I see this risk is ack'd
in section 8, I'm asking if we can avoid it almost
entirely by removing PEER reports that are useless.)

      

    

    SRD> There is no formal mechanism in place in Diameter to do
    "topology hiding".=C2=A0 There are many other places where to=
pology
    information can leak, so it isn't an issue specific to Load.=C2=A0 =
It is
    addressed today through proprietary implementations.

   =20

    SRD> Having a node that does not support would go against the
    Diameter extensibility strategy.=C2=A0 Nodes that don't understand =
an AVP
    are required to pass it on.=C2=A0 Nodes that do support the mechanism a=
nd
    see a Load report of type peer that isn't of type peer are supposed
    to remove it.=C2=A0 Doing anything other than this would require a chan=
ge
    to the base Diameter specification.

    

      

        
(3) This spec is a bit like RFC7944 (DRMP) in that it
defines some but not all of the things one needs to end up
with a workable system. That aspect of DRMP caused some
discussion during IESG evaluation. Have the authors of
this reviewed that discussion to see if we can avoid any
likely iterations being needed at that point? I'm hoping
that Steve, as an author of both, won't find this too
hard to do:-) If that's been done, great. If not, please
consider if there's any additional explanatory material
that could be added that might help us not to have to
iterate to discuss the same kinds of concern.

      

    

    SRD> I'll go back and review that discussion and see if there is
    something that needs to be added.=C2=A0 I'm hoping that the fact th=
at we
    made it through the discussion with DRMP will make it easier to do
    so with Load (and maybe agent overload).=C2=A0 I'm doubtful that we=
 can
    fully inoculate the draft from some of this level of discussion as
    we are dealing with Diameter here.

    

      

        
nits (fine to be considered last call comments):
-------------------------------------------------

      

    

    SRD> I'll deal with these as part of last call.


    

      

        
abstract: maybe put the 1st sentence last? that might read
better

4.1: the "opinion of the authors" isn't really of interest
at this point - is this also the opinion of the WG? (I
assume it is)

section 5 says "The load report includes a value
indicating the load of the sending node relative load of
the sending node, specified in a manner consistent with
that defined for DNS SRV [RFC2782]." I can't parse that.

- 6.2: What is a Diameter "connection?" I thought that
Diameter could use UDP as well as TCP so is that really
the right term? Maybe "message sender" is a better way to
identify the peer?

- section 8: "might require a transitive trust model" is
far too coy IMO. I think you should say that DOIC and this
entirely require transitive trust because we have no
Diameter mechanism that allows authenticated adding and
removal of AVPs as messages transit a network. (We did try
develop that ages ago but it was too complex, so I'm not
arguing to try again, just that we clearly ack the fact
that this stuff requires transitive trust.)




_______________________________________________
DiME mailing list
D=
iME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



      

     =20
     =20

      

     =20

      
_______________________________________________
DiME mailing list
D=
iME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


    

   =20

  



_______________________________________________

DiME mailing list

DiME@ietf.org

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
























--001a114102d86280a105461f23ce--


From nobody Sun Jan 15 22:19:36 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418FD129436 for ; Sun, 15 Jan 2017 22:19:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 5YQOWgdSzlLo for ; Sun, 15 Jan 2017 22:19:33 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 0460C12940B for ; Sun, 15 Jan 2017 22:19:33 -0800 (PST)
Received: from [12.198.235.13] (port=46413 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cT0dS-003YAF-MU; Sun, 15 Jan 2017 22:19:32 -0800
To: Misha Zaytsev 
References: <75a3dd19-bf69-5600-f439-0f544b65508d@cs.tcd.ie> <2ca7e5a2-c157-b548-c680-4c3b26e34112@cs.tcd.ie> <875060e8-aab3-1f75-39ed-615a364d466b@usdonovans.com>  <6c28f017-612e-3a17-8e23-5b4626d0f341@usdonovans.com>  <6b755a56-6183-97ff-d306-978a9dce8b3c@usdonovans.com> 
From: Steve Donovan 
Message-ID: 
Date: Sun, 15 Jan 2017 22:19:18 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E1C4F0A553EAAEE3A249D8B5"
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Cc: "dime@ietf.org" 
Subject: Re: [Dime] AD evaluation of draft-ietf-dime-load-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Jan 2017 06:19:35 -0000

This is a multi-part message in MIME format.
--------------E1C4F0A553EAAEE3A249D8B5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Misha,

Thank you for the very detailed review of the draft.  See my comments 
inline.

Regards,

Steve

On 1/15/17 2:00 AM, Misha Zaytsev wrote:
> Hi Steve,
>
> Sure, you can treat it as you wish since it is just a minor comment 
> from my side.
> However, I have other comments/questions to address:
>
> 0. general (editorial) Proposals regarding wording in the spec:
> - Use either "fulfil" or "fulfill" even if both forms are possible
Agreed, I'll update in the next release.
> - Use "remove"/"discard" instead of "strip" since it seems to be more 
> formal
This is a matter of preference and I prefer strip. :-)
>
> 1. section 4.1 (editorial)
> -  "did not had" -> "did not have"
> - "reacting node reduce" -> "reacting node reduce*s*"
Agreed, I'll update accordingly.
>
> 2. general (question): Why is different writing used for the same 
> terms through the spec?
> Example#1, "Load report" and "load report"
> Example#2, "report of type peer" and "load report of PEER"
> Example#3, "Diameter agent" and "Diameter Agent"
> Is this intentional? If yes, please clarify the intention.
This is a good point.  I'll update accordingly.
>
> 3. section 5 (editorial)
>
> The load report includes a value indicating the load of the sending
>     node relative load of the sending node, specified in a manner
>     consistent with that defined for DNS SRV [RFC2782].
> Should not be re-phrased a little bit in this way  - "...a value 
> indicating the relative load of the sending node, specified..."?
>
Yes, that is more clear.
> 4. section 5 (editorial): "weigh" -> "weigh*t*"
>
> The distribution algorithm used by Diameter nodes supporting the
>     Diameter Load mechanism is an implementation decision but it needs to
>     result in similar behavior to the algorithm described for the use of
>     weight values specified in [RFC2782].
>
Agreed
> 5. section 5 (question)
>
> The second type of load report is a peer report.  This report is used
>     by Diameter nodes as part of the logic to select the next-hop
>     Diameter node and, as such, does not have significance beyond the
>     peer node.  These load reports are removed by the first supporting
>     Diameter node to receive the report.
> Under "These load reports are removed..." the report of type PEER is 
> meant, right?
> Probably it is better to re-phrase this statement saying more explicitly:
> "The report of type PEER is removed by the first Diameter node 
> supporting Load mechanism."
The paragraph is talking about peer reports so I don't think there is 
any ambiguity.  However, I will update the last sentence to be clear it 
is referring to PEER reports.
>
> 6. section 6.1.2 (editorial) "insures" -> "*e*nsures"
>
> Note: In the case of peer load reports it is only necessary to
>        include load reports when the load value has changed by some
>        meaningful value, as long as the agent*e*nsures that all peers
>        receive the report.  It is also acceptable to include the load
>        report in every answer message handled by the Diameter agent.
>
Agreed
> 7. section 6.2 (editorial) "weigth" -> "weight"
>
> How a Diameter node uses load information for making routing
>     decisions is an implementation decision.  However, the distribution
>     algorithm MUST result in similar behavior as the algorithm described
>     for the use of weig*ht*  values in [RFC2782].
>
Agreed
> 8. section 6.4 (editorial) "Addition and removal of Nodes" -> 
> "Addition and Removal of Nodes"
Agreed
>
> 9. general. I'm voting for that the term "server selection" would be 
> defined explicitly in the spec.
> You answered on the comment from Stephen that this term came from RFC7683.
> But I have found only one place where it is mentioned: Appendix B, 
> "Non-supporting Agents".
I'll add a definition to the next version.
>
> Thanks a lot in advance.
>
> /Misha
>
> 2017-01-13 0:06 GMT+03:00 Steve Donovan  >:
>
>     Misha,
>
>     This draft has completed working group last call, so to some
>     degree the comment period has passed.  That said, there are no
>     hard and fast rules and we can certainly make changes that improve
>     the draft.  However, once it gets into IESG review, which is the
>     next step, it will be more difficult to make significant changes.
>
>     On your comment below, I don't see the need for the change.  I am
>     willing, however, to qualify the word connection to say "Diameter
>     connection".
>
>     Regards,
>
>     Steve
>
>     On 1/12/17 11:51 AM, Misha Zaytsev wrote:
>>     Hi Steve,
>>
>>     Thanks a lot for your explanation!
>>     My bad that I have not read the draft more carefully - will try
>>     to avoid this next time.
>>
>>     Then I can propose another version of statement that will exclude
>>     confusing "connection" term.
>>
>>>     This is achieved by comparing SourceID AVP in the Load report with host identity field of the entries from peer table defined in RFC6733.
>>
>>     If SourceID AVP contains the identity of one of the peer nodes
>>     (that our node has a direct connection to), then this is what we
>>     are looking for, right?
>>
>>     However, I find the term "connection" legal as it is defined in
>>     RFC6733, for instance section 5.1 "Peer Connections".
>>
>>     Or it can be easily re-phrased in this way, the term "peer"
>>     should not confuse anyone, I guess :)
>>
>>     This is achieved by comparing the DiameterIdentity of the peer from which the message was received with the
>>     DiameterIdentity included in the SourceID AVP in the Load report.
>>
>>     Btw, what is the due date for providing the comments for this draft?
>>
>>     Best regards,
>>
>>     /Misha
>>
>>     2017-01-12 20:16 GMT+03:00 Steve Donovan
>>     >:
>>
>>         Misha,
>>
>>         I've added the DIME WG mailing list.
>>
>>         See my comments inline.
>>
>>         Regars,
>>
>>         Steve
>>
>>         On 1/11/17 12:03 PM, Misha Zaytsev wrote:
>>>         Hi Steve,
>>>
>>>         I'm a newcomer in DiME working group - so, may not be
>>>         familiar with all rules.
>>>         So, excuse me in advance if it is not a good manner to
>>>         comment the ongoing draft review.
>>         SRD> Welcome to the working group!
>>>
>>>         But let me still put my 5 cents here.
>>>
>>>         Regarding this question from Stephen:
>>>
>>>         - 6.2: What is a Diameter "connection?" I thought that
>>>         Diameter could use UDP as well as TCP so is that really
>>>         the right term? Maybe "message sender" is a better way to
>>>         identify the peer?
>>>
>>>         Why can't we re-phrase the related statement in the
>>>         following way?
>>>
>>>         This is achieved by comparing Origin-Host AVP with SourceID AVP in the Load report.
>>>
>>         SRD> This actually doesn't work for the peer report case. 
>>         The Origin-Host AVP is inserted by the Diameter client and it
>>         remains the same as the request passes through Diameter
>>         agents.  For peer reports, it is necessary to know the peer
>>         that sent the request, not the client.  Thus the need to look
>>         at the DiameterID associated with the Diameter connection.
>>
>>>         Also if it does not bother you, could you explain what is
>>>         the official way to comment DiME drafts?
>>         SRD> The official way is to do exactly what you are doing,
>>         but by sending the questions and comments to the DIME WG
>>         mailing list.
>>
>>>
>>>         Thanks a lot in advance!
>>>
>>>         /Misha
>>>
>>>
>>>
>>>         2017-01-10 1:28 GMT+03:00 Steve Donovan
>>>         >:
>>>
>>>             Stephen,
>>>
>>>             Thanks for the review and for the ping.  Comments below.
>>>
>>>             Regards,
>>>
>>>             Steve
>>>
>>>             On 1/6/17 10:33 AM, Stephen Farrell wrote:
>>>>             Just bumping this, post holidays. I believe the
>>>>             ball is not in my court for this one:-)
>>>>
>>>>             Cheers,
>>>>             S.
>>>>
>>>>             On 16/12/16 17:38, Stephen Farrell wrote:
>>>>>             Hiya,
>>>>>
>>>>>             Thanks for getting this stuff progressed. I've done my
>>>>>             AD evaluation and have a few questions I'd like to ask
>>>>>             before starting IETF last call. Those are below along
>>>>>             with some more nitty comments that can be handled now or
>>>>>             later as the authors/WG prefer.
>>>>>
>>>>>             Cheers,
>>>>>             S.
>>>>>
>>>>>             Things to chat about before starting IETF LC:
>>>>>             ---------------------------------------------
>>>>>
>>>>>             (1) Is "server selection" sufficiently clear? Where is
>>>>>             that defined? I was a bit confused as to what this means
>>>>>             that is not next-hop selection.
>>>             SRD> Server selection is touched on in RFC7638 (DOIC)
>>>             and the concept carries over to Load.  It refers to
>>>             selection of the specific server instance that will be
>>>             handling the request.  This is according to the Diameter
>>>             Client, Server model.  I think it is well understood
>>>             what is meant by those who understand Diameter and would
>>>             be implementing this spec.  We can, if needed, add some
>>>             definition. That would have been best do be in the DOIC
>>>             RFC but it can go here if needed.
>>>>>             (2) PEER reports that are first received at a
>>>>>             non-supporting node will be left in place and will reach
>>>>>             the destination of the message. If that destination is in a
>>>>>             different domain then that leaks some internal structure
>>>>>             (the SourceID) to outsiders. Is that desirable?  Why not
>>>>>             have the first node that does support this AVP delete the
>>>>>             PEER report even if the node that added the PEER report is
>>>>>             not a peer of this node? (Note: I see this risk is ack'd
>>>>>             in section 8, I'm asking if we can avoid it almost
>>>>>             entirely by removing PEER reports that are useless.)
>>>             SRD> There is no formal mechanism in place in Diameter
>>>             to do "topology hiding".  There are many other places
>>>             where topology information can leak, so it isn't an
>>>             issue specific to Load.  It is addressed today through
>>>             proprietary implementations. SRD> Having a node that
>>>             does not support would go against the Diameter
>>>             extensibility strategy.  Nodes that don't understand an
>>>             AVP are required to pass it on.  Nodes that do support
>>>             the mechanism and see a Load report of type peer that
>>>             isn't of type peer are supposed to remove it.  Doing
>>>             anything other than this would require a change to the
>>>             base Diameter specification.
>>>>>             (3) This spec is a bit like RFC7944 (DRMP) in that it
>>>>>             defines some but not all of the things one needs to end up
>>>>>             with a workable system. That aspect of DRMP caused some
>>>>>             discussion during IESG evaluation. Have the authors of
>>>>>             this reviewed that discussion to see if we can avoid any
>>>>>             likely iterations being needed at that point? I'm hoping
>>>>>             that Steve, as an author of both, won't find this too
>>>>>             hard to do:-) If that's been done, great. If not, please
>>>>>             consider if there's any additional explanatory material
>>>>>             that could be added that might help us not to have to
>>>>>             iterate to discuss the same kinds of concern.
>>>             SRD> I'll go back and review that discussion and see if
>>>             there is something that needs to be added.  I'm hoping
>>>             that the fact that we made it through the discussion
>>>             with DRMP will make it easier to do so with Load (and
>>>             maybe agent overload).  I'm doubtful that we can fully
>>>             inoculate the draft from some of this level of
>>>             discussion as we are dealing with Diameter here.
>>>>>             nits (fine to be considered last call comments):
>>>>>             -------------------------------------------------
>>>             SRD> I'll deal with these as part of last call.
>>>>>             abstract: maybe put the 1st sentence last? that might read
>>>>>             better
>>>>>
>>>>>             4.1: the "opinion of the authors" isn't really of interest
>>>>>             at this point - is this also the opinion of the WG? (I
>>>>>             assume it is)
>>>>>
>>>>>             section 5 says "The load report includes a value
>>>>>             indicating the load of the sending node relative load of
>>>>>             the sending node, specified in a manner consistent with
>>>>>             that defined for DNS SRV [RFC2782]." I can't parse that.
>>>>>
>>>>>             - 6.2: What is a Diameter "connection?" I thought that
>>>>>             Diameter could use UDP as well as TCP so is that really
>>>>>             the right term? Maybe "message sender" is a better way to
>>>>>             identify the peer?
>>>>>
>>>>>             - section 8: "might require a transitive trust model" is
>>>>>             far too coy IMO. I think you should say that DOIC and this
>>>>>             entirely require transitive trust because we have no
>>>>>             Diameter mechanism that allows authenticated adding and
>>>>>             removal of AVPs as messages transit a network. (We did try
>>>>>             develop that ages ago but it was too complex, so I'm not
>>>>>             arguing to try again, just that we clearly ack the fact
>>>>>             that this stuff requires transitive trust.)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>             _______________________________________________
>>>>>             DiME mailing list
>>>>>             DiME@ietf.org 
>>>>>             https://www.ietf.org/mailman/listinfo/dime
>>>>>             
>>>>>
>>>>             _______________________________________________
>>>>             DiME mailing list
>>>>             DiME@ietf.org 
>>>>             https://www.ietf.org/mailman/listinfo/dime
>>>>             
>>>             _______________________________________________ DiME
>>>             mailing list DiME@ietf.org 
>>>             https://www.ietf.org/mailman/listinfo/dime
>>>              
>>>

--------------E1C4F0A553EAAEE3A249D8B5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Misha,

    

    Thank you for the very detailed review of the draft.  See my
    comments inline.

    

    Regards,

    

    Steve

    

    
On 1/15/17 2:00 AM, Misha Zaytsev
      wrote:

    

    

      
Hi Steve,
        


        

        
Sure, you can treat it as you wish since it is just a minor
          comment from my side.

        
However, I have other comments/questions to address:

        


        

        
0. general (editorial) Proposals regarding wording in the
          spec:

        
- Use either "fulfil" or "fulfill" even if both forms are
          possible

      

    

    Agreed, I'll update in the next release.

    

      

        
- Use "remove"/"discard" instead of "strip" since it seems
          to be more formal

      

    

    This is a matter of preference and I prefer strip. :-)

    

      

        


        

        
1. section 4.1 (editorial)

        
-  "did not had" -> "did not have"

        
- "reacting node reduce" -> "reacting node reduces"

      

    

    Agreed, I'll update accordingly.

    

      

        


        

        
2. general (question): Why is different writing used for
          the same terms through the spec?

        
Example#1, "Load report" and "load report"

        
Example#2, "report of type peer" and "load report of PEER"

        
Example#3, "Diameter agent" and "Diameter Agent"

        
Is this intentional? If yes, please clarify the intention.
          

        

      

    

    This is a good point.  I'll update accordingly.

    

      

        


        

        
3. section 5 (editorial)

        


        

        

          
The load report includes a value indicating the load of the sending
   node relative load of the sending node, specified in a manner
   consistent with that defined for DNS SRV [RFC2782].

        

        
Should not be re-phrased a little bit in this way  - "...a
          value indicating the relative load of the sending node,
          specified..."?

        


        

      

    

    Yes, that is more clear.

    

      

        
4. section 5 (editorial): "weigh" -> "weight"

        


        

        

          
The distribution algorithm used by Diameter nodes supporting the
   Diameter Load mechanism is an implementation decision but it needs to
   result in similar behavior to the algorithm described for the use of
   weight values specified in [RFC2782].

        

        


        

      

    

    Agreed

    

      

        
5. section 5 (question)

        


        

        

          
The second type of load report is a peer report.  This report is used
   by Diameter nodes as part of the logic to select the next-hop
   Diameter node and, as such, does not have significance beyond the
   peer node.  These load reports are removed by the first supporting
   Diameter node to receive the report.

        

        
Under "These load reports are removed..." the report of
          type PEER is meant, right?

        
Probably it is better to re-phrase this statement saying
          more explicitly:

        
"The report of type PEER is removed by the first Diameter
          node supporting Load mechanism."

      

    

    The paragraph is talking about peer reports so I don't think there
    is any ambiguity.  However, I will update the last sentence to be
    clear it is referring to PEER reports. 

    

      

        


        

        
6. section 6.1.2 (editorial) "insures" -> "ensures"

        


        

        

          
Note: In the case of peer load reports it is only necessary to
      include load reports when the load value has changed by some
      meaningful value, as long as the agent ensures that all peers
      receive the report.  It is also acceptable to include the load
      report in every answer message handled by the Diameter agent.

        

        


        

      

    

    Agreed

    

      

        
7. section 6.2 (editorial) "weigth" -> "weight"

        


        

        

          
How a Diameter node uses load information for making routing
   decisions is an implementation decision.  However, the distribution
   algorithm MUST result in similar behavior as the algorithm described
   for the use of weight values in [RFC2782].

        

        


        

      

    

    Agreed

    

      

        
8. section 6.4 (editorial) "Addition and removal of Nodes"
          -> "Addition and Removal of Nodes"

      

    

    Agreed

    

      

        


        

        
9. general. I'm voting for that the term "server selection"
          would be defined explicitly in the spec.

        
You answered on the comment from Stephen that this term
          came from RFC7683.

        
But I have found only one place where it is mentioned:
          Appendix B, "Non-supporting Agents".

      

    

    I'll add a definition to the next version.

    

      

        


        

        
Thanks a lot in advance.

        


        

        
/Misha

      

      


        
2017-01-13 0:06 GMT+03:00 Steve Donovan
          <srdonovan@usdonovans.com>:

          

            
 Misha,

              

              This draft has completed working group last call, so to
              some degree the comment period has passed.  That said,
              there are no hard and fast rules and we can certainly make
              changes that improve the draft.  However, once it gets
              into IESG review, which is the next step, it will be more
              difficult to make significant changes.

              

              On your comment below, I don't see the need for the
              change.  I am willing, however, to qualify the word
              connection to say "Diameter connection".

              

              Regards,

              

              Steve  

              

                
 

                  
On
                    1/12/17 11:51 AM, Misha Zaytsev wrote:

                  

                  

                    
Hi
                        Steve,
                      


                      

                      
Thanks a lot for
                        your explanation!

                      
My bad that I have
                        not read the draft more carefully - will try to
                        avoid this next time.

                      


                      

                      
Then I can propose
                        another version of statement that will exclude
                        confusing "connection" term.

                      


                      

                      

                        

                          

                            
This is achieved by comparing SourceID AVP in the Load report with host identity field of the entries from peer table defined in RFC6733.

                          

                        

                      

                      


                      

                      
If SourceID AVP
                        contains the identity of one of the peer nodes
                        (that our node has a direct connection to), then
                        this is what we are looking for, right?

                      


                      

                      
However, I find the
                        term "connection" legal as it is defined in
                        RFC6733, for instance section 5.1 "Peer
                        Connections".

                      


                      

                      
Or it can be easily
                        re-phrased in this way, the term "peer" should
                        not confuse anyone, I guess :)

                      


                      

                      

                        
This is achieved by comparing the DiameterIdentity of the peer from which the message was received with the
DiameterIdentity included in the SourceID AVP in the Load report.

                      

                      


                      

                      
Btw, what is the due
                        date for providing the comments for this draft?

                      


                      

                      
Best regards,

                      


                      

                      
/Misha

                    

                    


                      
2017-01-12 20:16
                        GMT+03:00 Steve Donovan <srdonovan@usdonovans.com>:

                        

                          
 Misha,

                            

                            I've added the DIME WG mailing list.

                            

                            See my comments inline.

                            

                            Regars,

                            

                            Steve

                              

                              
On
                                1/11/17 12:03 PM, Misha Zaytsev wrote:

                              

                              

                                
Hi Steve,
                                  


                                  

                                  
I'm a newcomer in DiME working
                                    group - so, may not be familiar with
                                    all rules.

                                  
So, excuse me in advance if it is
                                    not a good manner to comment the
                                    ongoing draft review.

                                

                              

                             SRD> Welcome to the working
                            group!

                              

                                

                                  


                                  

                                  
But let me still put my 5 cents
                                    here.

                                  


                                  

                                  
Regarding this question from
                                    Stephen:

                                  


                                  

                                  
-
                                      6.2: What is a Diameter
                                      "connection?" I thought that

                                    Diameter
                                      could use UDP as well as TCP so is
                                      that really

                                    the
                                      right term? Maybe "message sender"
                                      is a better way to

                                    identify
                                      the peer?

                                  

                                  


                                    

                                  
Why
                                      can't we re-phrase the related
                                      statement in the following way?

                                  


                                    

                                  

                                    
This is achieved by comparing Origin-Host AVP with SourceID AVP in the Load report.

                                  

                                  


                                  

                                

                              

                             SRD> This actually doesn't work
                            for the peer report case.  The Origin-Host
                            AVP is inserted by the Diameter client and
                            it remains the same as the request passes
                            through Diameter agents.  For peer reports,
                            it is necessary to know the peer that sent
                            the request, not the client.  Thus the need
                            to look at the DiameterID associated with
                            the Diameter connection.

                              

                              

                                

                                  
Also if it
                                    does not bother you, could you
                                    explain what is the official way to
                                    comment DiME drafts?

                                

                              

                             SRD> The official way is to do
                            exactly what you are doing, but by sending
                            the questions and comments to the DIME WG
                            mailing list.
                            

                              


                                

                                  

                                    


                                    

                                    
Thanks a
                                      lot in advance!

                                    


                                    

                                    
/Misha

                                    


                                    

                                    


                                    

                                    


                                      
2017-01-10
                                        1:28 GMT+03:00 Steve Donovan <srdonovan@usdonovans.com>:

                                        

                                          
 Stephen,

                                            

                                            Thanks for the review and
                                            for the ping.  Comments
                                            below.

                                            

                                            Regards,

                                            

                                            Steve

                                              

                                              
On
                                                1/6/17 10:33 AM, Stephen
                                                Farrell wrote:

                                              

                                              

                                                
Just bumping this, post holidays. I believe the
ball is not in my court for this one:-)

Cheers,
S.

On 16/12/16 17:38, Stephen Farrell wrote:


                                                

                                                  
Hiya,

Thanks for getting this stuff progressed. I've done my
AD evaluation and have a few questions I'd like to ask
before starting IETF last call. Those are below along
with some more nitty comments that can be handled now or
later as the authors/WG prefer.

Cheers,
S.

Things to chat about before starting IETF LC:
---------------------------------------------

(1) Is "server selection" sufficiently clear? Where is
that defined? I was a bit confused as to what this means
that is not next-hop selection.

      

    

    SRD> Server selection is touched on in RFC7638 (DOIC) and the
    concept carries over to Load.  It refers to selection of the
    specific server instance that will be handling the request.  This is
    according to the Diameter Client, Server model.  I think it is well
    understood what is meant by those who understand Diameter and would
    be implementing this spec.  We can, if needed, add some definition. 
    That would have been best do be in the DOIC RFC but it can go here
    if needed.

    

      

        
(2) PEER reports that are first received at a
non-supporting node will be left in place and will reach
the destination of the message. If that destination is in a
different domain then that leaks some internal structure
(the SourceID) to outsiders. Is that desirable?  Why not
have the first node that does support this AVP delete the
PEER report even if the node that added the PEER report is
not a peer of this node? (Note: I see this risk is ack'd
in section 8, I'm asking if we can avoid it almost
entirely by removing PEER reports that are useless.)

      

    

    SRD> There is no formal mechanism in place in Diameter to do
    "topology hiding".  There are many other places where topology
    information can leak, so it isn't an issue specific to Load.  It is
    addressed today through proprietary implementations.

    

    SRD> Having a node that does not support would go against the
    Diameter extensibility strategy.  Nodes that don't understand an AVP
    are required to pass it on.  Nodes that do support the mechanism and
    see a Load report of type peer that isn't of type peer are supposed
    to remove it.  Doing anything other than this would require a change
    to the base Diameter specification.

    

      

        
(3) This spec is a bit like RFC7944 (DRMP) in that it
defines some but not all of the things one needs to end up
with a workable system. That aspect of DRMP caused some
discussion during IESG evaluation. Have the authors of
this reviewed that discussion to see if we can avoid any
likely iterations being needed at that point? I'm hoping
that Steve, as an author of both, won't find this too
hard to do:-) If that's been done, great. If not, please
consider if there's any additional explanatory material
that could be added that might help us not to have to
iterate to discuss the same kinds of concern.

      

    

    SRD> I'll go back and review that discussion and see if there is
    something that needs to be added.  I'm hoping that the fact that we
    made it through the discussion with DRMP will make it easier to do
    so with Load (and maybe agent overload).  I'm doubtful that we can
    fully inoculate the draft from some of this level of discussion as
    we are dealing with Diameter here.

    

      

        
nits (fine to be considered last call comments):
-------------------------------------------------

      

    

    SRD> I'll deal with these as part of last call.


    

      

        
abstract: maybe put the 1st sentence last? that might read
better

4.1: the "opinion of the authors" isn't really of interest
at this point - is this also the opinion of the WG? (I
assume it is)

section 5 says "The load report includes a value
indicating the load of the sending node relative load of
the sending node, specified in a manner consistent with
that defined for DNS SRV [RFC2782]." I can't parse that.

- 6.2: What is a Diameter "connection?" I thought that
Diameter could use UDP as well as TCP so is that really
the right term? Maybe "message sender" is a better way to
identify the peer?

- section 8: "might require a transitive trust model" is
far too coy IMO. I think you should say that DOIC and this
entirely require transitive trust because we have no
Diameter mechanism that allows authenticated adding and
removal of AVPs as messages transit a network. (We did try
develop that ages ago but it was too complex, so I'm not
arguing to try again, just that we clearly ack the fact
that this stuff requires transitive trust.)




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



      

      
      

      

      

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


    

    

  



_______________________________________________

DiME mailing list

DiME@ietf.org

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






























--------------E1C4F0A553EAAEE3A249D8B5--


From nobody Tue Jan 17 12:23:58 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1109129480; Tue, 17 Jan 2017 12:23:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6L9Iq7dYWv7; Tue, 17 Jan 2017 12:23:47 -0800 (PST)
Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D30D12946E; Tue, 17 Jan 2017 12:23:44 -0800 (PST)
Received: by mail-lf0-x244.google.com with SMTP id q89so17729617lfi.1; Tue, 17 Jan 2017 12:23:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XfiFnfvk/H/rNNLWg+p/xKYiRmvuQ1/Jmoj6PzpmyCs=; b=fMbgoKGjoJICSP7VGQnRhhWvliRu3JwbppZBsgpYuIK7VfRW4zC8s5V/xgCRv32vQf sjpcZ51L2LYsBgruVdwlFYGb5iah6B0x/0iqag9LR10n/kYpixS6lb+CvPJI1YFhsAwt aKkM83SVAW1AvWvj4sf3TuoymDX1t+HUy8ieFwsNoK672eUjyzVXkJjunfqdBSE9NOAJ WGaGrh2BXIPQLXqJp3S5VmJWPUAhMmPodwq0+FUa8ART3ndsu+PFgOU/M+pKYeFFnfuI Kdt4okalbomyfqHtf3MdVSAuDm0gxt81nmy3nPEJE1vUpnzRUFNxi0G90BvEW0zxRfbe uBBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XfiFnfvk/H/rNNLWg+p/xKYiRmvuQ1/Jmoj6PzpmyCs=; b=fV4fNZfe7EGqCzp1/DIp7gRu34ZEZodlj/HjHz5vnov1FK2tvF83edxLTxQHbJEGdJ bFoup/m01ZOqLFjO6AGHCGVL4wNHU66EpDCe/d/hRi4WjoUFCmkiNmAW7aBi6qBeQDUK XQaktKs+i7KiONRyDWqfzrideviflWY81TOPS5MulqQGDXkoVcHiyn8VAlfA21OhITjl GnQJpJ9YDQjs+dMQ8nLuYOMPVG5WLlG8YFTJgUc/4aRewM5Vcz6Wvi9xw8Yi/4laiXzh 4Wx+De2+/tbfUWEQvJxXlcNaxVnpSwLBBg86vIJHB+ZfzEB0T3TjSjPmDEV2hu4V4xeq wK3Q==
X-Gm-Message-State: AIkVDXJu8Ubhnwo/GUbZ2pFwlucwBqZYMvQpgYq928UV9GihI49louP5BFWlZhwMQeiyp46GE8Ex6A5yodC0mA==
X-Received: by 10.25.145.89 with SMTP id y25mr9235781lfj.102.1484684622070; Tue, 17 Jan 2017 12:23:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Tue, 17 Jan 2017 12:23:41 -0800 (PST)
In-Reply-To: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com>
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com>
From: Misha Zaytsev 
Date: Tue, 17 Jan 2017 23:23:41 +0300
Message-ID: 
To: ietf@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c1cd53e8088760546501355
Archived-At: 
Cc: dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-agent-overload@ietf.org, IETF-Announce 
Subject: Re: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jan 2017 20:23:51 -0000

--94eb2c1cd53e8088760546501355
Content-Type: text/plain; charset=UTF-8

Hi All,

Here are my comments/questions to an agent overload draft.
This the first part. Later on I will complete my review and send out the
second portion of the comments.

1. section 1 (editorial) removed "is" before "feasible".

In the base specification, the goal is to handle abatement of the
   overload occurrence as close to the source of the Diameter traffic as
   feasible.


"scenaios" -> "scenarios"

The Peer overload report type is
   defined in a generic fashion so that it can also be used for other
   Diameter overload *scenarios*.


2. section 3.1.1 (editorial) replaced "were"-> "was"

In both of these cases, the occurrence of overload in the single
   agent must by handled by the client in a similar fashion as if the
   client *was* handling the overload of a directly connected server.


3. section 3.1.1 (question)

An appropriate error response is sent back to the originator
   of the request.

Who sends "an appropriate" error response" in this case?

4. section 3.1.2 (editorial) changed "to"->"the"

When the client has an active and a standby connection to the two
   agents then an alternative strategy for responding to an overload
   report from an agent is to change *the *standby connection to active and
   route all traffic through the new active connection.


5. section 3.1.3 (editorial)

An example of this type of deployment include*s* when there are Diameter
   agents between administrative domains.

6. section 3.1.3

There is no section 2.2. I guess section 3.1.2 was meant here, right?

Handling of overload of one or both of agents a11 or a12 in this case
   is equivalent to that discussed in section 2.2.


7. section 3.2.1

It is not clear which usage scenario is meant here.

   It is envisioned that abatement algorithms will be defined that will
   support the option for Diameter Endpoints to send peer reports.  For
   instance, it is envisioned that one usage scenario for the rate
   algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
   on by the DIME working group as this document is being written, will
   involve abatement being done on a hop-by-hop basis.


8. section 4

Why is throttling to be applied and not diversion (like in case of
redundant agents)?

In this scenario the reacting node should first handle the throttling of the
   overloaded host or realm.

"LOSS" Is it a new type defined in the scope of this draft?

Note: The goal is to avoid traffic oscillations that might result
      from throttling of messages for both the HOST/REALM overload
      reports and the PEER overload reports.  This is especially a
      concern if *both reports are of type LOSS*.


9. section 5.1.1

Probably it is better to describe OC_PEER_REPORT feature in section 5.1?
Otherwise, it is used as a well-known one while it is the first place where
it is mentioned.

Also I think it is better to add more specific in this draft related to
peer report handling:
- define Peer Report Reacting Node and Peer Report Reporting Node terms
explicitly and use them through the draft and especially starting from
section 5.1
- add "Peer Report" prefix to all the described procedures
Example: Capability Announcement -> Peer Report Capability Announcement

10. section 5.1.1/general

"DiameterIdentity" and "Diameter identity"
My proposal is to use one term through the spec.

Under "DOIC node", an agent is meant here?

 When an agent relays a request that includes a SourceID AVP in the
   OC-Supported-Features AVP, a DOIC node that supports the
   OC_PEER_REPORT feature MUST remove the received SourceID AVP and
   replace it with a SourceID AVP containing its own Diameter identity.


My proposal is to use peer report reacting node here re-phrasing this
statement below in the following way:

 When relaying a request that includes a SourceID AVP in the
   OC-Supported-Features AVP, a peer report reacting node MUST remove
the received SourceID AVP and
   replace it with a SourceID AVP containing its own DiameterIdentity.

11. section 5.1.2

added the missed "to"
changed "PEER_REPORT"-> "PEER"

Note: The transaction state is used when the DOIC node is acting
      as a peer-report reporting node and needs *to *send OC-OLR reports of
      type *PEER *in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.


"Diameter ID" term is not clarified anywhere.
Re-phrased the appropriate statement a little bit, changed "Diameter
ID"->"value"
Also there are other places in the draft where "Diameter ID" term is used.

The peer supports the OC_PEER_REPORT feature if the received request
   contains an OC-Supported-Features AVP with the OC-Feature-Vector with
   the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
   value that matches the DiameterIdentity of the peer from which
   the request was received.


Agent is meant under "reporting node" here?

Should not SourceID AVP not just stripped from the relayed answer, but
replaced with the SourceID AVP containing the DiameterIdentity of the agent
supporting OC_PEER_REPORT feature?

When an agent relays an answer message, a reporting node that
   supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
   the OC-Supported-Features AVP.


Hard to follow what was wanted to say here:
Corrected the statement, but this is just my best guess.

The OC-Peer-Algo AVP MUST indicate the overload abatement
   algorithm that the reporting node wants the reacting nodes to use
   *when *the reporting node send*s* a peer overload report as a result of
   becoming overloaded.


Should not we add a separate if- statement for the case when the peer does
not support OC_PEER_REPORT feature when sending an answer message?

12. section 5.1.1 and 5.1.2

Probably it is more helpful to illustrate OC_PEER_REPORT feature CA using
sequence diagrams like in the load info conveyance draft.

13. general.

What about to use the writing for the same terms through the spec?
Example1: "DOIC node" and "DOIC Node"
Example2: "peer-report reporting node" and "peer report reporting node"

14. section 5.2.1.2, 5.2.2, 5.2.3 and general

"peer-type OCS" and "peer report OCS" define the same term?
Why not to use only one?

Another example: "peer report" and "peer report-type" and "report of type
PEER"

15. section 5.2.3

Probably it is better to re-phrase this statement a little bit + corrected
the misprints.

If a *peer report* reacting node receives an OC-OLR AVP of type peer and the
SourceID matches the *DiameterIdentity *of the peer from which the *report*
was received then the report was *generated *by the peer.


Similar comment + corrected misprints for the next statement:

If a peer report reacting node receives an OC-OLR AVP of type peer and the
SourceID does not match the *DiameterIdentity *of the peer from which
the*report *was received then the reacting node MUST ignore the
overload
report.


Also I think it is useful to use one wording for the same term:
"Peer Report OLR", "OC-OLR AVP", "OLR"
Let's use a generic one "peer report"?

Just minor comment: "the existing..." and "a new overload condition" for
all occurrences if my English is correct.

16. section 5.2.3

How may it happen that peer report reacting node receives a peer report not
from the peer that generated it?
Peer reports can be sent only to peer report reacting node, right? And peer
reports are not relayed, right?

Best regards,

/Misha


2017-01-09 17:35 GMT+03:00 The IESG :

>
> The IESG has received a request from the Diameter Maintenance and
> Extensions WG (dime) to consider the following document:
> - 'Diameter Agent Overload and the Peer Overload Report'
>    as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2017-01-23. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This specification documents an extension to RFC 7683 (Diameter
>    Overload Indication Conveyance (DOIC)) base solution.  The extension
>    defines the Peer overload report type.  The initial use case for the
>    Peer report is the handling of occurrences of overload of a Diameter
>    agent.
>
> Requirements
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>     draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload
> Control (None - )
> Note that some of these references may already be listed in the acceptable
> Downref Registry.
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

--94eb2c1cd53e8088760546501355
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi All,

Here are my comments/questions =
to an agent overload draft.
This the first part. Later on I will =
complete my review and send out the second portion of the comments.

1. section 1 (editorial) removed "is" befo=
re "feasible".

The Peer overload report type is
   defined in a generic fashion so that it can also be used for other
   Diameter overload scenarios.

2. se=
ction 3.1.1 (editorial) replaced "were"-> "was"

In both of these cases, the=
 occurrence of overload in the single
   agent must by handled by the client in a similar fashion as if the
   client was handling the overload of a directly connected server.<=
/pre>

3. section 3.1.1 (question)

An appropriate error response is sent b=
ack to the originator
   of the request.
Who sends "an appropriate" err=
or response" in this case?

4. section 3.1.2 (=
editorial) changed "to"->"the"

<=
div>
When the client has an active and a standby =
connection to the two
   agents then an alternative strategy for responding to an overload
   report from an agent is to change the standby connection to activ=
e and
   route all traffic through the new active connection.
5. section 3.1.3 (editorial)

An example of this type of deployment includes whe=
n there are Diameter
   agents between administrative domains.
6. section 3.1.3<=
/div>

There is no section 2.2. I guess section 3.1.2 was=
 meant here, right?

Han=
dling of overload of one or both of agents a11 or a12 in this case
   is equivalent to that discussed in section 2.2.

7. section 3.2.1

It is not clear which usag=
e scenario is meant here.

   It is envisioned that abatement algorithms will be defined that will
   support the option for Diameter Endpoints to send peer reports.  For
   instance, it is envisioned that one usage scenario for the rate
   algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
   on by the DIME working group as this document is being written, will
   involve abatement being done on a hop-by-hop basis.

=

8. section 4

Why is throttling to be ap=
plied and not diversion (like in case of redundant agents)?=C2=A0

In this scenario the reacting no=
de should first handle the throttling of the
   overloaded host or realm.
"LOSS" Is it a new t=
ype defined in the scope of this draft?

Note: The goal is to avoid traffic oscillations that might=
 result
      from throttling of messages for both the HOST/REALM overload
      reports and the PEER overload reports.  This is especially a
      concern if both reports are of type LOSS.

=

9. section 5.1.1

Probably it is better =
to describe OC_PEER_REPORT feature in section 5.1?
Otherwise, it =
is used as a well-known one while it is the first place where it is mention=
ed.

Also I think it is better to add more specific=
 in this draft related to peer report handling:
- define Peer Rep=
ort Reacting Node and Peer Report Reporting Node terms explicitly and use t=
hem through the draft and especially starting from section 5.1=C2=A0
- add "Peer Report" prefix to all the described procedure=
s
Example: Capability Announcement -> Peer Report Capability A=
nnouncement

10. section 5.1.1/general
"DiameterIdentity" and "Diameter identity"=

My proposal is to use one term through the spec.

<=
/div>
Under "DOIC node", an agent is meant here?
 When an agent relays a request tha=
t includes a SourceID AVP in the
   OC-Supported-Features AVP, a DOIC node that supports the
   OC_PEER_REPORT feature MUST remove the received SourceID AVP and
   replace it with a SourceID AVP containing its own Diameter identity.

My proposal is to use peer report reacting node=
 here re-phrasing this statement below in the following way:
=

 When relaying a request that inc=
ludes a SourceID AVP in the
   OC-Supported-Features AVP, a peer report reacting node MUST remove the r=
eceived SourceID AVP and
   replace it with a SourceID AVP containing its own DiameterIdentity.
11. section 5.1.2

added the missed &qu=
ot;to"
changed "PEER_REPORT"-> "PEER"=


Note: The transaction =
state is used when the DOIC node is acting
      as a peer-report reporting node and needs to send OC-OLR repor=
ts of
      type PEER in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.

&q=
uot;Diameter ID" term is not clarified anywhere.
Re-phrased =
the appropriate statement a little bit, changed "Diameter ID"->=
;"value"
Also there are other places in the draft where=
 "Diameter ID" term is used.

The peer supports the OC_PEER_REPORT feature if the receiv=
ed request
   contains an OC-Supported-Features AVP with the OC-Feature-Vector with
   the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
   value that matches the DiameterIdentity of the peer from which
   the request was received.

Agent is meant =
under "reporting node" here?

Should not =
SourceID AVP not just stripped from the relayed answer, but replaced with t=
he SourceID AVP containing the DiameterIdentity of the agent supporting OC_=
PEER_REPORT feature?

Wh=
en an agent relays an answer message, a reporting node that
   supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
   the OC-Supported-Features AVP.

Hard to fo=
llow what was wanted to say here:
Corrected the statement, but th=
is is just my best guess.

The OC-Peer-Algo AVP MUST indicate the overload abatement
   algorithm that the reporting node wants the reacting nodes to use
   when the reporting node sends a peer overload report as a =
result of
   becoming overloaded.

Should not we add a =
separate if- statement for the case when the peer does not support OC_PEER_=
REPORT feature when sending an answer message?

12.=
 section 5.1.1 and 5.1.2

Probably it is more helpf=
ul to illustrate OC_PEER_REPORT feature CA using sequence diagrams like in =
the load info conveyance draft.

13. general.
=


What about to use the writing for the same terms throug=
h the spec?
Example1: "DOIC node" and "DOIC Node&q=
uot;
Example2: "peer-report reporting node" and "p=
eer report reporting node"

14. section 5.2.1.=
2, 5.2.2, 5.2.3 and general

"peer-type OCS&qu=
ot; and "peer report OCS" define the same term?
Why not=
 to use only one?

Another example: "peer =
report" and "peer report-type" and "report of type PEER=
"

15. section 5.2.3

<=
div>Probably it is better to re-phrase this statement a little bit + correc=
ted the misprints.

If a=
 peer report reacting node receives an OC-OLR AVP of type peer and t=
he
SourceID matches the DiameterIdentity of the peer from which the =
report
was received then the report was generated by the peer.
<=
div>
Similar comment + corrected misprints for the next state=
ment:

If a peer report =
reacting node receives an OC-OLR AVP of type peer and the
SourceID does not match the DiameterIdentity of the peer from which =
the
report was received then the reacting node MUST ignore the overload
report.

Also I think it is useful to us=
e one wording for the same term:
"Peer Report OLR", &qu=
ot;OC-OLR AVP", "OLR"
Let's use a generic one =
"peer report"?

Just minor comment:=
 "the existing..." and "a new overload condition" for a=
ll occurrences if my English is correct.

16. secti=
on 5.2.3

How may it happen that peer report reacti=
ng node receives a peer report not from the peer that generated it?
Peer reports can be sent only to peer report reacting node, right? And p=
eer reports are not relayed, right?

Best regards,<=
/div>

/Misha


2017-01-09 17:35 GMT+03:00 The IES=
G <iesg-secretary@ietf.org>:


The IESG has received a request from the Diameter Maintenance and

Extensions WG (dime) to consider the following document:

- 'Diameter Agent Overload and the Peer Overload Report'

=C2=A0 <draft-ietf-dime-agent-overload-08.txt> as Proposed Stand=
ard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2017-01=
-23. Exceptionally, comments may be

sent to iesg@ietf.org instead. In eith=
er case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





=C2=A0 =C2=A0This specification documents an extension to RFC 7683 (Diamete=
r

=C2=A0 =C2=A0Overload Indication Conveyance (DOIC)) base solution.=C2=A0 Th=
e extension

=C2=A0 =C2=A0defines the Peer overload report type.=C2=A0 The initial use c=
ase for the

=C2=A0 =C2=A0Peer report is the handling of occurrences of overload of a Di=
ameter

=C2=A0 =C2=A0agent.



Requirements







The file can be obtained via

https://datatracker.ietf.org/do=
c/draft-ietf-dime-agent-overload/



IESG discussion can be tracked via

https://datatracker.ietf.org/=
doc/draft-ietf-dime-agent-overload/ballot/





No IPR declarations have been submitted directly on this I-D.





The document contains these normative downward references.

See RFC 3967 for additional information:

=C2=A0 =C2=A0 draft-roach-dime-overload-ctrl: A Mechanism for Diameter=
 Overload Control (None - )

Note that some of these references may already be listed in the acceptable =
Downref Registry.





_______________________________________________

DiME mailing list

DiME@ietf.org

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





--94eb2c1cd53e8088760546501355--


From nobody Tue Jan 17 13:24:39 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C391294BF; Tue, 17 Jan 2017 13:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1DSdV2akUnn; Tue, 17 Jan 2017 13:24:34 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 8668B1295B3; Tue, 17 Jan 2017 13:24:33 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id k86so118554073lfi.0; Tue, 17 Jan 2017 13:24:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vsfPH/C+4iydCVPRGSuVMM6afBPI1Xk/wAb7RfUW/NA=; b=svNKAp+lT8WTc6DoqTuVpf9Z3O2FX4HuVjvZ8UPn0U+MJGXUCc0vI69flyWbcRqasG JZVW2zmPOe5DURhNorYk19Pm8dBwSXH8+Nqp6zpN2Xgvs9v4iZiQujKvqJN0za77RM85 BzIIal3mmcd5HV39PH6aI87AM82vBxj8PTSbGvpz/Ix2rScilmVyVN248Fc14l03cXw5 ATQ1VVAzrhrLPPnYiN5Pq4qlXtsvdd+ctg0tTqd2lyXzfoR7E2FKUkzUOiuRSw3aJSGA 5BFEUdNBgHtkNyYeP16VhJJ+c2wACD8WXJhRE3xmmH/kv1jvYD66gfVN7neAqpZbUgop xxWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vsfPH/C+4iydCVPRGSuVMM6afBPI1Xk/wAb7RfUW/NA=; b=l9YDILGeeuBQCJRHZ6rkGW57Pw+qkinsQtU+IMFXpQf7+RRZsy7CUaCwh1Yangq8Uj RvEkRsunQRP2siHA6akBf6Pd5qZ9T655f1DsWRdtFVc5d8/ci1KXS926TDT343iuVLfb i4gBNJQJnXn2y7cNsj+p8Bv5QbVG3f176unzky4cjDo2qYL1UP5O8kyO/l3UCcPHmUj0 ugcp/9qwDd55nz7cBi7ZEZnLcDXO+sbfXt/JSFFZmvaKSj0516FyRZh4B7VDnvuSCz31 ACIXqpG2rtiCP4NBN+GlM64aA/dlvKIok8uxl5QPr3EIa/uTOf1J3h2oAnBe/un1o9jp DjRA==
X-Gm-Message-State: AIkVDXL1AMCZjVXHXJhO3ip8ByBcChzpneVlXMTug49L/4Cp2tSoqtiHmzdJkYgA78tBVM9HvYVU0cQ0sMR8Og==
X-Received: by 10.25.208.20 with SMTP id h20mr4382606lfg.150.1484688271595; Tue, 17 Jan 2017 13:24:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Tue, 17 Jan 2017 13:24:31 -0800 (PST)
In-Reply-To: 
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com>  
From: Misha Zaytsev 
Date: Wed, 18 Jan 2017 00:24:31 +0300
Message-ID: 
To: "Gunn, Janet P" 
Content-Type: multipart/alternative; boundary=001a114125c807df3a054650ed5f
Archived-At: 
Cc: IETF-Announce , "dime-chairs@ietf.org" , "dime@ietf.org" , "ietf@ietf.org" , "draft-ietf-dime-agent-overload@ietf.org" 
Subject: Re: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jan 2017 21:24:37 -0000

--001a114125c807df3a054650ed5f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Janet,

OK, I will not argue :)
-1 comment for Steve to answer.

/Misha

2017-01-18 0:16 GMT+03:00 Gunn, Janet P :

> Point number 2-
>
>
>
> "As if the client were =E2=80=A6" is correct (subjunctive for a "conditio=
n
> contrary to fact")
>
>
>
> "As if the client  was" =E2=80=A6 is grammatically INCORRECT.
>
>
>
> Janet
>
>
>
> *From:* DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Misha Zaytsev
> *Sent:* Tuesday, January 17, 2017 3:24 PM
> *To:* ietf@ietf.org
> *Cc:* dime-chairs@ietf.org; dime@ietf.org; draft-ietf-dime-agent-
> overload@ietf.org; IETF-Announce 
> *Subject:* Re: [Dime] Last Call: 
> (Diameter Agent Overload and the Peer Overload Report) to Proposed Standa=
rd
>
>
>
> Hi All,
>
>
>
> Here are my comments/questions to an agent overload draft.
>
> This the first part. Later on I will complete my review and send out the
> second portion of the comments.
>
>
>
> 1. section 1 (editorial) removed "is" before "feasible".
>
>
>
> In the base specification, the goal is to handle abatement of the
>
>    overload occurrence as close to the source of the Diameter traffic as
>
>    feasible.
>
>
>
> "scenaios" -> "scenarios"
>
>
>
> The Peer overload report type is
>
>    defined in a generic fashion so that it can also be used for other
>
>    Diameter overload *scenarios*.
>
>
>
> 2. section 3.1.1 (editorial) replaced "were"-> "was"
>
>
>
> In both of these cases, the occurrence of overload in the single
>
>    agent must by handled by the client in a similar fashion as if the
>
>    client *was* handling the overload of a directly connected server.
>
>
>
> 3. section 3.1.1 (question)
>
>
>
> An appropriate error response is sent back to the originator
>
>    of the request.
>
> Who sends "an appropriate" error response" in this case?
>
>
>
> 4. section 3.1.2 (editorial) changed "to"->"the"
>
>
>
> When the client has an active and a standby connection to the two
>
>    agents then an alternative strategy for responding to an overload
>
>    report from an agent is to change *the *standby connection to active a=
nd
>
>    route all traffic through the new active connection.
>
>
>
> 5. section 3.1.3 (editorial)
>
>
>
> An example of this type of deployment include*s* when there are Diameter
>
>    agents between administrative domains.
>
> 6. section 3.1.3
>
>
>
> There is no section 2.2. I guess section 3.1.2 was meant here, right?
>
>
>
> Handling of overload of one or both of agents a11 or a12 in this case
>
>    is equivalent to that discussed in section 2.2.
>
>
>
> 7. section 3.2.1
>
>
>
> It is not clear which usage scenario is meant here.
>
>
>
>    It is envisioned that abatement algorithms will be defined that will
>
>    support the option for Diameter Endpoints to send peer reports.  For
>
>    instance, it is envisioned that one usage scenario for the rate
>
>    algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
>
>    on by the DIME working group as this document is being written, will
>
>    involve abatement being done on a hop-by-hop basis.
>
>
>
> 8. section 4
>
>
>
> Why is throttling to be applied and not diversion (like in case of
> redundant agents)?
>
>
>
> In this scenario the reacting node should first handle the throttling of =
the
>
>    overloaded host or realm.
>
> "LOSS" Is it a new type defined in the scope of this draft?
>
>
>
> Note: The goal is to avoid traffic oscillations that might result
>
>       from throttling of messages for both the HOST/REALM overload
>
>       reports and the PEER overload reports.  This is especially a
>
>       concern if *both reports are of type LOSS*.
>
>
>
> 9. section 5.1.1
>
>
>
> Probably it is better to describe OC_PEER_REPORT feature in section 5.1?
>
> Otherwise, it is used as a well-known one while it is the first place
> where it is mentioned.
>
>
>
> Also I think it is better to add more specific in this draft related to
> peer report handling:
>
> - define Peer Report Reacting Node and Peer Report Reporting Node terms
> explicitly and use them through the draft and especially starting from
> section 5.1
>
> - add "Peer Report" prefix to all the described procedures
>
> Example: Capability Announcement -> Peer Report Capability Announcement
>
>
>
> 10. section 5.1.1/general
>
>
>
> "DiameterIdentity" and "Diameter identity"
>
> My proposal is to use one term through the spec.
>
>
>
> Under "DOIC node", an agent is meant here?
>
>
>
>  When an agent relays a request that includes a SourceID AVP in the
>
>    OC-Supported-Features AVP, a DOIC node that supports the
>
>    OC_PEER_REPORT feature MUST remove the received SourceID AVP and
>
>    replace it with a SourceID AVP containing its own Diameter identity.
>
>
>
> My proposal is to use peer report reacting node here re-phrasing this
> statement below in the following way:
>
>
>
>  When relaying a request that includes a SourceID AVP in the
>
>    OC-Supported-Features AVP, a peer report reacting node MUST remove the=
 received SourceID AVP and
>
>    replace it with a SourceID AVP containing its own DiameterIdentity.
>
> 11. section 5.1.2
>
>
>
> added the missed "to"
>
> changed "PEER_REPORT"-> "PEER"
>
>
>
> Note: The transaction state is used when the DOIC node is acting
>
>       as a peer-report reporting node and needs *to *send OC-OLR reports =
of
>
>       type *PEER *in answer messages.  The peer overload reports
>
>       are only included in answer messages being sent to peers that
>
>       support the OC_PEER_REPORT feature.
>
>
>
> "Diameter ID" term is not clarified anywhere.
>
> Re-phrased the appropriate statement a little bit, changed "Diameter
> ID"->"value"
>
> Also there are other places in the draft where "Diameter ID" term is used=
.
>
>
>
> The peer supports the OC_PEER_REPORT feature if the received request
>
>    contains an OC-Supported-Features AVP with the OC-Feature-Vector with
>
>    the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
>
>    value that matches the DiameterIdentity of the peer from which
>
>    the request was received.
>
>
>
> Agent is meant under "reporting node" here?
>
>
>
> Should not SourceID AVP not just stripped from the relayed answer, but
> replaced with the SourceID AVP containing the DiameterIdentity of the age=
nt
> supporting OC_PEER_REPORT feature?
>
>
>
> When an agent relays an answer message, a reporting node that
>
>    supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
>
>    the OC-Supported-Features AVP.
>
>
>
> Hard to follow what was wanted to say here:
>
> Corrected the statement, but this is just my best guess.
>
>
>
> The OC-Peer-Algo AVP MUST indicate the overload abatement
>
>    algorithm that the reporting node wants the reacting nodes to use
>
>    *when *the reporting node send*s* a peer overload report as a result o=
f
>
>    becoming overloaded.
>
>
>
> Should not we add a separate if- statement for the case when the peer doe=
s
> not support OC_PEER_REPORT feature when sending an answer message?
>
>
>
> 12. section 5.1.1 and 5.1.2
>
>
>
> Probably it is more helpful to illustrate OC_PEER_REPORT feature CA using
> sequence diagrams like in the load info conveyance draft.
>
>
>
> 13. general.
>
>
>
> What about to use the writing for the same terms through the spec?
>
> Example1: "DOIC node" and "DOIC Node"
>
> Example2: "peer-report reporting node" and "peer report reporting node"
>
>
>
> 14. section 5.2.1.2, 5.2.2, 5.2.3 and general
>
>
>
> "peer-type OCS" and "peer report OCS" define the same term?
>
> Why not to use only one?
>
>
>
> Another example: "peer report" and "peer report-type" and "report of type
> PEER"
>
>
>
> 15. section 5.2.3
>
>
>
> Probably it is better to re-phrase this statement a little bit + correcte=
d
> the misprints.
>
>
>
> If a *peer report* reacting node receives an OC-OLR AVP of type peer and =
the
>
> SourceID matches the *DiameterIdentity *of the peer from which the *repor=
t*
>
> was received then the report was *generated *by the peer.
>
>
>
> Similar comment + corrected misprints for the next statement:
>
>
>
> If a peer report reacting node receives an OC-OLR AVP of type peer and th=
e
>
> SourceID does not match the *DiameterIdentity *of the peer from which the
>
> *report *was received then the reacting node MUST ignore the overload
>
> report.
>
>
>
> Also I think it is useful to use one wording for the same term:
>
> "Peer Report OLR", "OC-OLR AVP", "OLR"
>
> Let's use a generic one "peer report"?
>
>
>
> Just minor comment: "the existing..." and "a new overload condition" for
> all occurrences if my English is correct.
>
>
>
> 16. section 5.2.3
>
>
>
> How may it happen that peer report reacting node receives a peer report
> not from the peer that generated it?
>
> Peer reports can be sent only to peer report reacting node, right? And
> peer reports are not relayed, right?
>
>
>
> Best regards,
>
>
>
> /Misha
>
>
>
>
>
> 2017-01-09 17:35 GMT+03:00 The IESG :
>
>
> The IESG has received a request from the Diameter Maintenance and
> Extensions WG (dime) to consider the following document:
> - 'Diameter Agent Overload and the Peer Overload Report'
>    as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2017-01-23. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This specification documents an extension to RFC 7683 (Diameter
>    Overload Indication Conveyance (DOIC)) base solution.  The extension
>    defines the Peer overload report type.  The initial use case for the
>    Peer report is the handling of occurrences of overload of a Diameter
>    agent.
>
> Requirements
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>     draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload
> Control (None - )
> Note that some of these references may already be listed in the acceptabl=
e
> Downref Registry.
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
>
>
> This electronic message transmission contains information from CSRA that
> may be attorney-client privileged, proprietary or confidential. The
> information in this message is intended only for use by the individual(s)
> to whom it is addressed. If you believe you have received this message in
> error, please contact me immediately and be aware that any use, disclosur=
e,
> copying or distribution of the contents of this message is strictly
> prohibited. NOTE: Regardless of content, this email shall not operate to
> bind CSRA to any order or other contract unless pursuant to explicit
> written agreement or government initiative expressly permitting the use o=
f
> email for such purpose.
>

--001a114125c807df3a054650ed5f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Janet,

OK, I will not argue :)
=

-1 comment for Steve to answer.

/Misha
<=
/div>

2017-01-18 0=
:16 GMT+03:00 Gunn, Janet P <Janet.Gunn@csra.com>:











Point number 2-<=
/p>

=C2=A0


"As if the client were =E2=80=A6=
" is correct (subjunctive for a "condition contrary to fact"=
)


=C2=A0


"As if the client =C2=A0was"=
; =E2=80=A6 is grammatically INCORRECT.


=C2=A0


Janet


=C2=A0


From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Misha Zaytsev

Sent: Tuesday, January 17, 2017 3:24 PM

To: ietf@ietf.org=


Cc: dime-c=
hairs@ietf.org; dime=
@ietf.org; draft-ietf-dime-agent-overload@ietf.org; IETF-Ann=
ounce <ietf-=
announce@ietf.org>

Subject: Re: [Dime] Last Call: <draft-ietf-dime-agent-overlo=
ad-08.txt> (Diameter Agent Overload and the Peer Overload Report) to Pro=
posed Standard


=C2=A0




Hi All,




=C2=A0






Here are my comments/questions to an agent overload =
draft.






This the first part. Later on I will complete my rev=
iew and send out the second portion of the comments.






=C2=A0








1. section 1 (editorial) removed "is" befo=
re "feasible".






=C2=A0








In the=
 base specification, the goal is to handle abatement of the


=C2=A0=
=C2=A0 overload occurrence as close to the source of the Diameter traffic a=
s


=C2=A0=
=C2=A0 feasible.










=C2=A0






"scenaios" -> "scenarios"<=
/u>






=C2=A0








The Pe=
er overload report type is


=C2=A0=
=C2=A0 defined in a generic fashion so that it can also be used for other


=C2=A0=
=C2=A0 Diameter overload scenarios.








=C2=A0






2. section 3.1.1 (editorial) replaced "were&quo=
t;-> "was"






=C2=A0








In bot=
h of these cases, the occurrence of overload in the single


=C2=A0=
=C2=A0 agent must by handled by the client in a similar fashion as if the


=C2=A0=
=C2=A0 client was handling the overload of a directly connected serv=
er.








=C2=A0






3. section 3.1.1 (question)






=C2=A0








An app=
ropriate error response is sent back to the originator=



=C2=A0=
=C2=A0 of the request.








Who sends "an appropriate" error response&=
quot; in this case?






=C2=A0






4. section 3.1.2 (editorial) changed "to"-=
>"the"






=C2=A0








When t=
he client has an active and a standby connection to the two


=C2=A0=
=C2=A0 agents then an alternative strategy for responding to an overload=



=C2=A0=
=C2=A0 report from an agent is to change the standby connection to a=
ctive and


=C2=A0=
=C2=A0 route all traffic through the new active connection.








=C2=A0






5. section 3.1.3 (editorial)






=C2=A0








An exa=
mple of this type of deployment includes when there are Diameter<=
/u>


=C2=A0=
=C2=A0 agents between administrative domains.








6. section 3.1.3






=C2=A0






There is no section 2.2. I guess section 3.1.2 was m=
eant here, right?






=C2=A0








Handli=
ng of overload of one or both of agents a11 or a12 in this case


=C2=A0=
=C2=A0 is equivalent to that discussed in section 2.2.=









=C2=A0






7. section 3.2.1






=C2=A0






It is not clear which usage scenario is meant here.<=
u>






=C2=A0








=C2=A0=
=C2=A0 It is envisioned that abatement algorithms will be defined that will=



=C2=A0=
=C2=A0 support the option for Diameter Endpoints to send peer reports.=C2=
=A0 For


=C2=A0=
=C2=A0 instance, it is envisioned that one usage scenario for the rate


=C2=A0=
=C2=A0 algorithm, [I-D.ietf-dime-doic-rate-control], which is being wo=
rked


=C2=A0=
=C2=A0 on by the DIME working group as this document is being written, will=



=C2=A0=
=C2=A0 involve abatement being done on a hop-by-hop basis.








=C2=A0






8. section 4






=C2=A0






Why is throttling to be applied and not diversion (l=
ike in case of redundant agents)?=C2=A0






=C2=A0








In thi=
s scenario the reacting node should first handle the throttling of the


=C2=A0=
=C2=A0 overloaded host or realm.








"LOSS" Is it a new type defined in the sco=
pe of this draft?






=C2=A0








Note: =
The goal is to avoid traffic oscillations that might result


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 from throttling of messages for both the HOST/REAL=
M overload


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 reports and the PEER overload reports.=C2=A0 This =
is especially a


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 concern if both reports are of type LOSS.








=C2=A0






9. section 5.1.1






=C2=A0






Probably it is better to describe OC_PEER_REPORT fea=
ture in section 5.1?






Otherwise, it is used as a well-known one while it i=
s the first place where it is mentioned.






=C2=A0






Also I think it is better to add more specific in th=
is draft related to peer report handling:






- define Peer Report Reacting Node and Peer Report R=
eporting Node terms explicitly and use them through the draft and especiall=
y starting from section 5.1=C2=A0






- add "Peer Report" prefix to all the desc=
ribed procedures






Example: Capability Announcement -> Peer Report C=
apability Announcement






=C2=A0






10. section 5.1.1/general






=C2=A0






"DiameterIdentity" and "Diameter iden=
tity"






My proposal is to use one term through the spec.<=
/u>






=C2=A0






Under "DOIC node", an agent is meant here?=







=C2=A0








 When =
an agent relays a request that includes a SourceID AVP in the=



=C2=A0=
=C2=A0 OC-Supported-Features AVP, a DOIC node that supports the


=C2=A0=
=C2=A0 OC_PEER_REPORT feature MUST remove the received SourceID AVP and<=
/u>


=C2=A0=
=C2=A0 replace it with a SourceID AVP containing its own Diameter identity.=









=C2=A0






My proposal is to use peer report reacting node here=
 re-phrasing this statement below in the following way:






=C2=A0








 When =
relaying a request that includes a SourceID AVP in the=



=C2=A0=
=C2=A0 OC-Supported-Features AVP, a peer report reacting node MUST remove t=
he received SourceID AVP and


=C2=A0=
=C2=A0 replace it with a SourceID AVP containing its own DiameterIdentity.<=
u>








11. section 5.1.2






=C2=A0






added the missed "to"






changed "PEER_REPORT"-> "PEER"=
;






=C2=A0








Note: =
The transaction state is used when the DOIC node is acting


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 as a peer-report reporting node and needs to send OC-OLR reports of


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 type PEER in answer messages.=C2=A0 The pee=
r overload reports


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 are only included in answer messages being sent to=
 peers that


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 support the OC_PEER_REPORT feature.<=
/span>








=C2=A0






"Diameter ID" term is not clarified anywhe=
re.






Re-phrased the appropriate statement a little bit, c=
hanged "Diameter ID"->"value"






Also there are other places in the draft where "=
;Diameter ID" term is used.






=C2=A0








The pe=
er supports the OC_PEER_REPORT feature if the received request


=C2=A0=
=C2=A0 contains an OC-Supported-Features AVP with the OC-Feature-Vector wit=
h


=C2=A0=
=C2=A0 the OC_PEER_REPORT feature bit set and with a SourceID AVP with a=



=C2=A0=
=C2=A0 value that matches the DiameterIdentity of the peer from which


=C2=A0=
=C2=A0 the request was received.








=C2=A0






Agent is meant under "reporting node" here=
?






=C2=A0






Should not SourceID AVP not just stripped from the r=
elayed answer, but replaced with the SourceID AVP containing the DiameterId=
entity of the agent supporting OC_PEER_REPORT feature?






=C2=A0








When a=
n agent relays an answer message, a reporting node that


=C2=A0=
=C2=A0 supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from=



=C2=A0=
=C2=A0 the OC-Supported-Features AVP.








=C2=A0






Hard to follow what was wanted to say here:






Corrected the statement, but this is just my best gu=
ess.






=C2=A0








The OC=
-Peer-Algo AVP MUST indicate the overload abatement

=C2=A0=
=C2=A0 algorithm that the reporting node wants the reacting nodes to use=



=C2=A0=
=C2=A0 when the reporting node sends a peer overload report a=
s a result of


=C2=A0=
=C2=A0 becoming overloaded.








=C2=A0






Should not we add a separate if- statement for the c=
ase when the peer does not support OC_PEER_REPORT feature when sending an a=
nswer message?






=C2=A0






12. section 5.1.1 and 5.1.2






=C2=A0






Probably it is more helpful to illustrate OC_PEER_RE=
PORT feature CA using sequence diagrams like in the load info conveyance dr=
aft.






=C2=A0






13. general.






=C2=A0






What about to use the writing for the same terms thr=
ough the spec?






Example1: "DOIC node" and "DOIC Node&=
quot;






Example2: "peer-report reporting node" and=
 "peer report reporting node"






=C2=A0






14. section 5.2.1.2, 5.2.2, 5.2.3 and general=







=C2=A0






"peer-type OCS" and "peer report OCS&=
quot; define the same term?






Why not to use only one?






=C2=A0






Another example: "peer report" and "p=
eer report-type" and "report of type PEER"






=C2=A0






15. section 5.2.3






=C2=A0






Probably it is better to re-phrase this statement a =
little bit + corrected the misprints.






=C2=A0








If a <=
b>peer report reacting node receives an OC-OLR AVP of type peer and the=



Source=
ID matches the DiameterIdentity of the peer from which the report=



was re=
ceived then the report was generated by the peer.








=C2=A0






Similar comment + corrected misprints for the next s=
tatement:






=C2=A0








If a p=
eer report reacting node receives an OC-OLR AVP of type peer and the=



Source=
ID does not match the DiameterIdentity of the peer from which the=



rep=
ort was received th=
en the reacting node MUST ignore the overload


report=
.








=C2=A0








Also I think it is useful to use one wording for the=
 same term:






"Peer Report OLR", "OC-OLR AVP",=
 "OLR"






Let's use a generic one "peer report"?=









=C2=A0






Just minor comment: "the existing..." and =
"a new overload condition" for all occurrences if my English is c=
orrect.






=C2=A0






16. section 5.2.3






=C2=A0






How may it happen that peer report reacting node rec=
eives a peer report not from the peer that generated it?






Peer reports can be sent only to peer report reactin=
g node, right? And peer reports are not relayed, right?






=C2=A0






Best regards,






=C2=A0






/Misha






=C2=A0








=C2=A0




2017-01-09 17:35 GMT+03:00 The IESG <iesg-secretary@ietf.org>:






The IESG has received a request from the Diameter Maintenance and

Extensions WG (dime) to consider the following document:

- 'Diameter Agent Overload and the Peer Overload Report'

=C2=A0 <draft-ietf-dime-agent-overload-08.txt> as Proposed Stand=
ard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailin=
g lists by 2017-01-23. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





=C2=A0 =C2=A0This specification documents an extension to RFC 7683 (Diamete=
r

=C2=A0 =C2=A0Overload Indication Conveyance (DOIC)) base solution.=C2=A0 Th=
e extension

=C2=A0 =C2=A0defines the Peer overload report type.=C2=A0 The initial use c=
ase for the

=C2=A0 =C2=A0Peer report is the handling of occurrences of overload of a Di=
ameter

=C2=A0 =C2=A0agent.



Requirements







The file can be obtained via

https://datatracker.ietf.org/doc/draft-ietf-dime-a=
gent-overload/



IESG discussion can be tracked via

https://datatracker.ietf.org/doc/draft-ietf=
-dime-agent-overload/ballot/





No IPR declarations have been submitted directly on this I-D.





The document contains these normative downward references.

See RFC 3967 for additional information:

=C2=A0 =C2=A0 draft-roach-dime-overload-ctrl: A Mechanism for Diameter=
 Overload Control (None - )

Note that some of these references may already be listed in the acceptable =
Downref Registry.





_______________________________________________

DiME mailing list

DiME@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/dime






=C2=A0








This electronic message transmission contains information from CSRA that=
 may be attorney-client privileged, proprietary or confidential. The inform=
ation in this message is intended only for use by the individual(s) to whom=
 it is addressed. If you believe
 you have received this message in error, please contact me immediately and=
 be aware that any use, disclosure, copying or distribution of the contents=
 of this message is strictly prohibited. NOTE: Regardless of content, this =
email shall not operate to bind
 CSRA to any order or other contract unless pursuant to explicit written ag=
reement or government initiative expressly permitting the use of email for =
such purpose.








--001a114125c807df3a054650ed5f--


From nobody Tue Jan 17 13:26:35 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBE8129416; Tue, 17 Jan 2017 13:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, 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 YclgwRtFWB1a; Tue, 17 Jan 2017 13:26:25 -0800 (PST)
Received: from mailport8.csra.com (mailport8.csra.com [131.131.97.26]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6E91294FE; Tue, 17 Jan 2017 13:16:48 -0800 (PST)
Received: from csrrdu1exm023.corp.csra.com (HELO mail.csra.com) ([10.8.2.23]) by mailport8.csra.com with ESMTP/TLS/AES256-SHA; 17 Jan 2017 16:16:47 -0500
Received: from CSRRDU1EXM025.corp.csra.com (10.8.2.25) by CSRRDU1EXM021.corp.csra.com (10.8.2.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 16:16:46 -0500
Received: from CSRRDU1EXM025.corp.csra.com ([10.8.2.25]) by CSRRDU1EXM025.corp.csra.com ([10.8.2.25]) with mapi id 15.00.1210.000; Tue, 17 Jan 2017 16:16:46 -0500
From: "Gunn, Janet P" 
To: Misha Zaytsev , "ietf@ietf.org" 
Thread-Topic: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
Thread-Index: AQHSaoWzoyfk6GZ4r0WNj5yOH2cKTaE9ffWA//+6NiA=
Date: Tue, 17 Jan 2017 21:16:46 +0000
Message-ID: 
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.136.2.8]
Content-Type: multipart/alternative; boundary="_000_c5efbe4b018646489bb21b75a81e6836CSRRDU1EXM025corpcsraco_"
MIME-Version: 1.0
Archived-At: 
Cc: "dime-chairs@ietf.org" , "dime@ietf.org" , IETF-Announce , "draft-ietf-dime-agent-overload@ietf.org" 
Subject: Re: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jan 2017 21:26:27 -0000

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

UG9pbnQgbnVtYmVyIDItDQoNCiJBcyBpZiB0aGUgY2xpZW50IHdlcmUg4oCmIiBpcyBjb3JyZWN0
IChzdWJqdW5jdGl2ZSBmb3IgYSAiY29uZGl0aW9uIGNvbnRyYXJ5IHRvIGZhY3QiKQ0KDQoiQXMg
aWYgdGhlIGNsaWVudCAgd2FzIiDigKYgaXMgZ3JhbW1hdGljYWxseSBJTkNPUlJFQ1QuDQoNCkph
bmV0DQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBNaXNoYSBaYXl0c2V2DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDE3LCAyMDE3IDM6MjQg
UE0NClRvOiBpZXRmQGlldGYub3JnDQpDYzogZGltZS1jaGFpcnNAaWV0Zi5vcmc7IGRpbWVAaWV0
Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZEBpZXRmLm9yZzsgSUVURi1Bbm5v
dW5jZSA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGltZV0gTGFzdCBD
YWxsOiA8ZHJhZnQtaWV0Zi1kaW1lLWFnZW50LW92ZXJsb2FkLTA4LnR4dD4gKERpYW1ldGVyIEFn
ZW50IE92ZXJsb2FkIGFuZCB0aGUgUGVlciBPdmVybG9hZCBSZXBvcnQpIHRvIFByb3Bvc2VkIFN0
YW5kYXJkDQoNCkhpIEFsbCwNCg0KSGVyZSBhcmUgbXkgY29tbWVudHMvcXVlc3Rpb25zIHRvIGFu
IGFnZW50IG92ZXJsb2FkIGRyYWZ0Lg0KVGhpcyB0aGUgZmlyc3QgcGFydC4gTGF0ZXIgb24gSSB3
aWxsIGNvbXBsZXRlIG15IHJldmlldyBhbmQgc2VuZCBvdXQgdGhlIHNlY29uZCBwb3J0aW9uIG9m
IHRoZSBjb21tZW50cy4NCg0KMS4gc2VjdGlvbiAxIChlZGl0b3JpYWwpIHJlbW92ZWQgImlzIiBi
ZWZvcmUgImZlYXNpYmxlIi4NCg0KDQpJbiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9uLCB0aGUgZ29h
bCBpcyB0byBoYW5kbGUgYWJhdGVtZW50IG9mIHRoZQ0KDQogICBvdmVybG9hZCBvY2N1cnJlbmNl
IGFzIGNsb3NlIHRvIHRoZSBzb3VyY2Ugb2YgdGhlIERpYW1ldGVyIHRyYWZmaWMgYXMNCg0KICAg
ZmVhc2libGUuDQoNCiJzY2VuYWlvcyIgLT4gInNjZW5hcmlvcyINCg0KDQpUaGUgUGVlciBvdmVy
bG9hZCByZXBvcnQgdHlwZSBpcw0KDQogICBkZWZpbmVkIGluIGEgZ2VuZXJpYyBmYXNoaW9uIHNv
IHRoYXQgaXQgY2FuIGFsc28gYmUgdXNlZCBmb3Igb3RoZXINCg0KICAgRGlhbWV0ZXIgb3Zlcmxv
YWQgc2NlbmFyaW9zLg0KDQoyLiBzZWN0aW9uIDMuMS4xIChlZGl0b3JpYWwpIHJlcGxhY2VkICJ3
ZXJlIi0+ICJ3YXMiDQoNCg0KSW4gYm90aCBvZiB0aGVzZSBjYXNlcywgdGhlIG9jY3VycmVuY2Ug
b2Ygb3ZlcmxvYWQgaW4gdGhlIHNpbmdsZQ0KDQogICBhZ2VudCBtdXN0IGJ5IGhhbmRsZWQgYnkg
dGhlIGNsaWVudCBpbiBhIHNpbWlsYXIgZmFzaGlvbiBhcyBpZiB0aGUNCg0KICAgY2xpZW50IHdh
cyBoYW5kbGluZyB0aGUgb3ZlcmxvYWQgb2YgYSBkaXJlY3RseSBjb25uZWN0ZWQgc2VydmVyLg0K
DQozLiBzZWN0aW9uIDMuMS4xIChxdWVzdGlvbikNCg0KDQpBbiBhcHByb3ByaWF0ZSBlcnJvciBy
ZXNwb25zZSBpcyBzZW50IGJhY2sgdG8gdGhlIG9yaWdpbmF0b3INCg0KICAgb2YgdGhlIHJlcXVl
c3QuDQpXaG8gc2VuZHMgImFuIGFwcHJvcHJpYXRlIiBlcnJvciByZXNwb25zZSIgaW4gdGhpcyBj
YXNlPw0KDQo0LiBzZWN0aW9uIDMuMS4yIChlZGl0b3JpYWwpIGNoYW5nZWQgInRvIi0+InRoZSIN
Cg0KDQpXaGVuIHRoZSBjbGllbnQgaGFzIGFuIGFjdGl2ZSBhbmQgYSBzdGFuZGJ5IGNvbm5lY3Rp
b24gdG8gdGhlIHR3bw0KDQogICBhZ2VudHMgdGhlbiBhbiBhbHRlcm5hdGl2ZSBzdHJhdGVneSBm
b3IgcmVzcG9uZGluZyB0byBhbiBvdmVybG9hZA0KDQogICByZXBvcnQgZnJvbSBhbiBhZ2VudCBp
cyB0byBjaGFuZ2UgdGhlIHN0YW5kYnkgY29ubmVjdGlvbiB0byBhY3RpdmUgYW5kDQoNCiAgIHJv
dXRlIGFsbCB0cmFmZmljIHRocm91Z2ggdGhlIG5ldyBhY3RpdmUgY29ubmVjdGlvbi4NCg0KNS4g
c2VjdGlvbiAzLjEuMyAoZWRpdG9yaWFsKQ0KDQoNCkFuIGV4YW1wbGUgb2YgdGhpcyB0eXBlIG9m
IGRlcGxveW1lbnQgaW5jbHVkZXMgd2hlbiB0aGVyZSBhcmUgRGlhbWV0ZXINCg0KICAgYWdlbnRz
IGJldHdlZW4gYWRtaW5pc3RyYXRpdmUgZG9tYWlucy4NCjYuIHNlY3Rpb24gMy4xLjMNCg0KVGhl
cmUgaXMgbm8gc2VjdGlvbiAyLjIuIEkgZ3Vlc3Mgc2VjdGlvbiAzLjEuMiB3YXMgbWVhbnQgaGVy
ZSwgcmlnaHQ/DQoNCg0KSGFuZGxpbmcgb2Ygb3ZlcmxvYWQgb2Ygb25lIG9yIGJvdGggb2YgYWdl
bnRzIGExMSBvciBhMTIgaW4gdGhpcyBjYXNlDQoNCiAgIGlzIGVxdWl2YWxlbnQgdG8gdGhhdCBk
aXNjdXNzZWQgaW4gc2VjdGlvbiAyLjIuDQoNCjcuIHNlY3Rpb24gMy4yLjENCg0KSXQgaXMgbm90
IGNsZWFyIHdoaWNoIHVzYWdlIHNjZW5hcmlvIGlzIG1lYW50IGhlcmUuDQoNCg0KICAgSXQgaXMg
ZW52aXNpb25lZCB0aGF0IGFiYXRlbWVudCBhbGdvcml0aG1zIHdpbGwgYmUgZGVmaW5lZCB0aGF0
IHdpbGwNCg0KICAgc3VwcG9ydCB0aGUgb3B0aW9uIGZvciBEaWFtZXRlciBFbmRwb2ludHMgdG8g
c2VuZCBwZWVyIHJlcG9ydHMuICBGb3INCg0KICAgaW5zdGFuY2UsIGl0IGlzIGVudmlzaW9uZWQg
dGhhdCBvbmUgdXNhZ2Ugc2NlbmFyaW8gZm9yIHRoZSByYXRlDQoNCiAgIGFsZ29yaXRobSwgW0kt
RC5pZXRmLWRpbWUtZG9pYy1yYXRlLWNvbnRyb2xdLCB3aGljaCBpcyBiZWluZyB3b3JrZWQNCg0K
ICAgb24gYnkgdGhlIERJTUUgd29ya2luZyBncm91cCBhcyB0aGlzIGRvY3VtZW50IGlzIGJlaW5n
IHdyaXR0ZW4sIHdpbGwNCg0KICAgaW52b2x2ZSBhYmF0ZW1lbnQgYmVpbmcgZG9uZSBvbiBhIGhv
cC1ieS1ob3AgYmFzaXMuDQoNCjguIHNlY3Rpb24gNA0KDQpXaHkgaXMgdGhyb3R0bGluZyB0byBi
ZSBhcHBsaWVkIGFuZCBub3QgZGl2ZXJzaW9uIChsaWtlIGluIGNhc2Ugb2YgcmVkdW5kYW50IGFn
ZW50cyk/DQoNCg0KSW4gdGhpcyBzY2VuYXJpbyB0aGUgcmVhY3Rpbmcgbm9kZSBzaG91bGQgZmly
c3QgaGFuZGxlIHRoZSB0aHJvdHRsaW5nIG9mIHRoZQ0KDQogICBvdmVybG9hZGVkIGhvc3Qgb3Ig
cmVhbG0uDQoiTE9TUyIgSXMgaXQgYSBuZXcgdHlwZSBkZWZpbmVkIGluIHRoZSBzY29wZSBvZiB0
aGlzIGRyYWZ0Pw0KDQoNCk5vdGU6IFRoZSBnb2FsIGlzIHRvIGF2b2lkIHRyYWZmaWMgb3NjaWxs
YXRpb25zIHRoYXQgbWlnaHQgcmVzdWx0DQoNCiAgICAgIGZyb20gdGhyb3R0bGluZyBvZiBtZXNz
YWdlcyBmb3IgYm90aCB0aGUgSE9TVC9SRUFMTSBvdmVybG9hZA0KDQogICAgICByZXBvcnRzIGFu
ZCB0aGUgUEVFUiBvdmVybG9hZCByZXBvcnRzLiAgVGhpcyBpcyBlc3BlY2lhbGx5IGENCg0KICAg
ICAgY29uY2VybiBpZiBib3RoIHJlcG9ydHMgYXJlIG9mIHR5cGUgTE9TUy4NCg0KOS4gc2VjdGlv
biA1LjEuMQ0KDQpQcm9iYWJseSBpdCBpcyBiZXR0ZXIgdG8gZGVzY3JpYmUgT0NfUEVFUl9SRVBP
UlQgZmVhdHVyZSBpbiBzZWN0aW9uIDUuMT8NCk90aGVyd2lzZSwgaXQgaXMgdXNlZCBhcyBhIHdl
bGwta25vd24gb25lIHdoaWxlIGl0IGlzIHRoZSBmaXJzdCBwbGFjZSB3aGVyZSBpdCBpcyBtZW50
aW9uZWQuDQoNCkFsc28gSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gYWRkIG1vcmUgc3BlY2lmaWMg
aW4gdGhpcyBkcmFmdCByZWxhdGVkIHRvIHBlZXIgcmVwb3J0IGhhbmRsaW5nOg0KLSBkZWZpbmUg
UGVlciBSZXBvcnQgUmVhY3RpbmcgTm9kZSBhbmQgUGVlciBSZXBvcnQgUmVwb3J0aW5nIE5vZGUg
dGVybXMgZXhwbGljaXRseSBhbmQgdXNlIHRoZW0gdGhyb3VnaCB0aGUgZHJhZnQgYW5kIGVzcGVj
aWFsbHkgc3RhcnRpbmcgZnJvbSBzZWN0aW9uIDUuMQ0KLSBhZGQgIlBlZXIgUmVwb3J0IiBwcmVm
aXggdG8gYWxsIHRoZSBkZXNjcmliZWQgcHJvY2VkdXJlcw0KRXhhbXBsZTogQ2FwYWJpbGl0eSBB
bm5vdW5jZW1lbnQgLT4gUGVlciBSZXBvcnQgQ2FwYWJpbGl0eSBBbm5vdW5jZW1lbnQNCg0KMTAu
IHNlY3Rpb24gNS4xLjEvZ2VuZXJhbA0KDQoiRGlhbWV0ZXJJZGVudGl0eSIgYW5kICJEaWFtZXRl
ciBpZGVudGl0eSINCk15IHByb3Bvc2FsIGlzIHRvIHVzZSBvbmUgdGVybSB0aHJvdWdoIHRoZSBz
cGVjLg0KDQpVbmRlciAiRE9JQyBub2RlIiwgYW4gYWdlbnQgaXMgbWVhbnQgaGVyZT8NCg0KDQog
V2hlbiBhbiBhZ2VudCByZWxheXMgYSByZXF1ZXN0IHRoYXQgaW5jbHVkZXMgYSBTb3VyY2VJRCBB
VlAgaW4gdGhlDQoNCiAgIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAsIGEgRE9JQyBub2RlIHRo
YXQgc3VwcG9ydHMgdGhlDQoNCiAgIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgTVVTVCByZW1vdmUg
dGhlIHJlY2VpdmVkIFNvdXJjZUlEIEFWUCBhbmQNCg0KICAgcmVwbGFjZSBpdCB3aXRoIGEgU291
cmNlSUQgQVZQIGNvbnRhaW5pbmcgaXRzIG93biBEaWFtZXRlciBpZGVudGl0eS4NCg0KTXkgcHJv
cG9zYWwgaXMgdG8gdXNlIHBlZXIgcmVwb3J0IHJlYWN0aW5nIG5vZGUgaGVyZSByZS1waHJhc2lu
ZyB0aGlzIHN0YXRlbWVudCBiZWxvdyBpbiB0aGUgZm9sbG93aW5nIHdheToNCg0KDQogV2hlbiBy
ZWxheWluZyBhIHJlcXVlc3QgdGhhdCBpbmNsdWRlcyBhIFNvdXJjZUlEIEFWUCBpbiB0aGUNCg0K
ICAgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCwgYSBwZWVyIHJlcG9ydCByZWFjdGluZyBub2Rl
IE1VU1QgcmVtb3ZlIHRoZSByZWNlaXZlZCBTb3VyY2VJRCBBVlAgYW5kDQoNCiAgIHJlcGxhY2Ug
aXQgd2l0aCBhIFNvdXJjZUlEIEFWUCBjb250YWluaW5nIGl0cyBvd24gRGlhbWV0ZXJJZGVudGl0
eS4NCjExLiBzZWN0aW9uIDUuMS4yDQoNCmFkZGVkIHRoZSBtaXNzZWQgInRvIg0KY2hhbmdlZCAi
UEVFUl9SRVBPUlQiLT4gIlBFRVIiDQoNCg0KTm90ZTogVGhlIHRyYW5zYWN0aW9uIHN0YXRlIGlz
IHVzZWQgd2hlbiB0aGUgRE9JQyBub2RlIGlzIGFjdGluZw0KDQogICAgICBhcyBhIHBlZXItcmVw
b3J0IHJlcG9ydGluZyBub2RlIGFuZCBuZWVkcyB0byBzZW5kIE9DLU9MUiByZXBvcnRzIG9mDQoN
CiAgICAgIHR5cGUgUEVFUiBpbiBhbnN3ZXIgbWVzc2FnZXMuICBUaGUgcGVlciBvdmVybG9hZCBy
ZXBvcnRzDQoNCiAgICAgIGFyZSBvbmx5IGluY2x1ZGVkIGluIGFuc3dlciBtZXNzYWdlcyBiZWlu
ZyBzZW50IHRvIHBlZXJzIHRoYXQNCg0KICAgICAgc3VwcG9ydCB0aGUgT0NfUEVFUl9SRVBPUlQg
ZmVhdHVyZS4NCg0KIkRpYW1ldGVyIElEIiB0ZXJtIGlzIG5vdCBjbGFyaWZpZWQgYW55d2hlcmUu
DQpSZS1waHJhc2VkIHRoZSBhcHByb3ByaWF0ZSBzdGF0ZW1lbnQgYSBsaXR0bGUgYml0LCBjaGFu
Z2VkICJEaWFtZXRlciBJRCItPiJ2YWx1ZSINCkFsc28gdGhlcmUgYXJlIG90aGVyIHBsYWNlcyBp
biB0aGUgZHJhZnQgd2hlcmUgIkRpYW1ldGVyIElEIiB0ZXJtIGlzIHVzZWQuDQoNCg0KVGhlIHBl
ZXIgc3VwcG9ydHMgdGhlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgaWYgdGhlIHJlY2VpdmVkIHJl
cXVlc3QNCg0KICAgY29udGFpbnMgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCB3aXRoIHRo
ZSBPQy1GZWF0dXJlLVZlY3RvciB3aXRoDQoNCiAgIHRoZSBPQ19QRUVSX1JFUE9SVCBmZWF0dXJl
IGJpdCBzZXQgYW5kIHdpdGggYSBTb3VyY2VJRCBBVlAgd2l0aCBhDQoNCiAgIHZhbHVlIHRoYXQg
bWF0Y2hlcyB0aGUgRGlhbWV0ZXJJZGVudGl0eSBvZiB0aGUgcGVlciBmcm9tIHdoaWNoDQoNCiAg
IHRoZSByZXF1ZXN0IHdhcyByZWNlaXZlZC4NCg0KQWdlbnQgaXMgbWVhbnQgdW5kZXIgInJlcG9y
dGluZyBub2RlIiBoZXJlPw0KDQpTaG91bGQgbm90IFNvdXJjZUlEIEFWUCBub3QganVzdCBzdHJp
cHBlZCBmcm9tIHRoZSByZWxheWVkIGFuc3dlciwgYnV0IHJlcGxhY2VkIHdpdGggdGhlIFNvdXJj
ZUlEIEFWUCBjb250YWluaW5nIHRoZSBEaWFtZXRlcklkZW50aXR5IG9mIHRoZSBhZ2VudCBzdXBw
b3J0aW5nIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmU/DQoNCg0KV2hlbiBhbiBhZ2VudCByZWxheXMg
YW4gYW5zd2VyIG1lc3NhZ2UsIGEgcmVwb3J0aW5nIG5vZGUgdGhhdA0KDQogICBzdXBwb3J0cyB0
aGUgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZSBNVVNUIHN0cmlwIGFueSBTb3VyY2VJRCBBVlAgZnJv
bQ0KDQogICB0aGUgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUC4NCg0KSGFyZCB0byBmb2xsb3cg
d2hhdCB3YXMgd2FudGVkIHRvIHNheSBoZXJlOg0KQ29ycmVjdGVkIHRoZSBzdGF0ZW1lbnQsIGJ1
dCB0aGlzIGlzIGp1c3QgbXkgYmVzdCBndWVzcy4NCg0KDQpUaGUgT0MtUGVlci1BbGdvIEFWUCBN
VVNUIGluZGljYXRlIHRoZSBvdmVybG9hZCBhYmF0ZW1lbnQNCg0KICAgYWxnb3JpdGhtIHRoYXQg
dGhlIHJlcG9ydGluZyBub2RlIHdhbnRzIHRoZSByZWFjdGluZyBub2RlcyB0byB1c2UNCg0KICAg
d2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgc2VuZHMgYSBwZWVyIG92ZXJsb2FkIHJlcG9ydCBhcyBh
IHJlc3VsdCBvZg0KDQogICBiZWNvbWluZyBvdmVybG9hZGVkLg0KDQpTaG91bGQgbm90IHdlIGFk
ZCBhIHNlcGFyYXRlIGlmLSBzdGF0ZW1lbnQgZm9yIHRoZSBjYXNlIHdoZW4gdGhlIHBlZXIgZG9l
cyBub3Qgc3VwcG9ydCBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlIHdoZW4gc2VuZGluZyBhbiBhbnN3
ZXIgbWVzc2FnZT8NCg0KMTIuIHNlY3Rpb24gNS4xLjEgYW5kIDUuMS4yDQoNClByb2JhYmx5IGl0
IGlzIG1vcmUgaGVscGZ1bCB0byBpbGx1c3RyYXRlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgQ0Eg
dXNpbmcgc2VxdWVuY2UgZGlhZ3JhbXMgbGlrZSBpbiB0aGUgbG9hZCBpbmZvIGNvbnZleWFuY2Ug
ZHJhZnQuDQoNCjEzLiBnZW5lcmFsLg0KDQpXaGF0IGFib3V0IHRvIHVzZSB0aGUgd3JpdGluZyBm
b3IgdGhlIHNhbWUgdGVybXMgdGhyb3VnaCB0aGUgc3BlYz8NCkV4YW1wbGUxOiAiRE9JQyBub2Rl
IiBhbmQgIkRPSUMgTm9kZSINCkV4YW1wbGUyOiAicGVlci1yZXBvcnQgcmVwb3J0aW5nIG5vZGUi
IGFuZCAicGVlciByZXBvcnQgcmVwb3J0aW5nIG5vZGUiDQoNCjE0LiBzZWN0aW9uIDUuMi4xLjIs
IDUuMi4yLCA1LjIuMyBhbmQgZ2VuZXJhbA0KDQoicGVlci10eXBlIE9DUyIgYW5kICJwZWVyIHJl
cG9ydCBPQ1MiIGRlZmluZSB0aGUgc2FtZSB0ZXJtPw0KV2h5IG5vdCB0byB1c2Ugb25seSBvbmU/
DQoNCkFub3RoZXIgZXhhbXBsZTogInBlZXIgcmVwb3J0IiBhbmQgInBlZXIgcmVwb3J0LXR5cGUi
IGFuZCAicmVwb3J0IG9mIHR5cGUgUEVFUiINCg0KMTUuIHNlY3Rpb24gNS4yLjMNCg0KUHJvYmFi
bHkgaXQgaXMgYmV0dGVyIHRvIHJlLXBocmFzZSB0aGlzIHN0YXRlbWVudCBhIGxpdHRsZSBiaXQg
KyBjb3JyZWN0ZWQgdGhlIG1pc3ByaW50cy4NCg0KDQpJZiBhIHBlZXIgcmVwb3J0IHJlYWN0aW5n
IG5vZGUgcmVjZWl2ZXMgYW4gT0MtT0xSIEFWUCBvZiB0eXBlIHBlZXIgYW5kIHRoZQ0KDQpTb3Vy
Y2VJRCBtYXRjaGVzIHRoZSBEaWFtZXRlcklkZW50aXR5IG9mIHRoZSBwZWVyIGZyb20gd2hpY2gg
dGhlIHJlcG9ydA0KDQp3YXMgcmVjZWl2ZWQgdGhlbiB0aGUgcmVwb3J0IHdhcyBnZW5lcmF0ZWQg
YnkgdGhlIHBlZXIuDQoNClNpbWlsYXIgY29tbWVudCArIGNvcnJlY3RlZCBtaXNwcmludHMgZm9y
IHRoZSBuZXh0IHN0YXRlbWVudDoNCg0KDQpJZiBhIHBlZXIgcmVwb3J0IHJlYWN0aW5nIG5vZGUg
cmVjZWl2ZXMgYW4gT0MtT0xSIEFWUCBvZiB0eXBlIHBlZXIgYW5kIHRoZQ0KDQpTb3VyY2VJRCBk
b2VzIG5vdCBtYXRjaCB0aGUgRGlhbWV0ZXJJZGVudGl0eSBvZiB0aGUgcGVlciBmcm9tIHdoaWNo
IHRoZQ0KDQpyZXBvcnQgd2FzIHJlY2VpdmVkIHRoZW4gdGhlIHJlYWN0aW5nIG5vZGUgTVVTVCBp
Z25vcmUgdGhlIG92ZXJsb2FkDQoNCnJlcG9ydC4NCg0KQWxzbyBJIHRoaW5rIGl0IGlzIHVzZWZ1
bCB0byB1c2Ugb25lIHdvcmRpbmcgZm9yIHRoZSBzYW1lIHRlcm06DQoiUGVlciBSZXBvcnQgT0xS
IiwgIk9DLU9MUiBBVlAiLCAiT0xSIg0KTGV0J3MgdXNlIGEgZ2VuZXJpYyBvbmUgInBlZXIgcmVw
b3J0Ij8NCg0KSnVzdCBtaW5vciBjb21tZW50OiAidGhlIGV4aXN0aW5nLi4uIiBhbmQgImEgbmV3
IG92ZXJsb2FkIGNvbmRpdGlvbiIgZm9yIGFsbCBvY2N1cnJlbmNlcyBpZiBteSBFbmdsaXNoIGlz
IGNvcnJlY3QuDQoNCjE2LiBzZWN0aW9uIDUuMi4zDQoNCkhvdyBtYXkgaXQgaGFwcGVuIHRoYXQg
cGVlciByZXBvcnQgcmVhY3Rpbmcgbm9kZSByZWNlaXZlcyBhIHBlZXIgcmVwb3J0IG5vdCBmcm9t
IHRoZSBwZWVyIHRoYXQgZ2VuZXJhdGVkIGl0Pw0KUGVlciByZXBvcnRzIGNhbiBiZSBzZW50IG9u
bHkgdG8gcGVlciByZXBvcnQgcmVhY3Rpbmcgbm9kZSwgcmlnaHQ/IEFuZCBwZWVyIHJlcG9ydHMg
YXJlIG5vdCByZWxheWVkLCByaWdodD8NCg0KQmVzdCByZWdhcmRzLA0KDQovTWlzaGENCg0KDQoy
MDE3LTAxLTA5IDE3OjM1IEdNVCswMzowMCBUaGUgSUVTRyA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5v
cmc8bWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPj46DQoNClRoZSBJRVNHIGhhcyByZWNl
aXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgRGlhbWV0ZXIgTWFpbnRlbmFuY2UgYW5kDQpFeHRlbnNp
b25zIFdHIChkaW1lKSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KLSAnRGlh
bWV0ZXIgQWdlbnQgT3ZlcmxvYWQgYW5kIHRoZSBQZWVyIE92ZXJsb2FkIFJlcG9ydCcNCiAgPGRy
YWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZC0wOC50eHQ+IGFzIFByb3Bvc2VkIFN0YW5kYXJk
DQoNClRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vl
a3MsIGFuZCBzb2xpY2l0cw0KZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBz
ZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZQ0KaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0
ZkBpZXRmLm9yZz4gbWFpbGluZyBsaXN0cyBieSAyMDE3LTAxLTIzLiBFeGNlcHRpb25hbGx5LCBj
b21tZW50cyBtYXkgYmUNCnNlbnQgdG8gaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9y
Zz4gaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlDQpiZWdpbm5pbmcg
b2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCg0KQWJzdHJh
Y3QNCg0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gZG9jdW1lbnRzIGFuIGV4dGVuc2lvbiB0byBS
RkMgNzY4MyAoRGlhbWV0ZXINCiAgIE92ZXJsb2FkIEluZGljYXRpb24gQ29udmV5YW5jZSAoRE9J
QykpIGJhc2Ugc29sdXRpb24uICBUaGUgZXh0ZW5zaW9uDQogICBkZWZpbmVzIHRoZSBQZWVyIG92
ZXJsb2FkIHJlcG9ydCB0eXBlLiAgVGhlIGluaXRpYWwgdXNlIGNhc2UgZm9yIHRoZQ0KICAgUGVl
ciByZXBvcnQgaXMgdGhlIGhhbmRsaW5nIG9mIG9jY3VycmVuY2VzIG9mIG92ZXJsb2FkIG9mIGEg
RGlhbWV0ZXINCiAgIGFnZW50Lg0KDQpSZXF1aXJlbWVudHMNCg0KDQoNClRoZSBmaWxlIGNhbiBi
ZSBvYnRhaW5lZCB2aWENCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll
dGYtZGltZS1hZ2VudC1vdmVybG9hZC8NCg0KSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2Vk
IHZpYQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLWFn
ZW50LW92ZXJsb2FkL2JhbGxvdC8NCg0KDQpObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBz
dWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQoNCg0KVGhlIGRvY3VtZW50IGNvbnRhaW5z
IHRoZXNlIG5vcm1hdGl2ZSBkb3dud2FyZCByZWZlcmVuY2VzLg0KU2VlIFJGQyAzOTY3IGZvciBh
ZGRpdGlvbmFsIGluZm9ybWF0aW9uOg0KICAgIGRyYWZ0LXJvYWNoLWRpbWUtb3ZlcmxvYWQtY3Ry
bDogQSBNZWNoYW5pc20gZm9yIERpYW1ldGVyIE92ZXJsb2FkIENvbnRyb2wgKE5vbmUgLSApDQpO
b3RlIHRoYXQgc29tZSBvZiB0aGVzZSByZWZlcmVuY2VzIG1heSBhbHJlYWR5IGJlIGxpc3RlZCBp
biB0aGUgYWNjZXB0YWJsZSBEb3ducmVmIFJlZ2lzdHJ5Lg0KDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBp
ZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZGltZQ0KDQoNCg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgdHJhbnNtaXNz
aW9uIGNvbnRhaW5zIGluZm9ybWF0aW9uIGZyb20gQ1NSQSB0aGF0IG1heSBiZSBhdHRvcm5leS1j
bGllbnQgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3Jt
YXRpb24gaW4gdGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHVzZSBieSB0aGUgaW5k
aXZpZHVhbChzKSB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGJlbGlldmUgeW91IGhh
dmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UgY29udGFjdCBtZSBpbW1l
ZGlhdGVseSBhbmQgYmUgYXdhcmUgdGhhdCBhbnkgdXNlLCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9y
IGRpc3RyaWJ1dGlvbiBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5
IHByb2hpYml0ZWQuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlbWFpbCBzaGFs
bCBub3Qgb3BlcmF0ZSB0byBiaW5kIENTUkEgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0
IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5t
ZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlbWFpbCBmb3Ig
c3VjaCBwdXJwb3NlLg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy
IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk
LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy
IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk
Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ
Zm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt
b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu
MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi
IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0
IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk
Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj5Qb2ludCBudW1iZXIgMi08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPiZxdW90O0FzIGlmIHRoZSBjbGllbnQgd2VyZSDigKYmcXVvdDsg
aXMgY29ycmVjdCAoc3VianVuY3RpdmUgZm9yIGEgJnF1b3Q7Y29uZGl0aW9uIGNvbnRyYXJ5IHRv
IGZhY3QmcXVvdDspPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m
cXVvdDtBcyBpZiB0aGUgY2xpZW50ICZuYnNwO3dhcyZxdW90OyDigKYgaXMgZ3JhbW1hdGljYWxs
eSBJTkNPUlJFQ1QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5K
YW5ldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9
Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBEaU1FIFttYWlsdG86
ZGltZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NaXNoYSBaYXl0c2V2
PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTcgMzoyNCBQTTxicj4N
CjxiPlRvOjwvYj4gaWV0ZkBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gZGltZS1jaGFpcnNAaWV0
Zi5vcmc7IGRpbWVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZEBpZXRm
Lm9yZzsgSUVURi1Bbm5vdW5jZSAmbHQ7aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZyZndDs8YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLWRpbWUt
YWdlbnQtb3ZlcmxvYWQtMDgudHh0Jmd0OyAoRGlhbWV0ZXIgQWdlbnQgT3ZlcmxvYWQgYW5kIHRo
ZSBQZWVyIE92ZXJsb2FkIFJlcG9ydCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQ8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGFyZSBteSBjb21tZW50cy9xdWVzdGlvbnMgdG8g
YW4gYWdlbnQgb3ZlcmxvYWQgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHRoZSBmaXJzdCBwYXJ0LiBMYXRlciBvbiBJIHdpbGwg
Y29tcGxldGUgbXkgcmV2aWV3IGFuZCBzZW5kIG91dCB0aGUgc2Vjb25kIHBvcnRpb24gb2YgdGhl
IGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+MS4gc2VjdGlvbiAxIChlZGl0b3JpYWwpIHJlbW92ZWQgJnF1b3Q7aXMm
cXVvdDsgYmVmb3JlICZxdW90O2ZlYXNpYmxlJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVy
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNr
Z3JvdW5kOiNGRkZERjUiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv
dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW47
Ym94LXNpemluZzpib3JkZXItYm94O3dvcmQtd3JhcDpicmVhay13b3JkO2JvcmRlci1yYWRpdXM6
NHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs
YWNrIj5JbiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9uLCB0aGUgZ29hbCBpcyB0byBoYW5kbGUgYWJh
dGVtZW50IG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
LWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9y
ZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y
OmJsYWNrIj4mbmJzcDsmbmJzcDsgb3ZlcmxvYWQgb2NjdXJyZW5jZSBhcyBjbG9zZSB0byB0aGUg
c291cmNlIG9mIHRoZSBEaWFtZXRlciB0cmFmZmljIGFzPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk
LWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBmZWFzaWJsZS48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZxdW90O3NjZW5haW9zJnF1b3Q7IC0mZ3Q7ICZxdW90O3NjZW5hcmlv
cyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtc28t
ZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu
Zzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh
ay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW47Ym94LXNpemluZzpib3JkZXItYm94O3dvcmQt
d3JhcDpicmVhay13b3JkO2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5UaGUgUGVlciBvdmVybG9hZCByZXBv
cnQgdHlwZSBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJv
dHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVy
Om5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsgZGVmaW5lZCBpbiBhIGdlbmVyaWMgZmFzaGlvbiBzbyB0aGF0IGl0
IGNhbiBhbHNvIGJlIHVzZWQgZm9yIG90aGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFr
OmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBEaWFtZXRlciBvdmVybG9hZCA8Yj5z
Y2VuYXJpb3M8L2I+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIHNlY3Rpb24gMy4xLjEgKGVkaXRvcmlhbCkg
cmVwbGFjZWQgJnF1b3Q7d2VyZSZxdW90Oy0mZ3Q7ICZxdW90O3dhcyZxdW90OzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRl
ci1kaXY7Ym9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBw
dCA4LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3
LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7
cGFkZGluZzowaW47Ym94LXNpemluZzpib3JkZXItYm94O3dvcmQtd3JhcDpicmVhay13b3JkO2Jv
cmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2NvbG9yOmJsYWNrIj5JbiBib3RoIG9mIHRoZXNlIGNhc2VzLCB0aGUgb2NjdXJyZW5jZSBv
ZiBvdmVybG9hZCBpbiB0aGUgc2luZ2xlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy
ZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhZ2VudCBtdXN0IGJ5IGhhbmRsZWQgYnkg
dGhlIGNsaWVudCBpbiBhIHNpbWlsYXIgZmFzaGlvbiBhcyBpZiB0aGU8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZG
REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGNsaWVudCA8
Yj53YXM8L2I+IGhhbmRsaW5nIHRoZSBvdmVybG9hZCBvZiBhIGRpcmVjdGx5IGNvbm5lY3RlZCBz
ZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gc2VjdGlvbiAzLjEuMSAocXVlc3Rpb24pPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9y
ZGVyLWRpdjtib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDgu
MHB0IDguMHB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9u
ZTtwYWRkaW5nOjBpbjtib3gtc2l6aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7
Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Y29sb3I6YmxhY2siPkFuIGFwcHJvcHJpYXRlIGVycm9yIHJlc3BvbnNlIGlzIHNlbnQg
YmFjayB0byB0aGUgb3JpZ2luYXRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh
ay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgb2YgdGhlIHJlcXVlc3QuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PldobyBzZW5kcyAmcXVvdDthbiBhcHByb3ByaWF0ZSZxdW90OyBlcnJvciByZXNwb25zZSZxdW90
OyBpbiB0aGlzIGNhc2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjQuIHNlY3Rpb24gMy4xLjIgKGVkaXRvcmlhbCkgY2hhbmdlZCAmcXVvdDt0
byZxdW90Oy0mZ3Q7JnF1b3Q7dGhlJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6
I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG
RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbjtib3gtc2l6
aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3Zl
cmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPldo
ZW4gdGhlIGNsaWVudCBoYXMgYW4gYWN0aXZlIGFuZCBhIHN0YW5kYnkgY29ubmVjdGlvbiB0byB0
aGUgdHdvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9u
ZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si
PiZuYnNwOyZuYnNwOyBhZ2VudHMgdGhlbiBhbiBhbHRlcm5hdGl2ZSBzdHJhdGVneSBmb3IgcmVz
cG9uZGluZyB0byBhbiBvdmVybG9hZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh
ay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVwb3J0IGZyb20gYW4gYWdlbnQgaXMgdG8g
Y2hhbmdlIDxiPnRoZSA8L2I+c3RhbmRieSBjb25uZWN0aW9uIHRvIGFjdGl2ZSBhbmQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy
b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGlu
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7
IHJvdXRlIGFsbCB0cmFmZmljIHRocm91Z2ggdGhlIG5ldyBhY3RpdmUgY29ubmVjdGlvbi48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj41LiBzZWN0aW9uIDMuMS4zIChlZGl0b3JpYWwpPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjti
b3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0
O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2Jh
Y2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5n
OjBpbjtib3gtc2l6aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJh
ZGl1czo0cHg7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s
b3I6YmxhY2siPkFuIGV4YW1wbGUgb2YgdGhpcyB0eXBlIG9mIGRlcGxveW1lbnQgaW5jbHVkZTxi
PnM8L2I+IHdoZW4gdGhlcmUgYXJlIERpYW1ldGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy
ZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhZ2VudHMgYmV0d2VlbiBhZG1p
bmlzdHJhdGl2ZSBkb21haW5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj42LiBzZWN0aW9uIDMuMS4zPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIG5v
IHNlY3Rpb24gMi4yLiBJIGd1ZXNzIHNlY3Rpb24gMy4xLjIgd2FzIG1lYW50IGhlcmUsIHJpZ2h0
PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVu
dDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBw
dCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHByZSBzdHlsZT0ibWFy
Z2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7
Ym9yZGVyOm5vbmU7cGFkZGluZzowaW47Ym94LXNpemluZzpib3JkZXItYm94O3dvcmQtd3JhcDpi
cmVhay13b3JkO2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5IYW5kbGluZyBvZiBvdmVybG9hZCBvZiBvbmUg
b3IgYm90aCBvZiBhZ2VudHMgYTExIG9yIGExMiBpbiB0aGlzIGNhc2U8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZG
REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGlzIGVxdWl2
YWxlbnQgdG8gdGhhdCBkaXNjdXNzZWQgaW4gc2VjdGlvbiAyLjIuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ny4g
c2VjdGlvbiAzLjIuMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JdCBpcyBub3QgY2xlYXIgd2hpY2ggdXNhZ2Ugc2NlbmFyaW8gaXMgbWVhbnQg
aGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibXNvLWVs
ZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst
YWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluO2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdy
YXA6YnJlYWstd29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEl0IGlzIGVudmlz
aW9uZWQgdGhhdCBhYmF0ZW1lbnQgYWxnb3JpdGhtcyB3aWxsIGJlIGRlZmluZWQgdGhhdCB3aWxs
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0
O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRk
aW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNw
OyZuYnNwOyBzdXBwb3J0IHRoZSBvcHRpb24gZm9yIERpYW1ldGVyIEVuZHBvaW50cyB0byBzZW5k
IHBlZXIgcmVwb3J0cy4mbmJzcDsgRm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy
ZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpbnN0YW5jZSwgaXQgaXMgZW52aXNpb25l
ZCB0aGF0IG9uZSB1c2FnZSBzY2VuYXJpbyBmb3IgdGhlIHJhdGU8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1
O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFsZ29yaXRobSwg
W0ktRC5pZXRmLWRpbWUtZG9pYy1yYXRlLWNvbnRyb2xdLCB3aGljaCBpcyBiZWluZyB3b3JrZWQ8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7
YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRp
bmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7
Jm5ic3A7IG9uIGJ5IHRoZSBESU1FIHdvcmtpbmcgZ3JvdXAgYXMgdGhpcyBkb2N1bWVudCBpcyBi
ZWluZyB3cml0dGVuLCB3aWxsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs
bDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpbnZvbHZlIGFiYXRlbWVudCBiZWluZyBkb25lIG9u
IGEgaG9wLWJ5LWhvcCBiYXNpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj44LiBzZWN0aW9uIDQ8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5IGlzIHRocm90
dGxpbmcgdG8gYmUgYXBwbGllZCBhbmQgbm90IGRpdmVyc2lvbiAobGlrZSBpbiBjYXNlIG9mIHJl
ZHVuZGFudCBhZ2VudHMpPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5kOiNGRkZE
RjUiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7
d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW47Ym94LXNpemluZzpi
b3JkZXItYm94O3dvcmQtd3JhcDpicmVhay13b3JkO2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5JbiB0aGlz
IHNjZW5hcmlvIHRoZSByZWFjdGluZyBub2RlIHNob3VsZCBmaXJzdCBoYW5kbGUgdGhlIHRocm90
dGxpbmcgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3Jk
ZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6
YmxhY2siPiZuYnNwOyZuYnNwOyBvdmVybG9hZGVkIGhvc3Qgb3IgcmVhbG0uPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZxdW90O0xPU1MmcXVvdDsgSXMgaXQgYSBuZXcgdHlwZSBkZWZpbmVkIGluIHRoZSBzY29wZSBv
ZiB0aGlzIGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVh
azpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW47Ym94LXNpemluZzpib3JkZXItYm94
O3dvcmQtd3JhcDpicmVhay13b3JkO2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5Ob3RlOiBUaGUgZ29hbCBp
cyB0byBhdm9pZCB0cmFmZmljIG9zY2lsbGF0aW9ucyB0aGF0IG1pZ2h0IHJlc3VsdDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv
dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgZnJvbSB0aHJvdHRsaW5nIG9mIG1lc3NhZ2VzIGZvciBib3RoIHRo
ZSBIT1NUL1JFQUxNIG92ZXJsb2FkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr
LWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXBvcnRzIGFu
ZCB0aGUgUEVFUiBvdmVybG9hZCByZXBvcnRzLiZuYnNwOyBUaGlzIGlzIGVzcGVjaWFsbHkgYTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti
YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGlu
ZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uY2VybiBpZiA8Yj5ib3RoIHJlcG9ydHMgYXJlIG9m
IHR5cGUgTE9TUzwvYj4uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OS4gc2VjdGlvbiA1LjEuMTxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcm9iYWJseSBpdCBp
cyBiZXR0ZXIgdG8gZGVzY3JpYmUgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZSBpbiBzZWN0aW9uIDUu
MT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk90
aGVyd2lzZSwgaXQgaXMgdXNlZCBhcyBhIHdlbGwta25vd24gb25lIHdoaWxlIGl0IGlzIHRoZSBm
aXJzdCBwbGFjZSB3aGVyZSBpdCBpcyBtZW50aW9uZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28gSSB0aGluayBpdCBpcyBiZXR0ZXIg
dG8gYWRkIG1vcmUgc3BlY2lmaWMgaW4gdGhpcyBkcmFmdCByZWxhdGVkIHRvIHBlZXIgcmVwb3J0
IGhhbmRsaW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+LSBkZWZpbmUgUGVlciBSZXBvcnQgUmVhY3RpbmcgTm9kZSBhbmQgUGVlciBSZXBvcnQg
UmVwb3J0aW5nIE5vZGUgdGVybXMgZXhwbGljaXRseSBhbmQgdXNlIHRoZW0gdGhyb3VnaCB0aGUg
ZHJhZnQgYW5kIGVzcGVjaWFsbHkgc3RhcnRpbmcgZnJvbSBzZWN0aW9uIDUuMSZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBhZGQgJnF1
b3Q7UGVlciBSZXBvcnQmcXVvdDsgcHJlZml4IHRvIGFsbCB0aGUgZGVzY3JpYmVkIHByb2NlZHVy
ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4
YW1wbGU6IENhcGFiaWxpdHkgQW5ub3VuY2VtZW50IC0mZ3Q7IFBlZXIgUmVwb3J0IENhcGFiaWxp
dHkgQW5ub3VuY2VtZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjEwLiBzZWN0aW9uIDUuMS4xL2dlbmVyYWw8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7RGlhbWV0ZXJJZGVudGl0
eSZxdW90OyBhbmQgJnF1b3Q7RGlhbWV0ZXIgaWRlbnRpdHkmcXVvdDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHByb3Bvc2FsIGlzIHRvIHVz
ZSBvbmUgdGVybSB0aHJvdWdoIHRoZSBzcGVjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VbmRlciAmcXVvdDtET0lDIG5vZGUmcXVvdDssIGFu
IGFnZW50IGlzIG1lYW50IGhlcmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6I0ZGRkRG
NSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3
b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbjtib3gtc2l6aW5nOmJv
cmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZsb3c6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiBXaGVuIGFu
IGFnZW50IHJlbGF5cyBhIHJlcXVlc3QgdGhhdCBpbmNsdWRlcyBhIFNvdXJjZUlEIEFWUCBpbiB0
aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45
cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3Bh
ZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7IE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAsIGEgRE9JQyBub2RlIHRoYXQgc3Vw
cG9ydHMgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6
bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh
Y2siPiZuYnNwOyZuYnNwOyBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlIE1VU1QgcmVtb3ZlIHRoZSBy
ZWNlaXZlZCBTb3VyY2VJRCBBVlAgYW5kPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy
ZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyByZXBsYWNlIGl0IHdpdGggYSBTb3VyY2VJ
RCBBVlAgY29udGFpbmluZyBpdHMgb3duIERpYW1ldGVyIGlkZW50aXR5LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk15IHByb3Bvc2FsIGlzIHRvIHVzZSBwZWVyIHJlcG9ydCByZWFjdGluZyBub2RlIGhlcmUgcmUt
cGhyYXNpbmcgdGhpcyBzdGF0ZW1lbnQgYmVsb3cgaW4gdGhlIGZvbGxvd2luZyB3YXk6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEt
Ym9yZGVyLWRpdjtib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0
IDguMHB0IDguMHB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6
bm9uZTtwYWRkaW5nOjBpbjtib3gtc2l6aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdv
cmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Y29sb3I6YmxhY2siPiBXaGVuIHJlbGF5aW5nIGEgcmVxdWVzdCB0aGF0IGluY2x1
ZGVzIGEgU291cmNlSUQgQVZQIGluIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpi
cmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFW
UCwgYSBwZWVyIHJlcG9ydCByZWFjdGluZyBub2RlIE1VU1QgcmVtb3ZlIHRoZSByZWNlaXZlZCBT
b3VyY2VJRCBBVlAgYW5kPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDti
b3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s
b3I6YmxhY2siPiZuYnNwOyZuYnNwOyByZXBsYWNlIGl0IHdpdGggYSBTb3VyY2VJRCBBVlAgY29u
dGFpbmluZyBpdHMgb3duIERpYW1ldGVySWRlbnRpdHkuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjExLiBzZWN0aW9u
IDUuMS4yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPmFkZGVkIHRoZSBtaXNzZWQgJnF1b3Q7dG8mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNoYW5nZWQgJnF1b3Q7UEVFUl9SRVBPUlQm
cXVvdDstJmd0OyAmcXVvdDtQRUVSJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6
I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG
RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbjtib3gtc2l6
aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3Zl
cmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPk5v
dGU6IFRoZSB0cmFuc2FjdGlvbiBzdGF0ZSBpcyB1c2VkIHdoZW4gdGhlIERPSUMgbm9kZSBpcyBh
Y3Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206
Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25l
O3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIGEgcGVlci1yZXBvcnQgcmVwb3J0aW5n
IG5vZGUgYW5kIG5lZWRzIDxiPnRvIDwvYj5zZW5kIE9DLU9MUiByZXBvcnRzIG9mPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91
bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB0eXBlIDxiPlBFRVIgPC9iPmluIGFuc3dlciBtZXNzYWdlcy4mbmJz
cDsgVGhlIHBlZXIgb3ZlcmxvYWQgcmVwb3J0czxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVh
azpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJl
IG9ubHkgaW5jbHVkZWQgaW4gYW5zd2VyIG1lc3NhZ2VzIGJlaW5nIHNlbnQgdG8gcGVlcnMgdGhh
dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3Ljlw
dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFk
ZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VwcG9ydCB0aGUgT0NfUEVFUl9SRVBPUlQgZmVh
dHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtEaWFtZXRlciBJRCZxdW90OyB0ZXJtIGlzIG5vdCBj
bGFyaWZpZWQgYW55d2hlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5SZS1waHJhc2VkIHRoZSBhcHByb3ByaWF0ZSBzdGF0ZW1lbnQgYSBsaXR0
bGUgYml0LCBjaGFuZ2VkICZxdW90O0RpYW1ldGVyIElEJnF1b3Q7LSZndDsmcXVvdDt2YWx1ZSZx
dW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
QWxzbyB0aGVyZSBhcmUgb3RoZXIgcGxhY2VzIGluIHRoZSBkcmFmdCB3aGVyZSAmcXVvdDtEaWFt
ZXRlciBJRCZxdW90OyB0ZXJtIGlzIHVzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6
I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG
RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbjtib3gtc2l6
aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3Zl
cmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRo
ZSBwZWVyIHN1cHBvcnRzIHRoZSBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlIGlmIHRoZSByZWNlaXZl
ZCByZXF1ZXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6
bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh
Y2siPiZuYnNwOyZuYnNwOyBjb250YWlucyBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIHdp
dGggdGhlIE9DLUZlYXR1cmUtVmVjdG9yIHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl
YWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoZSBPQ19QRUVSX1JFUE9SVCBm
ZWF0dXJlIGJpdCBzZXQgYW5kIHdpdGggYSBTb3VyY2VJRCBBVlAgd2l0aCBhPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6
I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB2YWx1
ZSB0aGF0IG1hdGNoZXMgdGhlIERpYW1ldGVySWRlbnRpdHkgb2YgdGhlIHBlZXIgZnJvbSB3aGlj
aDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3Ljlw
dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFk
ZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsgdGhlIHJlcXVlc3Qgd2FzIHJlY2VpdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFnZW50IGlz
IG1lYW50IHVuZGVyICZxdW90O3JlcG9ydGluZyBub2RlJnF1b3Q7IGhlcmU/PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNob3VsZCBub3QgU291
cmNlSUQgQVZQIG5vdCBqdXN0IHN0cmlwcGVkIGZyb20gdGhlIHJlbGF5ZWQgYW5zd2VyLCBidXQg
cmVwbGFjZWQgd2l0aCB0aGUgU291cmNlSUQgQVZQIGNvbnRhaW5pbmcgdGhlIERpYW1ldGVySWRl
bnRpdHkgb2YgdGhlIGFnZW50IHN1cHBvcnRpbmcgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZT88bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFy
YS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4w
cHQgOC4wcHQgOC4wcHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1i
b3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRl
cjpub25lO3BhZGRpbmc6MGluO2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdyYXA6YnJlYWst
d29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtjb2xvcjpibGFjayI+V2hlbiBhbiBhZ2VudCByZWxheXMgYW4gYW5zd2VyIG1l
c3NhZ2UsIGEgcmVwb3J0aW5nIG5vZGUgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVh
azpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc3VwcG9ydHMgdGhlIE9DX1BFRVJf
UkVQT1JUIGZlYXR1cmUgTVVTVCBzdHJpcCBhbnkgU291cmNlSUQgQVZQIGZyb208bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3Vu
ZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRo
ZSBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhcmQgdG8gZm9sbG93
IHdoYXQgd2FzIHdhbnRlZCB0byBzYXkgaGVyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvcnJlY3RlZCB0aGUgc3RhdGVtZW50LCBidXQgdGhp
cyBpcyBqdXN0IG15IGJlc3QgZ3Vlc3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQ6I0ZG
RkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRG
NTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbjtib3gtc2l6aW5n
OmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZs
b3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlRoZSBP
Qy1QZWVyLUFsZ28gQVZQIE1VU1QgaW5kaWNhdGUgdGhlIG92ZXJsb2FkIGFiYXRlbWVudDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr
Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzow
aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsgYWxnb3JpdGhtIHRoYXQgdGhlIHJlcG9ydGluZyBub2RlIHdhbnRzIHRoZSByZWFjdGluZyBu
b2RlcyB0byB1c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1i
b3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRl
cjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7IDxiPndoZW4gPC9iPnRoZSByZXBvcnRpbmcgbm9kZSBzZW5kPGI+
czwvYj4gYSBwZWVyIG92ZXJsb2FkIHJlcG9ydCBhcyBhIHJlc3VsdCBvZjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG
RkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYmVjb21p
bmcgb3ZlcmxvYWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgbm90IHdlIGFkZCBhIHNlcGFyYXRl
IGlmLSBzdGF0ZW1lbnQgZm9yIHRoZSBjYXNlIHdoZW4gdGhlIHBlZXIgZG9lcyBub3Qgc3VwcG9y
dCBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlIHdoZW4gc2VuZGluZyBhbiBhbnN3ZXIgbWVzc2FnZT88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MTIu
IHNlY3Rpb24gNS4xLjEgYW5kIDUuMS4yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByb2JhYmx5IGl0IGlzIG1vcmUgaGVscGZ1bCB0byBpbGx1
c3RyYXRlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgQ0EgdXNpbmcgc2VxdWVuY2UgZGlhZ3JhbXMg
bGlrZSBpbiB0aGUgbG9hZCBpbmZvIGNvbnZleWFuY2UgZHJhZnQuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEzLiBnZW5lcmFsLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGFib3V0
IHRvIHVzZSB0aGUgd3JpdGluZyBmb3IgdGhlIHNhbWUgdGVybXMgdGhyb3VnaCB0aGUgc3BlYz88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4YW1w
bGUxOiAmcXVvdDtET0lDIG5vZGUmcXVvdDsgYW5kICZxdW90O0RPSUMgTm9kZSZxdW90OzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXhhbXBsZTI6
ICZxdW90O3BlZXItcmVwb3J0IHJlcG9ydGluZyBub2RlJnF1b3Q7IGFuZCAmcXVvdDtwZWVyIHJl
cG9ydCByZXBvcnRpbmcgbm9kZSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xNC4gc2VjdGlvbiA1LjIuMS4yLCA1LjIuMiwgNS4yLjMg
YW5kIGdlbmVyYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+JnF1b3Q7cGVlci10eXBlIE9DUyZxdW90OyBhbmQgJnF1b3Q7cGVlciByZXBvcnQg
T0NTJnF1b3Q7IGRlZmluZSB0aGUgc2FtZSB0ZXJtPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5IG5vdCB0byB1c2Ugb25seSBvbmU/PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFub3RoZXIg
ZXhhbXBsZTogJnF1b3Q7cGVlciByZXBvcnQmcXVvdDsgYW5kICZxdW90O3BlZXIgcmVwb3J0LXR5
cGUmcXVvdDsgYW5kICZxdW90O3JlcG9ydCBvZiB0eXBlIFBFRVImcXVvdDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MTUuIHNlY3Rpb24gNS4y
LjM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
UHJvYmFibHkgaXQgaXMgYmV0dGVyIHRvIHJlLXBocmFzZSB0aGlzIHN0YXRlbWVudCBhIGxpdHRs
ZSBiaXQgJiM0MzsgY29ycmVjdGVkIHRoZSBtaXNwcmludHMuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3Jk
ZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2Jh
Y2tncm91bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tn
cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBp
bjtib3gtc2l6aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1
czo0cHg7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6
YmxhY2siPklmIGEgPGI+cGVlciByZXBvcnQ8L2I+IHJlYWN0aW5nIG5vZGUgcmVjZWl2ZXMgYW4g
T0MtT0xSIEFWUCBvZiB0eXBlIHBlZXIgYW5kIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i
cmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5Tb3VyY2VJRCBtYXRjaGVzIHRoZSA8Yj5EaWFtZXRl
cklkZW50aXR5IDwvYj5vZiB0aGUgcGVlciBmcm9tIHdoaWNoIHRoZSA8Yj5yZXBvcnQ8L2I+PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2Jh
Y2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5n
OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPndhcyByZWNl
aXZlZCB0aGVuIHRoZSByZXBvcnQgd2FzIDxiPmdlbmVyYXRlZCA8L2I+YnkgdGhlIHBlZXIuPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+U2ltaWxhciBjb21tZW50ICYjNDM7IGNvcnJlY3RlZCBtaXNwcmludHMgZm9y
IHRoZSBuZXh0IHN0YXRlbWVudDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQ7YmFja2dyb3VuZDojRkZGREY1
Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv
cmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluO2JveC1zaXppbmc6Ym9y
ZGVyLWJveDt3b3JkLXdyYXA6YnJlYWstd29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SWYgYSBwZWVy
IHJlcG9ydCByZWFjdGluZyBub2RlIHJlY2VpdmVzIGFuIE9DLU9MUiBBVlAgb2YgdHlwZSBwZWVy
IGFuZCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0
b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpu
b25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj
ayI+U291cmNlSUQgZG9lcyBub3QgbWF0Y2ggdGhlIDxiPkRpYW1ldGVySWRlbnRpdHkgPC9iPm9m
IHRoZSBwZWVyIGZyb20gd2hpY2ggdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy
ZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Y29sb3I6YmxhY2siPnJlcG9ydCA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj53YXMgcmVjZWl2ZWQgdGhlbiB0aGUgcmVhY3Rpbmcg
bm9kZSBNVVNUIGlnbm9yZSB0aGUgb3ZlcmxvYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl
YWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtjb2xvcjpibGFjayI+cmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNv
IEkgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIHVzZSBvbmUgd29yZGluZyBmb3IgdGhlIHNhbWUgdGVy
bTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZx
dW90O1BlZXIgUmVwb3J0IE9MUiZxdW90OywgJnF1b3Q7T0MtT0xSIEFWUCZxdW90OywgJnF1b3Q7
T0xSJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5MZXQncyB1c2UgYSBnZW5lcmljIG9uZSAmcXVvdDtwZWVyIHJlcG9ydCZxdW90Oz88bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5KdXN0IG1pbm9yIGNvbW1lbnQ6ICZxdW90O3RoZSBleGlzdGluZy4uLiZxdW90OyBhbmQgJnF1
b3Q7YSBuZXcgb3ZlcmxvYWQgY29uZGl0aW9uJnF1b3Q7IGZvciBhbGwgb2NjdXJyZW5jZXMgaWYg
bXkgRW5nbGlzaCBpcyBjb3JyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4xNi4gc2VjdGlvbiA1LjIuMzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgbWF5IGl0IGhhcHBlbiB0aGF0
IHBlZXIgcmVwb3J0IHJlYWN0aW5nIG5vZGUgcmVjZWl2ZXMgYSBwZWVyIHJlcG9ydCBub3QgZnJv
bSB0aGUgcGVlciB0aGF0IGdlbmVyYXRlZCBpdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlZXIgcmVwb3J0cyBjYW4gYmUgc2VudCBvbmx5IHRv
IHBlZXIgcmVwb3J0IHJlYWN0aW5nIG5vZGUsIHJpZ2h0PyBBbmQgcGVlciByZXBvcnRzIGFyZSBu
b3QgcmVsYXllZCwgcmlnaHQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L01pc2hhPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNy0wMS0wOSAxNzozNSBHTVQmIzQz
OzAzOjAwIFRoZSBJRVNHICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5pZXNnLXNlY3JldGFyeUBpZXRmLm9yZzwvYT4mZ3Q7OjxvOnA+
PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBJ
RVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgRGlhbWV0ZXIgTWFpbnRlbmFuY2Ug
YW5kPGJyPg0KRXh0ZW5zaW9ucyBXRyAoZGltZSkgdG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBk
b2N1bWVudDo8YnI+DQotICdEaWFtZXRlciBBZ2VudCBPdmVybG9hZCBhbmQgdGhlIFBlZXIgT3Zl
cmxvYWQgUmVwb3J0Jzxicj4NCiZuYnNwOyAmbHQ7ZHJhZnQtaWV0Zi1kaW1lLWFnZW50LW92ZXJs
b2FkLTA4LnR4dCZndDsgYXMgUHJvcG9zZWQgU3RhbmRhcmQ8YnI+DQo8YnI+DQpUaGUgSUVTRyBw
bGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNp
dHM8YnI+DQpmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3Rh
bnRpdmUgY29tbWVudHMgdG8gdGhlPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmci
PmlldGZAaWV0Zi5vcmc8L2E+IG1haWxpbmcgbGlzdHMgYnkgMjAxNy0wMS0yMy4gRXhjZXB0aW9u
YWxseSwgY29tbWVudHMgbWF5IGJlPGJyPg0Kc2VudCB0byA8YSBocmVmPSJtYWlsdG86aWVzZ0Bp
ZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4gaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFz
ZSByZXRhaW4gdGhlPGJyPg0KYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cg
YXV0b21hdGVkIHNvcnRpbmcuPGJyPg0KPGJyPg0KQWJzdHJhY3Q8YnI+DQo8YnI+DQo8YnI+DQom
bmJzcDsgJm5ic3A7VGhpcyBzcGVjaWZpY2F0aW9uIGRvY3VtZW50cyBhbiBleHRlbnNpb24gdG8g
UkZDIDc2ODMgKERpYW1ldGVyPGJyPg0KJm5ic3A7ICZuYnNwO092ZXJsb2FkIEluZGljYXRpb24g
Q29udmV5YW5jZSAoRE9JQykpIGJhc2Ugc29sdXRpb24uJm5ic3A7IFRoZSBleHRlbnNpb248YnI+
DQombmJzcDsgJm5ic3A7ZGVmaW5lcyB0aGUgUGVlciBvdmVybG9hZCByZXBvcnQgdHlwZS4mbmJz
cDsgVGhlIGluaXRpYWwgdXNlIGNhc2UgZm9yIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtQZWVyIHJl
cG9ydCBpcyB0aGUgaGFuZGxpbmcgb2Ygb2NjdXJyZW5jZXMgb2Ygb3ZlcmxvYWQgb2YgYSBEaWFt
ZXRlcjxicj4NCiZuYnNwOyAmbmJzcDthZ2VudC48YnI+DQo8YnI+DQpSZXF1aXJlbWVudHM8YnI+
DQo8YnI+DQo8YnI+DQo8YnI+DQpUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhPGJyPg0KPGEg
aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLWFn
ZW50LW92ZXJsb2FkLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZC88L2E+PGJyPg0KPGJyPg0KSUVT
RyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYTxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZC9iYWxs
b3QvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtaWV0Zi1kaW1lLWFnZW50LW92ZXJsb2FkL2JhbGxvdC88L2E+PGJyPg0KPGJyPg0KPGJyPg0K
Tm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMg
SS1ELjxicj4NCjxicj4NCjxicj4NClRoZSBkb2N1bWVudCBjb250YWlucyB0aGVzZSBub3JtYXRp
dmUgZG93bndhcmQgcmVmZXJlbmNlcy48YnI+DQpTZWUgUkZDIDM5NjcgZm9yIGFkZGl0aW9uYWwg
aW5mb3JtYXRpb246PGJyPg0KJm5ic3A7ICZuYnNwOyBkcmFmdC1yb2FjaC1kaW1lLW92ZXJsb2Fk
LWN0cmw6IEEgTWVjaGFuaXNtIGZvciBEaWFtZXRlciBPdmVybG9hZCBDb250cm9sIChOb25lIC0g
KTxicj4NCk5vdGUgdGhhdCBzb21lIG9mIHRoZXNlIHJlZmVyZW5jZXMgbWF5IGFscmVhZHkgYmUg
bGlzdGVkIGluIHRoZSBhY2NlcHRhYmxlIERvd25yZWYgUmVnaXN0cnkuPGJyPg0KPGJyPg0KPGJy
Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpE
aU1FIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1F
QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZGltZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZGltZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGJyPg0KPHA+VGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgdHJhbnNtaXNzaW9uIGNvbnRh
aW5zIGluZm9ybWF0aW9uIGZyb20gQ1NSQSB0aGF0IG1heSBiZSBhdHRvcm5leS1jbGllbnQgcHJp
dmlsZWdlZCwgcHJvcHJpZXRhcnkgb3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaW4g
dGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHVzZSBieSB0aGUgaW5kaXZpZHVhbChz
KSB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGJlbGlldmUNCiB5b3UgaGF2ZSByZWNl
aXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBjb250YWN0IG1lIGltbWVkaWF0ZWx5
IGFuZCBiZSBhd2FyZSB0aGF0IGFueSB1c2UsIGRpc2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJp
YnV0aW9uIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGli
aXRlZC4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGVtYWlsIHNoYWxsIG5vdCBv
cGVyYXRlIHRvIGJpbmQNCiBDU1JBIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxl
c3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBp
bml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZW1haWwgZm9yIHN1Y2gg
cHVycG9zZS48L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_c5efbe4b018646489bb21b75a81e6836CSRRDU1EXM025corpcsraco_--


From nobody Tue Jan 17 18:04:36 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891431295F0; Tue, 17 Jan 2017 18:04:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq354gCaS1VR; Tue, 17 Jan 2017 18:04:31 -0800 (PST)
Received: from mailport8.csra.com (mailport8.csra.com [131.131.97.26]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE18C1294EB; Tue, 17 Jan 2017 18:04:30 -0800 (PST)
Received: from csrrdu1exm029.corp.csra.com (HELO mail.csra.com) ([10.8.2.29]) by mailport8.csra.com with ESMTP/TLS/AES256-SHA; 17 Jan 2017 21:04:29 -0500
Received: from CSRRDU1EXM025.corp.csra.com (10.8.2.25) by CSRRDU1EXM021.corp.csra.com (10.8.2.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 21:04:28 -0500
Received: from CSRRDU1EXM025.corp.csra.com ([10.8.2.25]) by CSRRDU1EXM025.corp.csra.com ([10.8.2.25]) with mapi id 15.00.1210.000; Tue, 17 Jan 2017 21:04:28 -0500
From: "Gunn, Janet P" 
To: Misha Zaytsev 
Thread-Topic: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
Thread-Index: AQHSaoWzoyfk6GZ4r0WNj5yOH2cKTaE9ffWA//+6NiCAAFbJgP//+i3A
Date: Wed, 18 Jan 2017 02:04:28 +0000
Message-ID: <82cae801ab704dc483228653735ddb6a@CSRRDU1EXM025.corp.csra.com>
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.136.2.8]
Content-Type: multipart/alternative; boundary="_000_82cae801ab704dc483228653735ddb6aCSRRDU1EXM025corpcsraco_"
MIME-Version: 1.0
Archived-At: 
Cc: IETF-Announce , "dime-chairs@ietf.org" , "dime@ietf.org" , "ietf@ietf.org" , "draft-ietf-dime-agent-overload@ietf.org" 
Subject: Re: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jan 2017 02:04:34 -0000

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

SnVzdCB0aGUgdmFnYXJpZXMgb2YgRW5nbGlzaCBncmFtbWFyLg0KDQpJIHRob3VnaHQgdGhlIHJl
c3Qgb2YgeW91ciBjb21tZW50cyB3ZXJlIGdvb2QgY2F0Y2hlcy4NCg0KSmFuZXQNCg0KRnJvbTog
TWlzaGEgWmF5dHNldiBbbWFpbHRvOm1pc2hhLnpheXRzZXYucnVzQGdtYWlsLmNvbV0NClNlbnQ6
IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTcgNDoyNSBQTQ0KVG86IEd1bm4sIEphbmV0IFAgPEph
bmV0Lkd1bm5AY3NyYS5jb20+DQpDYzogaWV0ZkBpZXRmLm9yZzsgZGltZS1jaGFpcnNAaWV0Zi5v
cmc7IGRpbWVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZEBpZXRmLm9y
ZzsgSUVURi1Bbm5vdW5jZSA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb
RGltZV0gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1kaW1lLWFnZW50LW92ZXJsb2FkLTA4LnR4dD4g
KERpYW1ldGVyIEFnZW50IE92ZXJsb2FkIGFuZCB0aGUgUGVlciBPdmVybG9hZCBSZXBvcnQpIHRv
IFByb3Bvc2VkIFN0YW5kYXJkDQoNCkhpIEphbmV0LA0KDQpPSywgSSB3aWxsIG5vdCBhcmd1ZSA6
KQ0KLTEgY29tbWVudCBmb3IgU3RldmUgdG8gYW5zd2VyLg0KDQovTWlzaGENCg0KMjAxNy0wMS0x
OCAwOjE2IEdNVCswMzowMCBHdW5uLCBKYW5ldCBQIDxKYW5ldC5HdW5uQGNzcmEuY29tPG1haWx0
bzpKYW5ldC5HdW5uQGNzcmEuY29tPj46DQpQb2ludCBudW1iZXIgMi0NCg0KIkFzIGlmIHRoZSBj
bGllbnQgd2VyZSDigKYiIGlzIGNvcnJlY3QgKHN1Ymp1bmN0aXZlIGZvciBhICJjb25kaXRpb24g
Y29udHJhcnkgdG8gZmFjdCIpDQoNCiJBcyBpZiB0aGUgY2xpZW50ICB3YXMiIOKApiBpcyBncmFt
bWF0aWNhbGx5IElOQ09SUkVDVC4NCg0KSmFuZXQNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUt
Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxm
IE9mIE1pc2hhIFpheXRzZXYNClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTcgMzoyNCBQ
TQ0KVG86IGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+DQpDYzogZGltZS1jaGFp
cnNAaWV0Zi5vcmc8bWFpbHRvOmRpbWUtY2hhaXJzQGlldGYub3JnPjsgZGltZUBpZXRmLm9yZzxt
YWlsdG86ZGltZUBpZXRmLm9yZz47IGRyYWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZEBpZXRm
Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1kaW1lLWFnZW50LW92ZXJsb2FkQGlldGYub3JnPjsgSUVU
Ri1Bbm5vdW5jZSA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aWV0Zi1hbm5vdW5jZUBp
ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0RpbWVdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtZGlt
ZS1hZ2VudC1vdmVybG9hZC0wOC50eHQ+IChEaWFtZXRlciBBZ2VudCBPdmVybG9hZCBhbmQgdGhl
IFBlZXIgT3ZlcmxvYWQgUmVwb3J0KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpIaSBBbGwsDQoN
CkhlcmUgYXJlIG15IGNvbW1lbnRzL3F1ZXN0aW9ucyB0byBhbiBhZ2VudCBvdmVybG9hZCBkcmFm
dC4NClRoaXMgdGhlIGZpcnN0IHBhcnQuIExhdGVyIG9uIEkgd2lsbCBjb21wbGV0ZSBteSByZXZp
ZXcgYW5kIHNlbmQgb3V0IHRoZSBzZWNvbmQgcG9ydGlvbiBvZiB0aGUgY29tbWVudHMuDQoNCjEu
IHNlY3Rpb24gMSAoZWRpdG9yaWFsKSByZW1vdmVkICJpcyIgYmVmb3JlICJmZWFzaWJsZSIuDQoN
Cg0KSW4gdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbiwgdGhlIGdvYWwgaXMgdG8gaGFuZGxlIGFiYXRl
bWVudCBvZiB0aGUNCg0KICAgb3ZlcmxvYWQgb2NjdXJyZW5jZSBhcyBjbG9zZSB0byB0aGUgc291
cmNlIG9mIHRoZSBEaWFtZXRlciB0cmFmZmljIGFzDQoNCiAgIGZlYXNpYmxlLg0KDQoic2NlbmFp
b3MiIC0+ICJzY2VuYXJpb3MiDQoNCg0KVGhlIFBlZXIgb3ZlcmxvYWQgcmVwb3J0IHR5cGUgaXMN
Cg0KICAgZGVmaW5lZCBpbiBhIGdlbmVyaWMgZmFzaGlvbiBzbyB0aGF0IGl0IGNhbiBhbHNvIGJl
IHVzZWQgZm9yIG90aGVyDQoNCiAgIERpYW1ldGVyIG92ZXJsb2FkIHNjZW5hcmlvcy4NCg0KMi4g
c2VjdGlvbiAzLjEuMSAoZWRpdG9yaWFsKSByZXBsYWNlZCAid2VyZSItPiAid2FzIg0KDQoNCklu
IGJvdGggb2YgdGhlc2UgY2FzZXMsIHRoZSBvY2N1cnJlbmNlIG9mIG92ZXJsb2FkIGluIHRoZSBz
aW5nbGUNCg0KICAgYWdlbnQgbXVzdCBieSBoYW5kbGVkIGJ5IHRoZSBjbGllbnQgaW4gYSBzaW1p
bGFyIGZhc2hpb24gYXMgaWYgdGhlDQoNCiAgIGNsaWVudCB3YXMgaGFuZGxpbmcgdGhlIG92ZXJs
b2FkIG9mIGEgZGlyZWN0bHkgY29ubmVjdGVkIHNlcnZlci4NCg0KMy4gc2VjdGlvbiAzLjEuMSAo
cXVlc3Rpb24pDQoNCg0KQW4gYXBwcm9wcmlhdGUgZXJyb3IgcmVzcG9uc2UgaXMgc2VudCBiYWNr
IHRvIHRoZSBvcmlnaW5hdG9yDQoNCiAgIG9mIHRoZSByZXF1ZXN0Lg0KV2hvIHNlbmRzICJhbiBh
cHByb3ByaWF0ZSIgZXJyb3IgcmVzcG9uc2UiIGluIHRoaXMgY2FzZT8NCg0KNC4gc2VjdGlvbiAz
LjEuMiAoZWRpdG9yaWFsKSBjaGFuZ2VkICJ0byItPiJ0aGUiDQoNCg0KV2hlbiB0aGUgY2xpZW50
IGhhcyBhbiBhY3RpdmUgYW5kIGEgc3RhbmRieSBjb25uZWN0aW9uIHRvIHRoZSB0d28NCg0KICAg
YWdlbnRzIHRoZW4gYW4gYWx0ZXJuYXRpdmUgc3RyYXRlZ3kgZm9yIHJlc3BvbmRpbmcgdG8gYW4g
b3ZlcmxvYWQNCg0KICAgcmVwb3J0IGZyb20gYW4gYWdlbnQgaXMgdG8gY2hhbmdlIHRoZSBzdGFu
ZGJ5IGNvbm5lY3Rpb24gdG8gYWN0aXZlIGFuZA0KDQogICByb3V0ZSBhbGwgdHJhZmZpYyB0aHJv
dWdoIHRoZSBuZXcgYWN0aXZlIGNvbm5lY3Rpb24uDQoNCjUuIHNlY3Rpb24gMy4xLjMgKGVkaXRv
cmlhbCkNCg0KDQpBbiBleGFtcGxlIG9mIHRoaXMgdHlwZSBvZiBkZXBsb3ltZW50IGluY2x1ZGVz
IHdoZW4gdGhlcmUgYXJlIERpYW1ldGVyDQoNCiAgIGFnZW50cyBiZXR3ZWVuIGFkbWluaXN0cmF0
aXZlIGRvbWFpbnMuDQo2LiBzZWN0aW9uIDMuMS4zDQoNClRoZXJlIGlzIG5vIHNlY3Rpb24gMi4y
LiBJIGd1ZXNzIHNlY3Rpb24gMy4xLjIgd2FzIG1lYW50IGhlcmUsIHJpZ2h0Pw0KDQoNCkhhbmRs
aW5nIG9mIG92ZXJsb2FkIG9mIG9uZSBvciBib3RoIG9mIGFnZW50cyBhMTEgb3IgYTEyIGluIHRo
aXMgY2FzZQ0KDQogICBpcyBlcXVpdmFsZW50IHRvIHRoYXQgZGlzY3Vzc2VkIGluIHNlY3Rpb24g
Mi4yLg0KDQo3LiBzZWN0aW9uIDMuMi4xDQoNCkl0IGlzIG5vdCBjbGVhciB3aGljaCB1c2FnZSBz
Y2VuYXJpbyBpcyBtZWFudCBoZXJlLg0KDQoNCiAgIEl0IGlzIGVudmlzaW9uZWQgdGhhdCBhYmF0
ZW1lbnQgYWxnb3JpdGhtcyB3aWxsIGJlIGRlZmluZWQgdGhhdCB3aWxsDQoNCiAgIHN1cHBvcnQg
dGhlIG9wdGlvbiBmb3IgRGlhbWV0ZXIgRW5kcG9pbnRzIHRvIHNlbmQgcGVlciByZXBvcnRzLiAg
Rm9yDQoNCiAgIGluc3RhbmNlLCBpdCBpcyBlbnZpc2lvbmVkIHRoYXQgb25lIHVzYWdlIHNjZW5h
cmlvIGZvciB0aGUgcmF0ZQ0KDQogICBhbGdvcml0aG0sIFtJLUQuaWV0Zi1kaW1lLWRvaWMtcmF0
ZS1jb250cm9sXSwgd2hpY2ggaXMgYmVpbmcgd29ya2VkDQoNCiAgIG9uIGJ5IHRoZSBESU1FIHdv
cmtpbmcgZ3JvdXAgYXMgdGhpcyBkb2N1bWVudCBpcyBiZWluZyB3cml0dGVuLCB3aWxsDQoNCiAg
IGludm9sdmUgYWJhdGVtZW50IGJlaW5nIGRvbmUgb24gYSBob3AtYnktaG9wIGJhc2lzLg0KDQo4
LiBzZWN0aW9uIDQNCg0KV2h5IGlzIHRocm90dGxpbmcgdG8gYmUgYXBwbGllZCBhbmQgbm90IGRp
dmVyc2lvbiAobGlrZSBpbiBjYXNlIG9mIHJlZHVuZGFudCBhZ2VudHMpPw0KDQoNCkluIHRoaXMg
c2NlbmFyaW8gdGhlIHJlYWN0aW5nIG5vZGUgc2hvdWxkIGZpcnN0IGhhbmRsZSB0aGUgdGhyb3R0
bGluZyBvZiB0aGUNCg0KICAgb3ZlcmxvYWRlZCBob3N0IG9yIHJlYWxtLg0KIkxPU1MiIElzIGl0
IGEgbmV3IHR5cGUgZGVmaW5lZCBpbiB0aGUgc2NvcGUgb2YgdGhpcyBkcmFmdD8NCg0KDQpOb3Rl
OiBUaGUgZ29hbCBpcyB0byBhdm9pZCB0cmFmZmljIG9zY2lsbGF0aW9ucyB0aGF0IG1pZ2h0IHJl
c3VsdA0KDQogICAgICBmcm9tIHRocm90dGxpbmcgb2YgbWVzc2FnZXMgZm9yIGJvdGggdGhlIEhP
U1QvUkVBTE0gb3ZlcmxvYWQNCg0KICAgICAgcmVwb3J0cyBhbmQgdGhlIFBFRVIgb3ZlcmxvYWQg
cmVwb3J0cy4gIFRoaXMgaXMgZXNwZWNpYWxseSBhDQoNCiAgICAgIGNvbmNlcm4gaWYgYm90aCBy
ZXBvcnRzIGFyZSBvZiB0eXBlIExPU1MuDQoNCjkuIHNlY3Rpb24gNS4xLjENCg0KUHJvYmFibHkg
aXQgaXMgYmV0dGVyIHRvIGRlc2NyaWJlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgaW4gc2VjdGlv
biA1LjE/DQpPdGhlcndpc2UsIGl0IGlzIHVzZWQgYXMgYSB3ZWxsLWtub3duIG9uZSB3aGlsZSBp
dCBpcyB0aGUgZmlyc3QgcGxhY2Ugd2hlcmUgaXQgaXMgbWVudGlvbmVkLg0KDQpBbHNvIEkgdGhp
bmsgaXQgaXMgYmV0dGVyIHRvIGFkZCBtb3JlIHNwZWNpZmljIGluIHRoaXMgZHJhZnQgcmVsYXRl
ZCB0byBwZWVyIHJlcG9ydCBoYW5kbGluZzoNCi0gZGVmaW5lIFBlZXIgUmVwb3J0IFJlYWN0aW5n
IE5vZGUgYW5kIFBlZXIgUmVwb3J0IFJlcG9ydGluZyBOb2RlIHRlcm1zIGV4cGxpY2l0bHkgYW5k
IHVzZSB0aGVtIHRocm91Z2ggdGhlIGRyYWZ0IGFuZCBlc3BlY2lhbGx5IHN0YXJ0aW5nIGZyb20g
c2VjdGlvbiA1LjENCi0gYWRkICJQZWVyIFJlcG9ydCIgcHJlZml4IHRvIGFsbCB0aGUgZGVzY3Jp
YmVkIHByb2NlZHVyZXMNCkV4YW1wbGU6IENhcGFiaWxpdHkgQW5ub3VuY2VtZW50IC0+IFBlZXIg
UmVwb3J0IENhcGFiaWxpdHkgQW5ub3VuY2VtZW50DQoNCjEwLiBzZWN0aW9uIDUuMS4xL2dlbmVy
YWwNCg0KIkRpYW1ldGVySWRlbnRpdHkiIGFuZCAiRGlhbWV0ZXIgaWRlbnRpdHkiDQpNeSBwcm9w
b3NhbCBpcyB0byB1c2Ugb25lIHRlcm0gdGhyb3VnaCB0aGUgc3BlYy4NCg0KVW5kZXIgIkRPSUMg
bm9kZSIsIGFuIGFnZW50IGlzIG1lYW50IGhlcmU/DQoNCg0KIFdoZW4gYW4gYWdlbnQgcmVsYXlz
IGEgcmVxdWVzdCB0aGF0IGluY2x1ZGVzIGEgU291cmNlSUQgQVZQIGluIHRoZQ0KDQogICBPQy1T
dXBwb3J0ZWQtRmVhdHVyZXMgQVZQLCBhIERPSUMgbm9kZSB0aGF0IHN1cHBvcnRzIHRoZQ0KDQog
ICBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlIE1VU1QgcmVtb3ZlIHRoZSByZWNlaXZlZCBTb3VyY2VJ
RCBBVlAgYW5kDQoNCiAgIHJlcGxhY2UgaXQgd2l0aCBhIFNvdXJjZUlEIEFWUCBjb250YWluaW5n
IGl0cyBvd24gRGlhbWV0ZXIgaWRlbnRpdHkuDQoNCk15IHByb3Bvc2FsIGlzIHRvIHVzZSBwZWVy
IHJlcG9ydCByZWFjdGluZyBub2RlIGhlcmUgcmUtcGhyYXNpbmcgdGhpcyBzdGF0ZW1lbnQgYmVs
b3cgaW4gdGhlIGZvbGxvd2luZyB3YXk6DQoNCg0KIFdoZW4gcmVsYXlpbmcgYSByZXF1ZXN0IHRo
YXQgaW5jbHVkZXMgYSBTb3VyY2VJRCBBVlAgaW4gdGhlDQoNCiAgIE9DLVN1cHBvcnRlZC1GZWF0
dXJlcyBBVlAsIGEgcGVlciByZXBvcnQgcmVhY3Rpbmcgbm9kZSBNVVNUIHJlbW92ZSB0aGUgcmVj
ZWl2ZWQgU291cmNlSUQgQVZQIGFuZA0KDQogICByZXBsYWNlIGl0IHdpdGggYSBTb3VyY2VJRCBB
VlAgY29udGFpbmluZyBpdHMgb3duIERpYW1ldGVySWRlbnRpdHkuDQoxMS4gc2VjdGlvbiA1LjEu
Mg0KDQphZGRlZCB0aGUgbWlzc2VkICJ0byINCmNoYW5nZWQgIlBFRVJfUkVQT1JUIi0+ICJQRUVS
Ig0KDQoNCk5vdGU6IFRoZSB0cmFuc2FjdGlvbiBzdGF0ZSBpcyB1c2VkIHdoZW4gdGhlIERPSUMg
bm9kZSBpcyBhY3RpbmcNCg0KICAgICAgYXMgYSBwZWVyLXJlcG9ydCByZXBvcnRpbmcgbm9kZSBh
bmQgbmVlZHMgdG8gc2VuZCBPQy1PTFIgcmVwb3J0cyBvZg0KDQogICAgICB0eXBlIFBFRVIgaW4g
YW5zd2VyIG1lc3NhZ2VzLiAgVGhlIHBlZXIgb3ZlcmxvYWQgcmVwb3J0cw0KDQogICAgICBhcmUg
b25seSBpbmNsdWRlZCBpbiBhbnN3ZXIgbWVzc2FnZXMgYmVpbmcgc2VudCB0byBwZWVycyB0aGF0
DQoNCiAgICAgIHN1cHBvcnQgdGhlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUuDQoNCiJEaWFtZXRl
ciBJRCIgdGVybSBpcyBub3QgY2xhcmlmaWVkIGFueXdoZXJlLg0KUmUtcGhyYXNlZCB0aGUgYXBw
cm9wcmlhdGUgc3RhdGVtZW50IGEgbGl0dGxlIGJpdCwgY2hhbmdlZCAiRGlhbWV0ZXIgSUQiLT4i
dmFsdWUiDQpBbHNvIHRoZXJlIGFyZSBvdGhlciBwbGFjZXMgaW4gdGhlIGRyYWZ0IHdoZXJlICJE
aWFtZXRlciBJRCIgdGVybSBpcyB1c2VkLg0KDQoNClRoZSBwZWVyIHN1cHBvcnRzIHRoZSBPQ19Q
RUVSX1JFUE9SVCBmZWF0dXJlIGlmIHRoZSByZWNlaXZlZCByZXF1ZXN0DQoNCiAgIGNvbnRhaW5z
IGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAgd2l0aCB0aGUgT0MtRmVhdHVyZS1WZWN0b3Ig
d2l0aA0KDQogICB0aGUgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZSBiaXQgc2V0IGFuZCB3aXRoIGEg
U291cmNlSUQgQVZQIHdpdGggYQ0KDQogICB2YWx1ZSB0aGF0IG1hdGNoZXMgdGhlIERpYW1ldGVy
SWRlbnRpdHkgb2YgdGhlIHBlZXIgZnJvbSB3aGljaA0KDQogICB0aGUgcmVxdWVzdCB3YXMgcmVj
ZWl2ZWQuDQoNCkFnZW50IGlzIG1lYW50IHVuZGVyICJyZXBvcnRpbmcgbm9kZSIgaGVyZT8NCg0K
U2hvdWxkIG5vdCBTb3VyY2VJRCBBVlAgbm90IGp1c3Qgc3RyaXBwZWQgZnJvbSB0aGUgcmVsYXll
ZCBhbnN3ZXIsIGJ1dCByZXBsYWNlZCB3aXRoIHRoZSBTb3VyY2VJRCBBVlAgY29udGFpbmluZyB0
aGUgRGlhbWV0ZXJJZGVudGl0eSBvZiB0aGUgYWdlbnQgc3VwcG9ydGluZyBPQ19QRUVSX1JFUE9S
VCBmZWF0dXJlPw0KDQoNCldoZW4gYW4gYWdlbnQgcmVsYXlzIGFuIGFuc3dlciBtZXNzYWdlLCBh
IHJlcG9ydGluZyBub2RlIHRoYXQNCg0KICAgc3VwcG9ydHMgdGhlIE9DX1BFRVJfUkVQT1JUIGZl
YXR1cmUgTVVTVCBzdHJpcCBhbnkgU291cmNlSUQgQVZQIGZyb20NCg0KICAgdGhlIE9DLVN1cHBv
cnRlZC1GZWF0dXJlcyBBVlAuDQoNCkhhcmQgdG8gZm9sbG93IHdoYXQgd2FzIHdhbnRlZCB0byBz
YXkgaGVyZToNCkNvcnJlY3RlZCB0aGUgc3RhdGVtZW50LCBidXQgdGhpcyBpcyBqdXN0IG15IGJl
c3QgZ3Vlc3MuDQoNCg0KVGhlIE9DLVBlZXItQWxnbyBBVlAgTVVTVCBpbmRpY2F0ZSB0aGUgb3Zl
cmxvYWQgYWJhdGVtZW50DQoNCiAgIGFsZ29yaXRobSB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB3
YW50cyB0aGUgcmVhY3Rpbmcgbm9kZXMgdG8gdXNlDQoNCiAgIHdoZW4gdGhlIHJlcG9ydGluZyBu
b2RlIHNlbmRzIGEgcGVlciBvdmVybG9hZCByZXBvcnQgYXMgYSByZXN1bHQgb2YNCg0KICAgYmVj
b21pbmcgb3ZlcmxvYWRlZC4NCg0KU2hvdWxkIG5vdCB3ZSBhZGQgYSBzZXBhcmF0ZSBpZi0gc3Rh
dGVtZW50IGZvciB0aGUgY2FzZSB3aGVuIHRoZSBwZWVyIGRvZXMgbm90IHN1cHBvcnQgT0NfUEVF
Ul9SRVBPUlQgZmVhdHVyZSB3aGVuIHNlbmRpbmcgYW4gYW5zd2VyIG1lc3NhZ2U/DQoNCjEyLiBz
ZWN0aW9uIDUuMS4xIGFuZCA1LjEuMg0KDQpQcm9iYWJseSBpdCBpcyBtb3JlIGhlbHBmdWwgdG8g
aWxsdXN0cmF0ZSBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlIENBIHVzaW5nIHNlcXVlbmNlIGRpYWdy
YW1zIGxpa2UgaW4gdGhlIGxvYWQgaW5mbyBjb252ZXlhbmNlIGRyYWZ0Lg0KDQoxMy4gZ2VuZXJh
bC4NCg0KV2hhdCBhYm91dCB0byB1c2UgdGhlIHdyaXRpbmcgZm9yIHRoZSBzYW1lIHRlcm1zIHRo
cm91Z2ggdGhlIHNwZWM/DQpFeGFtcGxlMTogIkRPSUMgbm9kZSIgYW5kICJET0lDIE5vZGUiDQpF
eGFtcGxlMjogInBlZXItcmVwb3J0IHJlcG9ydGluZyBub2RlIiBhbmQgInBlZXIgcmVwb3J0IHJl
cG9ydGluZyBub2RlIg0KDQoxNC4gc2VjdGlvbiA1LjIuMS4yLCA1LjIuMiwgNS4yLjMgYW5kIGdl
bmVyYWwNCg0KInBlZXItdHlwZSBPQ1MiIGFuZCAicGVlciByZXBvcnQgT0NTIiBkZWZpbmUgdGhl
IHNhbWUgdGVybT8NCldoeSBub3QgdG8gdXNlIG9ubHkgb25lPw0KDQpBbm90aGVyIGV4YW1wbGU6
ICJwZWVyIHJlcG9ydCIgYW5kICJwZWVyIHJlcG9ydC10eXBlIiBhbmQgInJlcG9ydCBvZiB0eXBl
IFBFRVIiDQoNCjE1LiBzZWN0aW9uIDUuMi4zDQoNClByb2JhYmx5IGl0IGlzIGJldHRlciB0byBy
ZS1waHJhc2UgdGhpcyBzdGF0ZW1lbnQgYSBsaXR0bGUgYml0ICsgY29ycmVjdGVkIHRoZSBtaXNw
cmludHMuDQoNCg0KSWYgYSBwZWVyIHJlcG9ydCByZWFjdGluZyBub2RlIHJlY2VpdmVzIGFuIE9D
LU9MUiBBVlAgb2YgdHlwZSBwZWVyIGFuZCB0aGUNCg0KU291cmNlSUQgbWF0Y2hlcyB0aGUgRGlh
bWV0ZXJJZGVudGl0eSBvZiB0aGUgcGVlciBmcm9tIHdoaWNoIHRoZSByZXBvcnQNCg0Kd2FzIHJl
Y2VpdmVkIHRoZW4gdGhlIHJlcG9ydCB3YXMgZ2VuZXJhdGVkIGJ5IHRoZSBwZWVyLg0KDQpTaW1p
bGFyIGNvbW1lbnQgKyBjb3JyZWN0ZWQgbWlzcHJpbnRzIGZvciB0aGUgbmV4dCBzdGF0ZW1lbnQ6
DQoNCg0KSWYgYSBwZWVyIHJlcG9ydCByZWFjdGluZyBub2RlIHJlY2VpdmVzIGFuIE9DLU9MUiBB
VlAgb2YgdHlwZSBwZWVyIGFuZCB0aGUNCg0KU291cmNlSUQgZG9lcyBub3QgbWF0Y2ggdGhlIERp
YW1ldGVySWRlbnRpdHkgb2YgdGhlIHBlZXIgZnJvbSB3aGljaCB0aGUNCg0KcmVwb3J0IHdhcyBy
ZWNlaXZlZCB0aGVuIHRoZSByZWFjdGluZyBub2RlIE1VU1QgaWdub3JlIHRoZSBvdmVybG9hZA0K
DQpyZXBvcnQuDQoNCkFsc28gSSB0aGluayBpdCBpcyB1c2VmdWwgdG8gdXNlIG9uZSB3b3JkaW5n
IGZvciB0aGUgc2FtZSB0ZXJtOg0KIlBlZXIgUmVwb3J0IE9MUiIsICJPQy1PTFIgQVZQIiwgIk9M
UiINCkxldCdzIHVzZSBhIGdlbmVyaWMgb25lICJwZWVyIHJlcG9ydCI/DQoNCkp1c3QgbWlub3Ig
Y29tbWVudDogInRoZSBleGlzdGluZy4uLiIgYW5kICJhIG5ldyBvdmVybG9hZCBjb25kaXRpb24i
IGZvciBhbGwgb2NjdXJyZW5jZXMgaWYgbXkgRW5nbGlzaCBpcyBjb3JyZWN0Lg0KDQoxNi4gc2Vj
dGlvbiA1LjIuMw0KDQpIb3cgbWF5IGl0IGhhcHBlbiB0aGF0IHBlZXIgcmVwb3J0IHJlYWN0aW5n
IG5vZGUgcmVjZWl2ZXMgYSBwZWVyIHJlcG9ydCBub3QgZnJvbSB0aGUgcGVlciB0aGF0IGdlbmVy
YXRlZCBpdD8NClBlZXIgcmVwb3J0cyBjYW4gYmUgc2VudCBvbmx5IHRvIHBlZXIgcmVwb3J0IHJl
YWN0aW5nIG5vZGUsIHJpZ2h0PyBBbmQgcGVlciByZXBvcnRzIGFyZSBub3QgcmVsYXllZCwgcmln
aHQ/DQoNCkJlc3QgcmVnYXJkcywNCg0KL01pc2hhDQoNCg0KMjAxNy0wMS0wOSAxNzozNSBHTVQr
MDM6MDAgVGhlIElFU0cgPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPG1haWx0bzppZXNnLXNlY3Jl
dGFyeUBpZXRmLm9yZz4+Og0KDQpUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20g
dGhlIERpYW1ldGVyIE1haW50ZW5hbmNlIGFuZA0KRXh0ZW5zaW9ucyBXRyAoZGltZSkgdG8gY29u
c2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCi0gJ0RpYW1ldGVyIEFnZW50IE92ZXJsb2Fk
IGFuZCB0aGUgUGVlciBPdmVybG9hZCBSZXBvcnQnDQogIDxkcmFmdC1pZXRmLWRpbWUtYWdlbnQt
b3ZlcmxvYWQtMDgudHh0PiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KDQpUaGUgSUVTRyBwbGFucyB0
byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMNCmZp
bmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21t
ZW50cyB0byB0aGUNCmlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+IG1haWxpbmcg
bGlzdHMgYnkgMjAxNy0wMS0yMy4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5IGJlDQpzZW50
IHRvIGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+IGluc3RlYWQuIEluIGVpdGhl
ciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUg
dG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQoNCkFic3RyYWN0DQoNCg0KICAgVGhpcyBzcGVj
aWZpY2F0aW9uIGRvY3VtZW50cyBhbiBleHRlbnNpb24gdG8gUkZDIDc2ODMgKERpYW1ldGVyDQog
ICBPdmVybG9hZCBJbmRpY2F0aW9uIENvbnZleWFuY2UgKERPSUMpKSBiYXNlIHNvbHV0aW9uLiAg
VGhlIGV4dGVuc2lvbg0KICAgZGVmaW5lcyB0aGUgUGVlciBvdmVybG9hZCByZXBvcnQgdHlwZS4g
IFRoZSBpbml0aWFsIHVzZSBjYXNlIGZvciB0aGUNCiAgIFBlZXIgcmVwb3J0IGlzIHRoZSBoYW5k
bGluZyBvZiBvY2N1cnJlbmNlcyBvZiBvdmVybG9hZCBvZiBhIERpYW1ldGVyDQogICBhZ2VudC4N
Cg0KUmVxdWlyZW1lbnRzDQoNCg0KDQpUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQpodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRpbWUtYWdlbnQtb3Zlcmxv
YWQvDQoNCklFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWENCmh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZC9iYWxsb3Qv
DQoNCg0KTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9u
IHRoaXMgSS1ELg0KDQoNClRoZSBkb2N1bWVudCBjb250YWlucyB0aGVzZSBub3JtYXRpdmUgZG93
bndhcmQgcmVmZXJlbmNlcy4NClNlZSBSRkMgMzk2NyBmb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlv
bjoNCiAgICBkcmFmdC1yb2FjaC1kaW1lLW92ZXJsb2FkLWN0cmw6IEEgTWVjaGFuaXNtIGZvciBE
aWFtZXRlciBPdmVybG9hZCBDb250cm9sIChOb25lIC0gKQ0KTm90ZSB0aGF0IHNvbWUgb2YgdGhl
c2UgcmVmZXJlbmNlcyBtYXkgYWxyZWFkeSBiZSBsaXN0ZWQgaW4gdGhlIGFjY2VwdGFibGUgRG93
bnJlZiBSZWdpc3RyeS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVA
aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0K
DQoNClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIHRyYW5zbWlzc2lvbiBjb250YWlucyBpbmZvcm1h
dGlvbiBmcm9tIENTUkEgdGhhdCBtYXkgYmUgYXR0b3JuZXktY2xpZW50IHByaXZpbGVnZWQsIHBy
b3ByaWV0YXJ5IG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgbWVzc2Fn
ZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB1c2UgYnkgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSBp
dCBpcyBhZGRyZXNzZWQuIElmIHlvdSBiZWxpZXZlIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVz
c2FnZSBpbiBlcnJvciwgcGxlYXNlIGNvbnRhY3QgbWUgaW1tZWRpYXRlbHkgYW5kIGJlIGF3YXJl
IHRoYXQgYW55IHVzZSwgZGlzY2xvc3VyZSwgY29weWluZyBvciBkaXN0cmlidXRpb24gb2YgdGhl
IGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBOT1RFOiBS
ZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmlu
ZCBDU1JBIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8g
ZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJl
c3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZW1haWwgZm9yIHN1Y2ggcHVycG9zZS4NCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy
IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk
LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6
MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm
b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N
CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl
Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhU
TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD
aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl
Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkp1c3QgdGhlIHZhZ2FyaWVzIG9mIEVuZ2xp
c2ggZ3JhbW1hci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkg
dGhvdWdodCB0aGUgcmVzdCBvZiB5b3VyIGNvbW1lbnRzIHdlcmUgZ29vZCBjYXRjaGVzLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SmFuZXQ8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2Ui
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWlzaGEgWmF5dHNldiBbbWFpbHRvOm1pc2hhLnph
eXRzZXYucnVzQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5
IDE3LCAyMDE3IDQ6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IEd1bm4sIEphbmV0IFAgJmx0O0phbmV0
Lkd1bm5AY3NyYS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBpZXRmQGlldGYub3JnOyBkaW1lLWNo
YWlyc0BpZXRmLm9yZzsgZGltZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaW1lLWFnZW50LW92ZXJs
b2FkQGlldGYub3JnOyBJRVRGLUFubm91bmNlICZsdDtpZXRmLWFubm91bmNlQGlldGYub3JnJmd0
Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWll
dGYtZGltZS1hZ2VudC1vdmVybG9hZC0wOC50eHQmZ3Q7IChEaWFtZXRlciBBZ2VudCBPdmVybG9h
ZCBhbmQgdGhlIFBlZXIgT3ZlcmxvYWQgUmVwb3J0KSB0byBQcm9wb3NlZCBTdGFuZGFyZDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEphbmV0LDxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0ssIEkgd2lsbCBub3QgYXJndWUgOik8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0xIGNv
bW1lbnQgZm9yIFN0ZXZlIHRvIGFuc3dlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L01pc2hhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTctMDEtMTggMDoxNiBHTVQmIzQzOzAzOjAw
IEd1bm4sIEphbmV0IFAgJmx0OzxhIGhyZWY9Im1haWx0bzpKYW5ldC5HdW5uQGNzcmEuY29tIiB0
YXJnZXQ9Il9ibGFuayI+SmFuZXQuR3VubkBjc3JhLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UG9pbnQgbnVtYmVyIDItPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+JnF1b3Q7QXMgaWYgdGhlIGNsaWVudCB3
ZXJlIOKApiZxdW90OyBpcyBjb3JyZWN0IChzdWJqdW5jdGl2ZSBmb3IgYSAmcXVvdDtjb25kaXRp
b24gY29udHJhcnkgdG8gZmFjdCZxdW90Oyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj4mcXVvdDtBcyBpZiB0aGUgY2xpZW50ICZuYnNwO3dhcyZxdW90OyDi
gKYgaXMgZ3JhbW1hdGljYWxseSBJTkNPUlJFQ1QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+SmFuZXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fNjc4MjcwNDM5MzI5MDE4NzI1NF9fTWFpbEVuZENv
bXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBEaU1FIFttYWlsdG86PGEgaHJlZj0i
bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRpbWUtYm91bmNl
c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pc2hhIFpheXRzZXY8YnI+DQo8
Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAxNywgMjAxNyAzOjI0IFBNPGJyPg0KPGI+VG86
PC9iPiA8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlldGZA
aWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZGltZS1jaGFpcnNA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kaW1lLWNoYWlyc0BpZXRmLm9yZzwvYT47DQo8YSBo
cmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRpbWVAaWV0Zi5vcmc8
L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1kaW1lLWFnZW50LW92ZXJsb2FkQGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLWRpbWUtYWdlbnQtb3ZlcmxvYWRAaWV0
Zi5vcmc8L2E+OyBJRVRGLUFubm91bmNlICZsdDs8YSBocmVmPSJtYWlsdG86aWV0Zi1hbm5vdW5j
ZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0
Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWll
dGYtZGltZS1hZ2VudC1vdmVybG9hZC0wOC50eHQmZ3Q7IChEaWFtZXRlciBBZ2VudCBPdmVybG9h
ZCBhbmQgdGhlIFBlZXIgT3ZlcmxvYWQgUmVwb3J0KSB0byBQcm9wb3NlZCBTdGFuZGFyZDwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEFs
bCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IZXJl
IGFyZSBteSBjb21tZW50cy9xdWVzdGlvbnMgdG8gYW4gYWdlbnQgb3ZlcmxvYWQgZHJhZnQuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMg
dGhlIGZpcnN0IHBhcnQuIExhdGVyIG9uIEkgd2lsbCBjb21wbGV0ZSBteSByZXZpZXcgYW5kIHNl
bmQgb3V0IHRoZSBzZWNvbmQgcG9ydGlvbiBvZiB0aGUgY29tbWVudHMuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS4gc2Vj
dGlvbiAxIChlZGl0b3JpYWwpIHJlbW92ZWQgJnF1b3Q7aXMmcXVvdDsgYmVmb3JlICZxdW90O2Zl
YXNpYmxlJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQg
OC4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZE
RjU7d29yZC1icmVhazpicmVhay1hbGw7Ym94LXNpemluZzpib3JkZXItYm94O3dvcmQtd3JhcDpi
cmVhay13b3JkO2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5JbiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9uLCB0
aGUgZ29hbCBpcyB0byBoYW5kbGUgYWJhdGVtZW50IG9mIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7
d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y
OmJsYWNrIj4mbmJzcDsmbmJzcDsgb3ZlcmxvYWQgb2NjdXJyZW5jZSBhcyBjbG9zZSB0byB0aGUg
c291cmNlIG9mIHRoZSBEaWFtZXRlciB0cmFmZmljIGFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk
LWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh
Y2siPiZuYnNwOyZuYnNwOyBmZWFzaWJsZS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVv
dDtzY2VuYWlvcyZxdW90OyAtJmd0OyAmcXVvdDtzY2VuYXJpb3MmcXVvdDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdp
bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2Jv
eC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdyYXA6YnJlYWstd29yZDtib3JkZXItcmFkaXVzOjRw
eDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj
ayI+VGhlIFBlZXIgb3ZlcmxvYWQgcmVwb3J0IHR5cGUgaXM8L3NwYW4+PG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv
cmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7IGRlZmluZWQgaW4gYSBnZW5lcmljIGZhc2hpb24gc28gdGhhdCBp
dCBjYW4gYWxzbyBiZSB1c2VkIGZvciBvdGhlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVh
azpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4m
bmJzcDsmbmJzcDsgRGlhbWV0ZXIgb3ZlcmxvYWQgPGI+c2NlbmFyaW9zPC9iPi48L3NwYW4+PG86
cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Mi4gc2VjdGlvbiAzLjEuMSAoZWRpdG9yaWFsKSByZXBsYWNlZCAmcXVvdDt3ZXJl
JnF1b3Q7LSZndDsgJnF1b3Q7d2FzJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBw
dCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2Jh
Y2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3gtc2l6aW5nOmJvcmRlci1i
b3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZsb3c6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkluIGJvdGggb2YgdGhl
c2UgY2FzZXMsIHRoZSBvY2N1cnJlbmNlIG9mIG92ZXJsb2FkIGluIHRoZSBzaW5nbGU8L3NwYW4+
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy
b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFnZW50IG11c3QgYnkgaGFuZGxlZCBi
eSB0aGUgY2xpZW50IGluIGEgc2ltaWxhciBmYXNoaW9uIGFzIGlmIHRoZTwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG
RkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY2xpZW50IDxiPndhczwvYj4gaGFuZGxpbmcgdGhl
IG92ZXJsb2FkIG9mIGEgZGlyZWN0bHkgY29ubmVjdGVkIHNlcnZlci48L3NwYW4+PG86cD48L286
cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+My4gc2VjdGlvbiAzLjEuMSAocXVlc3Rpb24pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4
LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0
O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3gtc2l6aW5nOmJvcmRl
ci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZsb3c6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkFuIGFwcHJvcHJp
YXRlIGVycm9yIHJlc3BvbnNlIGlzIHNlbnQgYmFjayB0byB0aGUgb3JpZ2luYXRvcjwvc3Bhbj48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv
dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgb2YgdGhlIHJlcXVlc3QuPC9zcGFuPjxv
OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+V2hvIHNlbmRzICZxdW90O2FuIGFwcHJvcHJpYXRlJnF1b3Q7IGVycm9yIHJlc3BvbnNl
JnF1b3Q7IGluIHRoaXMgY2FzZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuIHNlY3Rpb24gMy4xLjIgKGVkaXRvcmlhbCkgY2hhbmdl
ZCAmcXVvdDt0byZxdW90Oy0mZ3Q7JnF1b3Q7dGhlJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3gtc2l6aW5n
OmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZs
b3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPldoZW4g
dGhlIGNsaWVudCBoYXMgYW4gYWN0aXZlIGFuZCBhIHN0YW5kYnkgY29ubmVjdGlvbiB0byB0aGUg
dHdvPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcu
OXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhZ2VudHMgdGhlbiBh
biBhbHRlcm5hdGl2ZSBzdHJhdGVneSBmb3IgcmVzcG9uZGluZyB0byBhbiBvdmVybG9hZDwvc3Bh
bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr
Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVwb3J0IGZyb20gYW4gYWdlbnQg
aXMgdG8gY2hhbmdlIDxiPnRoZSA8L2I+c3RhbmRieSBjb25uZWN0aW9uIHRvIGFjdGl2ZSBhbmQ8
L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7
YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHJvdXRlIGFsbCB0cmFmZmlj
IHRocm91Z2ggdGhlIG5ldyBhY3RpdmUgY29ubmVjdGlvbi48L3NwYW4+PG86cD48L286cD48L3By
ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NS4g
c2VjdGlvbiAzLjEuMyAoZWRpdG9yaWFsKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQg
OC4wcHQgOC4wcHQgOC4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr
Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym94LXNpemluZzpib3JkZXItYm94
O3dvcmQtd3JhcDpicmVhay13b3JkO2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5BbiBleGFtcGxlIG9mIHRo
aXMgdHlwZSBvZiBkZXBsb3ltZW50IGluY2x1ZGU8Yj5zPC9iPiB3aGVuIHRoZXJlIGFyZSBEaWFt
ZXRlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3
LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWdlbnRzIGJldHdl
ZW4gYWRtaW5pc3RyYXRpdmUgZG9tYWlucy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj42LiBzZWN0aW9uIDMuMS4z
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5UaGVyZSBpcyBubyBzZWN0aW9uIDIuMi4gSSBndWVzcyBzZWN0aW9uIDMuMS4yIHdhcyBtZWFu
dCBoZXJlLCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0
IDguMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZG
REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdyYXA6
YnJlYWstd29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SGFuZGxpbmcgb2Ygb3ZlcmxvYWQgb2Ygb25l
IG9yIGJvdGggb2YgYWdlbnRzIGExMSBvciBhMTIgaW4gdGhpcyBjYXNlPC9zcGFuPjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG
RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpcyBlcXVpdmFsZW50IHRvIHRoYXQgZGlzY3Vzc2Vk
IGluIHNlY3Rpb24gMi4yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj43LiBzZWN0aW9uIDMuMi4xPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBp
cyBub3QgY2xlYXIgd2hpY2ggdXNhZ2Ugc2NlbmFyaW8gaXMgbWVhbnQgaGVyZS48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0Ij4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs
O2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdyYXA6YnJlYWstd29yZDtib3JkZXItcmFkaXVz
OjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7IEl0IGlzIGVudmlzaW9uZWQgdGhhdCBhYmF0ZW1lbnQgYWxnb3Jp
dGhtcyB3aWxsIGJlIGRlZmluZWQgdGhhdCB3aWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy
ZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si
PiZuYnNwOyZuYnNwOyBzdXBwb3J0IHRoZSBvcHRpb24gZm9yIERpYW1ldGVyIEVuZHBvaW50cyB0
byBzZW5kIHBlZXIgcmVwb3J0cy4mbmJzcDsgRm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy
ZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si
PiZuYnNwOyZuYnNwOyBpbnN0YW5jZSwgaXQgaXMgZW52aXNpb25lZCB0aGF0IG9uZSB1c2FnZSBz
Y2VuYXJpbyBmb3IgdGhlIHJhdGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst
YWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i
c3A7IGFsZ29yaXRobSwgW0ktRC5pZXRmLWRpbWUtZG9pYy1yYXRlLWNvbnRyb2xdLCB3aGljaCBp
cyBiZWluZyB3b3JrZWQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp
bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG9u
IGJ5IHRoZSBESU1FIHdvcmtpbmcgZ3JvdXAgYXMgdGhpcyBkb2N1bWVudCBpcyBiZWluZyB3cml0
dGVuLCB3aWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpbnZvbHZl
IGFiYXRlbWVudCBiZWluZyBkb25lIG9uIGEgaG9wLWJ5LWhvcCBiYXNpcy48L3NwYW4+PG86cD48
L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+OC4gc2VjdGlvbiA0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5XaHkgaXMgdGhyb3R0bGluZyB0byBiZSBhcHBsaWVkIGFuZCBu
b3QgZGl2ZXJzaW9uIChsaWtlIGluIGNhc2Ugb2YgcmVkdW5kYW50IGFnZW50cyk/Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy
ZWFrLWFsbDtib3gtc2l6aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVy
LXJhZGl1czo0cHg7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Y29sb3I6YmxhY2siPkluIHRoaXMgc2NlbmFyaW8gdGhlIHJlYWN0aW5nIG5vZGUgc2hvdWxkIGZp
cnN0IGhhbmRsZSB0aGUgdGhyb3R0bGluZyBvZiB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQt
YnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj
ayI+Jm5ic3A7Jm5ic3A7IG92ZXJsb2FkZWQgaG9zdCBvciByZWFsbS48L3NwYW4+PG86cD48L286
cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
cXVvdDtMT1NTJnF1b3Q7IElzIGl0IGEgbmV3IHR5cGUgZGVmaW5lZCBpbiB0aGUgc2NvcGUgb2Yg
dGhpcyBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDgu
MHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1
O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdyYXA6YnJl
YWstd29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Tm90ZTogVGhlIGdvYWwgaXMgdG8gYXZvaWQgdHJh
ZmZpYyBvc2NpbGxhdGlvbnMgdGhhdCBtaWdodCByZXN1bHQ8L3NwYW4+PG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv
cmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZyb20gdGhyb3R0bGluZyBvZiBt
ZXNzYWdlcyBmb3IgYm90aCB0aGUgSE9TVC9SRUFMTSBvdmVybG9hZDwvc3Bhbj48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZE
RjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv
bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVwb3J0cyBhbmQgdGhl
IFBFRVIgb3ZlcmxvYWQgcmVwb3J0cy4mbmJzcDsgVGhpcyBpcyBlc3BlY2lhbGx5IGE8L3NwYW4+
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy
b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmNl
cm4gaWYgPGI+Ym90aCByZXBvcnRzIGFyZSBvZiB0eXBlIExPU1M8L2I+Ljwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj45LiBzZWN0aW9uIDUuMS4xPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5Qcm9iYWJseSBpdCBpcyBiZXR0ZXIgdG8gZGVzY3JpYmUg
T0NfUEVFUl9SRVBPUlQgZmVhdHVyZSBpbiBzZWN0aW9uIDUuMT88bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T3RoZXJ3aXNlLCBpdCBpcyB1c2Vk
IGFzIGEgd2VsbC1rbm93biBvbmUgd2hpbGUgaXQgaXMgdGhlIGZpcnN0IHBsYWNlIHdoZXJlIGl0
IGlzIG1lbnRpb25lZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPkFsc28gSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gYWRkIG1vcmUgc3Bl
Y2lmaWMgaW4gdGhpcyBkcmFmdCByZWxhdGVkIHRvIHBlZXIgcmVwb3J0IGhhbmRsaW5nOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIGRlZmlu
ZSBQZWVyIFJlcG9ydCBSZWFjdGluZyBOb2RlIGFuZCBQZWVyIFJlcG9ydCBSZXBvcnRpbmcgTm9k
ZSB0ZXJtcyBleHBsaWNpdGx5IGFuZCB1c2UgdGhlbSB0aHJvdWdoIHRoZSBkcmFmdCBhbmQgZXNw
ZWNpYWxseSBzdGFydGluZyBmcm9tIHNlY3Rpb24gNS4xJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gYWRkICZxdW90O1BlZXIgUmVw
b3J0JnF1b3Q7IHByZWZpeCB0byBhbGwgdGhlIGRlc2NyaWJlZCBwcm9jZWR1cmVzPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkV4YW1wbGU6IENh
cGFiaWxpdHkgQW5ub3VuY2VtZW50IC0mZ3Q7IFBlZXIgUmVwb3J0IENhcGFiaWxpdHkgQW5ub3Vu
Y2VtZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4xMC4gc2VjdGlvbiA1LjEuMS9nZW5lcmFsPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDtEaWFtZXRlcklkZW50aXR5
JnF1b3Q7IGFuZCAmcXVvdDtEaWFtZXRlciBpZGVudGl0eSZxdW90OzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NeSBwcm9wb3NhbCBpcyB0byB1
c2Ugb25lIHRlcm0gdGhyb3VnaCB0aGUgc3BlYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlVuZGVyICZxdW90O0RPSUMgbm9kZSZxdW90
OywgYW4gYWdlbnQgaXMgbWVhbnQgaGVyZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0
IDguMHB0IDguMHB0IDguMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFj
a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JveC1zaXppbmc6Ym9yZGVyLWJv
eDt3b3JkLXdyYXA6YnJlYWstd29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+IFdoZW4gYW4gYWdlbnQg
cmVsYXlzIGEgcmVxdWVzdCB0aGF0IGluY2x1ZGVzIGEgU291cmNlSUQgQVZQIGluIHRoZTwvc3Bh
bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr
Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgT0MtU3VwcG9ydGVkLUZlYXR1cmVz
IEFWUCwgYSBET0lDIG5vZGUgdGhhdCBzdXBwb3J0cyB0aGU8L3NwYW4+PG86cD48L286cD48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv
cmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7IE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgTVVTVCByZW1vdmUgdGhl
IHJlY2VpdmVkIFNvdXJjZUlEIEFWUCBhbmQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6
YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7IHJlcGxhY2UgaXQgd2l0aCBhIFNvdXJjZUlEIEFWUCBjb250YWluaW5nIGl0cyBv
d24gRGlhbWV0ZXIgaWRlbnRpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk15IHByb3Bvc2FsIGlzIHRv
IHVzZSBwZWVyIHJlcG9ydCByZWFjdGluZyBub2RlIGhlcmUgcmUtcGhyYXNpbmcgdGhpcyBzdGF0
ZW1lbnQgYmVsb3cgaW4gdGhlIGZvbGxvd2luZyB3YXk6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu
Zzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcu
OXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3gtc2l6aW5nOmJv
cmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZsb3c6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiBXaGVuIHJl
bGF5aW5nIGEgcmVxdWVzdCB0aGF0IGluY2x1ZGVzIGEgU291cmNlSUQgQVZQIGluIHRoZTwvc3Bh
bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr
Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgT0MtU3VwcG9ydGVkLUZlYXR1cmVz
IEFWUCwgYSBwZWVyIHJlcG9ydCByZWFjdGluZyBub2RlIE1VU1QgcmVtb3ZlIHRoZSByZWNlaXZl
ZCBTb3VyY2VJRCBBVlAgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw
OyByZXBsYWNlIGl0IHdpdGggYSBTb3VyY2VJRCBBVlAgY29udGFpbmluZyBpdHMgb3duIERpYW1l
dGVySWRlbnRpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTEuIHNlY3Rpb24gNS4xLjI8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmFkZGVkIHRoZSBt
aXNzZWQgJnF1b3Q7dG8mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Y2hhbmdlZCAmcXVvdDtQRUVSX1JFUE9SVCZxdW90Oy0mZ3Q7ICZx
dW90O1BFRVImcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0
IDguMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZG
REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdyYXA6
YnJlYWstd29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Tm90ZTogVGhlIHRyYW5zYWN0aW9uIHN0YXRl
IGlzIHVzZWQgd2hlbiB0aGUgRE9JQyBub2RlIGlzIGFjdGluZzwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7
d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y
OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXMgYSBwZWVyLXJlcG9ydCBy
ZXBvcnRpbmcgbm9kZSBhbmQgbmVlZHMgPGI+dG8gPC9iPnNlbmQgT0MtT0xSIHJlcG9ydHMgb2Y8
L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7
YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHR5cGUgPGI+UEVFUiA8L2I+aW4gYW5zd2VyIG1lc3NhZ2VzLiZuYnNwOyBUaGUgcGVlciBvdmVy
bG9hZCByZXBvcnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBhcmUgb25seSBpbmNsdWRlZCBpbiBhbnN3ZXIgbWVzc2FnZXMgYmVpbmcg
c2VudCB0byBwZWVycyB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBzdXBwb3J0IHRoZSBPQ19QRUVSX1JFUE9SVCBmZWF0dXJlLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mcXVvdDtEaWFtZXRlciBJRCZxdW90OyB0ZXJtIGlzIG5vdCBjbGFy
aWZpZWQgYW55d2hlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPlJlLXBocmFzZWQgdGhlIGFwcHJvcHJpYXRlIHN0YXRlbWVudCBhIGxpdHRs
ZSBiaXQsIGNoYW5nZWQgJnF1b3Q7RGlhbWV0ZXIgSUQmcXVvdDstJmd0OyZxdW90O3ZhbHVlJnF1
b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PkFsc28gdGhlcmUgYXJlIG90aGVyIHBsYWNlcyBpbiB0aGUgZHJhZnQgd2hlcmUgJnF1b3Q7RGlh
bWV0ZXIgSUQmcXVvdDsgdGVybSBpcyB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4w
cHQgOC4wcHQgOC4wcHQgOC4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti
YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym94LXNpemluZzpib3JkZXIt
Ym94O3dvcmQtd3JhcDpicmVhay13b3JkO2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5UaGUgcGVlciBzdXBw
b3J0cyB0aGUgT0NfUEVFUl9SRVBPUlQgZmVhdHVyZSBpZiB0aGUgcmVjZWl2ZWQgcmVxdWVzdDwv
c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti
YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY29udGFpbnMgYW4gT0MtU3Vw
cG9ydGVkLUZlYXR1cmVzIEFWUCB3aXRoIHRoZSBPQy1GZWF0dXJlLVZlY3RvciB3aXRoPC9zcGFu
PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tn
cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUgT0NfUEVFUl9SRVBPUlQgZmVh
dHVyZSBiaXQgc2V0IGFuZCB3aXRoIGEgU291cmNlSUQgQVZQIHdpdGggYTwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG
RkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdmFsdWUgdGhhdCBtYXRjaGVzIHRoZSBEaWFtZXRl
cklkZW50aXR5IG9mIHRoZSBwZWVyIGZyb20gd2hpY2g8L3NwYW4+PG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQt
YnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj
ayI+Jm5ic3A7Jm5ic3A7IHRoZSByZXF1ZXN0IHdhcyByZWNlaXZlZC48L3NwYW4+PG86cD48L286
cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+QWdlbnQgaXMgbWVhbnQgdW5kZXIgJnF1b3Q7cmVwb3J0aW5nIG5vZGUmcXVvdDsgaGVyZT88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PlNob3VsZCBub3QgU291cmNlSUQgQVZQIG5vdCBqdXN0IHN0cmlwcGVkIGZyb20gdGhlIHJlbGF5
ZWQgYW5zd2VyLCBidXQgcmVwbGFjZWQgd2l0aCB0aGUgU291cmNlSUQgQVZQIGNvbnRhaW5pbmcg
dGhlIERpYW1ldGVySWRlbnRpdHkgb2YgdGhlIGFnZW50IHN1cHBvcnRpbmcgT0NfUEVFUl9SRVBP
UlQgZmVhdHVyZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDgu
MHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1
O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdyYXA6YnJl
YWstd29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+V2hlbiBhbiBhZ2VudCByZWxheXMgYW4gYW5zd2Vy
IG1lc3NhZ2UsIGEgcmVwb3J0aW5nIG5vZGUgdGhhdDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i
cmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr
Ij4mbmJzcDsmbmJzcDsgc3VwcG9ydHMgdGhlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgTVVTVCBz
dHJpcCBhbnkgU291cmNlSUQgQVZQIGZyb208L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6
YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7IHRoZSBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQLjwvc3Bhbj48bzpwPjwvbzpw
PjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5IYXJkIHRvIGZvbGxvdyB3aGF0IHdhcyB3YW50ZWQgdG8gc2F5IGhlcmU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvcnJlY3RlZCB0aGUg
c3RhdGVtZW50LCBidXQgdGhpcyBpcyBqdXN0IG15IGJlc3QgZ3Vlc3MuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4w
cHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3gt
c2l6aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0cHg7
b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si
PlRoZSBPQy1QZWVyLUFsZ28gQVZQIE1VU1QgaW5kaWNhdGUgdGhlIG92ZXJsb2FkIGFiYXRlbWVu
dDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3Ljlw
dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWxnb3JpdGhtIHRoYXQg
dGhlIHJlcG9ydGluZyBub2RlIHdhbnRzIHRoZSByZWFjdGluZyBub2RlcyB0byB1c2U8L3NwYW4+
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy
b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDxiPndoZW4gPC9iPnRoZSByZXBvcnRp
bmcgbm9kZSBzZW5kPGI+czwvYj4gYSBwZWVyIG92ZXJsb2FkIHJlcG9ydCBhcyBhIHJlc3VsdCBv
Zjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3Ljlw
dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYmVjb21pbmcgb3Zlcmxv
YWRlZC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2hvdWxkIG5vdCB3ZSBhZGQgYSBzZXBhcmF0ZSBpZi0g
c3RhdGVtZW50IGZvciB0aGUgY2FzZSB3aGVuIHRoZSBwZWVyIGRvZXMgbm90IHN1cHBvcnQgT0Nf
UEVFUl9SRVBPUlQgZmVhdHVyZSB3aGVuIHNlbmRpbmcgYW4gYW5zd2VyIG1lc3NhZ2U/PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMi4g
c2VjdGlvbiA1LjEuMSBhbmQgNS4xLjI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlByb2JhYmx5IGl0IGlzIG1vcmUgaGVscGZ1bCB0byBp
bGx1c3RyYXRlIE9DX1BFRVJfUkVQT1JUIGZlYXR1cmUgQ0EgdXNpbmcgc2VxdWVuY2UgZGlhZ3Jh
bXMgbGlrZSBpbiB0aGUgbG9hZCBpbmZvIGNvbnZleWFuY2UgZHJhZnQuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMy4gZ2VuZXJhbC48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PldoYXQgYWJvdXQgdG8gdXNlIHRoZSB3cml0aW5nIGZvciB0aGUgc2FtZSB0ZXJtcyB0aHJvdWdo
IHRoZSBzcGVjPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5FeGFtcGxlMTogJnF1b3Q7RE9JQyBub2RlJnF1b3Q7IGFuZCAmcXVvdDtET0lDIE5v
ZGUmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+RXhhbXBsZTI6ICZxdW90O3BlZXItcmVwb3J0IHJlcG9ydGluZyBub2RlJnF1b3Q7IGFu
ZCAmcXVvdDtwZWVyIHJlcG9ydCByZXBvcnRpbmcgbm9kZSZxdW90OzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTQuIHNlY3Rpb24gNS4y
LjEuMiwgNS4yLjIsIDUuMi4zIGFuZCBnZW5lcmFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDtwZWVyLXR5cGUgT0NTJnF1b3Q7
IGFuZCAmcXVvdDtwZWVyIHJlcG9ydCBPQ1MmcXVvdDsgZGVmaW5lIHRoZSBzYW1lIHRlcm0/PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoeSBu
b3QgdG8gdXNlIG9ubHkgb25lPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+QW5vdGhlciBleGFtcGxlOiAmcXVvdDtwZWVyIHJlcG9ydCZx
dW90OyBhbmQgJnF1b3Q7cGVlciByZXBvcnQtdHlwZSZxdW90OyBhbmQgJnF1b3Q7cmVwb3J0IG9m
IHR5cGUgUEVFUiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+MTUuIHNlY3Rpb24gNS4yLjM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlByb2JhYmx5IGl0IGlzIGJldHRl
ciB0byByZS1waHJhc2UgdGhpcyBzdGF0ZW1lbnQgYSBsaXR0bGUgYml0ICYjNDM7IGNvcnJlY3Rl
ZCB0aGUgbWlzcHJpbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4w
cHQgOC4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG
RkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym94LXNpemluZzpib3JkZXItYm94O3dvcmQtd3Jh
cDpicmVhay13b3JkO2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5JZiBhIDxiPnBlZXIgcmVwb3J0PC9iPiBy
ZWFjdGluZyBub2RlIHJlY2VpdmVzIGFuIE9DLU9MUiBBVlAgb2YgdHlwZSBwZWVyIGFuZCB0aGU8
L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7
YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+U291cmNlSUQgbWF0Y2hlcyB0aGUgPGI+RGlhbWV0
ZXJJZGVudGl0eSA8L2I+b2YgdGhlIHBlZXIgZnJvbSB3aGljaCB0aGUgPGI+cmVwb3J0PC9iPjwv
c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti
YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj53YXMgcmVjZWl2ZWQgdGhlbiB0aGUgcmVwb3J0IHdh
cyA8Yj5nZW5lcmF0ZWQgPC9iPmJ5IHRoZSBwZWVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TaW1pbGFy
IGNvbW1lbnQgJiM0MzsgY29ycmVjdGVkIG1pc3ByaW50cyBmb3IgdGhlIG5leHQgc3RhdGVtZW50
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQiPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVh
azpicmVhay1hbGw7Ym94LXNpemluZzpib3JkZXItYm94O3dvcmQtd3JhcDpicmVhay13b3JkO2Jv
cmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2NvbG9yOmJsYWNrIj5JZiBhIHBlZXIgcmVwb3J0IHJlYWN0aW5nIG5vZGUgcmVjZWl2ZXMg
YW4gT0MtT0xSIEFWUCBvZiB0eXBlIHBlZXIgYW5kIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29y
ZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs
YWNrIj5Tb3VyY2VJRCBkb2VzIG5vdCBtYXRjaCB0aGUgPGI+RGlhbWV0ZXJJZGVudGl0eSA8L2I+
b2YgdGhlIHBlZXIgZnJvbSB3aGljaCB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6
YnJlYWstYWxsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+
cmVwb3J0IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh
Y2siPndhcyByZWNlaXZlZCB0aGVuIHRoZSByZWFjdGluZyBub2RlIE1VU1QgaWdub3JlIHRoZSBv
dmVybG9hZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRv
bTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5yZXBvcnQuPC9zcGFuPjxvOnA+PC9v
OnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5BbHNvIEkgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIHVzZSBvbmUgd29yZGluZyBm
b3IgdGhlIHNhbWUgdGVybTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+JnF1b3Q7UGVlciBSZXBvcnQgT0xSJnF1b3Q7LCAmcXVvdDtPQy1PTFIg
QVZQJnF1b3Q7LCAmcXVvdDtPTFImcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TGV0J3MgdXNlIGEgZ2VuZXJpYyBvbmUgJnF1b3Q7cGVl
ciByZXBvcnQmcXVvdDs/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkp1c3QgbWlub3IgY29tbWVudDogJnF1b3Q7dGhlIGV4
aXN0aW5nLi4uJnF1b3Q7IGFuZCAmcXVvdDthIG5ldyBvdmVybG9hZCBjb25kaXRpb24mcXVvdDsg
Zm9yIGFsbCBvY2N1cnJlbmNlcyBpZiBteSBFbmdsaXNoIGlzIGNvcnJlY3QuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xNi4gc2VjdGlv
biA1LjIuMzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+SG93IG1heSBpdCBoYXBwZW4gdGhhdCBwZWVyIHJlcG9ydCByZWFjdGluZyBub2Rl
IHJlY2VpdmVzIGEgcGVlciByZXBvcnQgbm90IGZyb20gdGhlIHBlZXIgdGhhdCBnZW5lcmF0ZWQg
aXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PlBlZXIgcmVwb3J0cyBjYW4gYmUgc2VudCBvbmx5IHRvIHBlZXIgcmVwb3J0IHJlYWN0aW5nIG5v
ZGUsIHJpZ2h0PyBBbmQgcGVlciByZXBvcnRzIGFyZSBub3QgcmVsYXllZCwgcmlnaHQ/PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0
IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4vTWlzaGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDE3LTAxLTA5IDE3OjM1IEdNVCYjNDM7MDM6MDAgVGhl
IElFU0cgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPmllc2ctc2VjcmV0YXJ5QGlldGYub3JnPC9hPiZndDs6PG86cD48L286cD48L3A+
DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBm
cm9tIHRoZSBEaWFtZXRlciBNYWludGVuYW5jZSBhbmQ8YnI+DQpFeHRlbnNpb25zIFdHIChkaW1l
KSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Ojxicj4NCi0gJ0RpYW1ldGVyIEFn
ZW50IE92ZXJsb2FkIGFuZCB0aGUgUGVlciBPdmVybG9hZCBSZXBvcnQnPGJyPg0KJm5ic3A7ICZs
dDtkcmFmdC1pZXRmLWRpbWUtYWdlbnQtb3ZlcmxvYWQtMDgudHh0Jmd0OyBhcyBQcm9wb3NlZCBT
dGFuZGFyZDxicj4NCjxicj4NClRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0
aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0czxicj4NCmZpbmFsIGNvbW1lbnRzIG9uIHRo
aXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGU8YnI+DQo8
YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAaWV0Zi5v
cmc8L2E+IG1haWxpbmcgbGlzdHMgYnkgMjAxNy0wMS0yMy4gRXhjZXB0aW9uYWxseSwgY29tbWVu
dHMgbWF5IGJlPGJyPg0Kc2VudCB0byA8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPmllc2dAaWV0Zi5vcmc8L2E+IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBw
bGVhc2UgcmV0YWluIHRoZTxicj4NCmJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFs
bG93IGF1dG9tYXRlZCBzb3J0aW5nLjxicj4NCjxicj4NCkFic3RyYWN0PGJyPg0KPGJyPg0KPGJy
Pg0KJm5ic3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBkb2N1bWVudHMgYW4gZXh0ZW5zaW9u
IHRvIFJGQyA3NjgzIChEaWFtZXRlcjxicj4NCiZuYnNwOyAmbmJzcDtPdmVybG9hZCBJbmRpY2F0
aW9uIENvbnZleWFuY2UgKERPSUMpKSBiYXNlIHNvbHV0aW9uLiZuYnNwOyBUaGUgZXh0ZW5zaW9u
PGJyPg0KJm5ic3A7ICZuYnNwO2RlZmluZXMgdGhlIFBlZXIgb3ZlcmxvYWQgcmVwb3J0IHR5cGUu
Jm5ic3A7IFRoZSBpbml0aWFsIHVzZSBjYXNlIGZvciB0aGU8YnI+DQombmJzcDsgJm5ic3A7UGVl
ciByZXBvcnQgaXMgdGhlIGhhbmRsaW5nIG9mIG9jY3VycmVuY2VzIG9mIG92ZXJsb2FkIG9mIGEg
RGlhbWV0ZXI8YnI+DQombmJzcDsgJm5ic3A7YWdlbnQuPGJyPg0KPGJyPg0KUmVxdWlyZW1lbnRz
PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYTxicj4N
CjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGlt
ZS1hZ2VudC1vdmVybG9hZC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1pZXRmLWRpbWUtYWdlbnQtb3ZlcmxvYWQvPC9hPjxicj4NCjxicj4N
CklFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWE8YnI+DQo8YSBocmVmPSJodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRpbWUtYWdlbnQtb3ZlcmxvYWQv
YmFsbG90LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LWlldGYtZGltZS1hZ2VudC1vdmVybG9hZC9iYWxsb3QvPC9hPjxicj4NCjxicj4NCjxi
cj4NCk5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0
aGlzIEktRC48YnI+DQo8YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnQgY29udGFpbnMgdGhlc2Ugbm9y
bWF0aXZlIGRvd253YXJkIHJlZmVyZW5jZXMuPGJyPg0KU2VlIFJGQyAzOTY3IGZvciBhZGRpdGlv
bmFsIGluZm9ybWF0aW9uOjxicj4NCiZuYnNwOyAmbmJzcDsgZHJhZnQtcm9hY2gtZGltZS1vdmVy
bG9hZC1jdHJsOiBBIE1lY2hhbmlzbSBmb3IgRGlhbWV0ZXIgT3ZlcmxvYWQgQ29udHJvbCAoTm9u
ZSAtICk8YnI+DQpOb3RlIHRoYXQgc29tZSBvZiB0aGVzZSByZWZlcmVuY2VzIG1heSBhbHJlYWR5
IGJlIGxpc3RlZCBpbiB0aGUgYWNjZXB0YWJsZSBEb3ducmVmIFJlZ2lzdHJ5Ljxicj4NCjxicj4N
Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KRGlNRSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiPkRpTUVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9hPjxvOnA+PC9vOnA+PC9wPg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPlRoaXMgZWxlY3Ryb25pYyBtZXNzYWdl
IHRyYW5zbWlzc2lvbiBjb250YWlucyBpbmZvcm1hdGlvbiBmcm9tIENTUkEgdGhhdCBtYXkgYmUg
YXR0b3JuZXktY2xpZW50IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5IG9yIGNvbmZpZGVudGlhbC4g
VGhlIGluZm9ybWF0aW9uIGluIHRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB1c2Ug
YnkgdGhlIGluZGl2aWR1YWwocykgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBiZWxp
ZXZlDQogeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UgY29u
dGFjdCBtZSBpbW1lZGlhdGVseSBhbmQgYmUgYXdhcmUgdGhhdCBhbnkgdXNlLCBkaXNjbG9zdXJl
LCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdl
IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhp
cyBlbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kDQogQ1NSQSB0byBhbnkgb3JkZXIgb3Ig
b3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4gYWdyZWVt
ZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNl
IG9mIGVtYWlsIGZvciBzdWNoIHB1cnBvc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_82cae801ab704dc483228653735ddb6aCSRRDU1EXM025corpcsraco_--


From nobody Wed Jan 18 10:40:18 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5E4129556; Wed, 18 Jan 2017 10:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSXW8KHmcl51; Wed, 18 Jan 2017 10:40:04 -0800 (PST)
Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 28CDA129555; Wed, 18 Jan 2017 10:40:04 -0800 (PST)
Received: by mail-lf0-x243.google.com with SMTP id q89so2955373lfi.1; Wed, 18 Jan 2017 10:40:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0qo9hsQ+6q3D3Huvy65ivN6XGB2jtRNrquGtrMRQLak=; b=VVZjFz7N8Fax/Ft3O3t57yjARkfUXRZ1mkeMdgE+hBh+cNfskbxv3cM8GUb9+zjOjT uOy7gjWgMNLB4cT1vd611hEmp+3RrNLsK0SsdsMdWLYxUdLZxaMJ4pHEgsiBrWAK2X9P O/XtKaNeWd55Rfa2O6qcecOI7WM/tNa3m5bwm0cCg23EcoUZYqtJvBWc/1JJAacN9zw8 qQsTWUldaOjtUzeq5mGv41OfoOGXch4qtSHSY5OrSStKFzw508XX4qBE+RpPzkx2UGvR ZNmpKME8Nq5Y7NSxNgkrnny/cWly6yrSKUzlxOmONKamoryEjsVI1VxF59HGH+YltFo+ xHMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0qo9hsQ+6q3D3Huvy65ivN6XGB2jtRNrquGtrMRQLak=; b=nVLZlaN2542Ap3hhgweFdpgxGgFwHXnh5CVJlM29Rqw9wLJVn31XUosQTvXyyKq/M3 goXdKjfj6tALGbl6UtwOMfR00B6HIUPRpUQcLhtuMWOLK27AHdKoy1QjgbweuD+9RnuM wLhi7Qk9xanCwdB5uwqctlyLth+1dKQqxywNoVVTVU+drHHltezVmoM7yqKI2+lOU32i ZlFs8rwFRtBoeF+AwXmV725sctwHYrWEuZLzPsNXmyPVFrx7A/3OZXEH0OtaEMqsG3Dv q8RIbc9n3BEj7RuFJ9SvoGcz+UEQAi1jFsGR2UuE3OfOMchCYXg/e1C2YCqpjJJtMflZ Y3IA==
X-Gm-Message-State: AIkVDXLFDAgovcr6s8OjNQv4t8EDxAcUW/j4ZMknBmxKs2m5chEs1A9D1a2w+ECqzM1gaz5AVAOkhfbUGnmM+Q==
X-Received: by 10.46.1.153 with SMTP id f25mr2171171lji.47.1484764802103; Wed, 18 Jan 2017 10:40:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Wed, 18 Jan 2017 10:40:01 -0800 (PST)
In-Reply-To: 
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com> 
From: Misha Zaytsev 
Date: Wed, 18 Jan 2017 21:40:01 +0300
Message-ID: 
To: ietf@ietf.org
Content-Type: multipart/alternative; boundary=001a1142be3c9abcfb054662bed1
Archived-At: 
Cc: dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-agent-overload@ietf.org, IETF-Announce 
Subject: Re: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jan 2017 18:40:10 -0000

--001a1142be3c9abcfb054662bed1
Content-Type: text/plain; charset=UTF-8

Hi All,

As promised here is the second part of the comments (numbering is kept):

17. section 5.2.3, 5.2.4 (and further if applicable)

Why not to use "active OCS" instead of "existing OCS" or "existing overload
conditions"?
Just to be inline with the RFC7683 this draft is extending...

18. section 5.2.4

What is meant here? Especially "other overload reporting node behaviors".
For me it says about all and about nothing at the same time. Please clarify

The reporting agent must follow all other overload reporting node
   behaviors outlined in the DOIC specification.


19. section 5.2.5

Seems to be a little bit grammatically incorrect, "on" -> "to"

If the request matches an active OCS then the reacting node MUST
   apply abatement treatment *to *the request.

Maybe "error response" sounds better than just an "error" in this case:

... agent MUST send an appropriate error response as defined in [RFC7683].

Seems to be wrongly phrased:

 ... then *abatement *associated with the overload *abatement *MUST be
ended in a
   controlled fashion.


20. section 6

I do not know why but I do not like the following wording:

... used as part of the CER/CEA base Diameter capabilities exchange.


Probably this version is better:

... used as part of the Diameter Capabilities Exchange procedure
defined in [RFC6733].


21. section 6.1.1

The peer report feature defines a new feature bit *that (?)*is added
for the OC-Feature-Vector AVP.


22. section 6.2, similar to comment#16

In the section 5.1.2 it says the following:

When receiving a request a DOIC node that supports the OC_PEER_REPORT
   feature MUST update transaction state with *an indication of whether
   or not the peer from which the request was received supports the
   OC_PEER_REPORT feature.*

      Note: The transaction state is used when the DOIC node is acting
      as a peer-report reporting node and needs send OC-OLR reports of
      type PEER_REPORT in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.

So, my gut feeling is that it means that peer report can't be sent thru a
non-supporting agent???
If I'm wrong, please clarify that.

Also, just several updates in wording + corrected misprints.

The overload report MUST also include the Diameter identity of the
   agent that generated the report.  This is necessary to handle the
   case where there is a non*-*supporting agent between the reporting node
   and the reacting node.  Without the indication of the agent that
   generated the overload *report*, the reacting node could erroneously
   assume that the report applied to the non-supporting node.  This
   could, in turn, result in unnecessary traffic being either
   *diverged* or throttled.


23. section 6.3 "SourceID" -> "SourceID AVP" in the section header.

Seems to be all from my side, but probably I have still missed something.
Anyway, I'm ready to re-check the new version of the draft when available.

Best regards,

/Misha

2017-01-17 23:23 GMT+03:00 Misha Zaytsev :

> Hi All,
>
> Here are my comments/questions to an agent overload draft.
> This the first part. Later on I will complete my review and send out the
> second portion of the comments.
>
> 1. section 1 (editorial) removed "is" before "feasible".
>
> In the base specification, the goal is to handle abatement of the
>    overload occurrence as close to the source of the Diameter traffic as
>    feasible.
>
>
> "scenaios" -> "scenarios"
>
> The Peer overload report type is
>    defined in a generic fashion so that it can also be used for other
>    Diameter overload *scenarios*.
>
>
> 2. section 3.1.1 (editorial) replaced "were"-> "was"
>
> In both of these cases, the occurrence of overload in the single
>    agent must by handled by the client in a similar fashion as if the
>    client *was* handling the overload of a directly connected server.
>
>
> 3. section 3.1.1 (question)
>
> An appropriate error response is sent back to the originator
>    of the request.
>
> Who sends "an appropriate" error response" in this case?
>
> 4. section 3.1.2 (editorial) changed "to"->"the"
>
> When the client has an active and a standby connection to the two
>    agents then an alternative strategy for responding to an overload
>    report from an agent is to change *the *standby connection to active and
>    route all traffic through the new active connection.
>
>
> 5. section 3.1.3 (editorial)
>
> An example of this type of deployment include*s* when there are Diameter
>    agents between administrative domains.
>
> 6. section 3.1.3
>
> There is no section 2.2. I guess section 3.1.2 was meant here, right?
>
> Handling of overload of one or both of agents a11 or a12 in this case
>    is equivalent to that discussed in section 2.2.
>
>
> 7. section 3.2.1
>
> It is not clear which usage scenario is meant here.
>
>    It is envisioned that abatement algorithms will be defined that will
>    support the option for Diameter Endpoints to send peer reports.  For
>    instance, it is envisioned that one usage scenario for the rate
>    algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
>    on by the DIME working group as this document is being written, will
>    involve abatement being done on a hop-by-hop basis.
>
>
> 8. section 4
>
> Why is throttling to be applied and not diversion (like in case of
> redundant agents)?
>
> In this scenario the reacting node should first handle the throttling of the
>    overloaded host or realm.
>
> "LOSS" Is it a new type defined in the scope of this draft?
>
> Note: The goal is to avoid traffic oscillations that might result
>       from throttling of messages for both the HOST/REALM overload
>       reports and the PEER overload reports.  This is especially a
>       concern if *both reports are of type LOSS*.
>
>
> 9. section 5.1.1
>
> Probably it is better to describe OC_PEER_REPORT feature in section 5.1?
> Otherwise, it is used as a well-known one while it is the first place
> where it is mentioned.
>
> Also I think it is better to add more specific in this draft related to
> peer report handling:
> - define Peer Report Reacting Node and Peer Report Reporting Node terms
> explicitly and use them through the draft and especially starting from
> section 5.1
> - add "Peer Report" prefix to all the described procedures
> Example: Capability Announcement -> Peer Report Capability Announcement
>
> 10. section 5.1.1/general
>
> "DiameterIdentity" and "Diameter identity"
> My proposal is to use one term through the spec.
>
> Under "DOIC node", an agent is meant here?
>
>  When an agent relays a request that includes a SourceID AVP in the
>    OC-Supported-Features AVP, a DOIC node that supports the
>    OC_PEER_REPORT feature MUST remove the received SourceID AVP and
>    replace it with a SourceID AVP containing its own Diameter identity.
>
>
> My proposal is to use peer report reacting node here re-phrasing this
> statement below in the following way:
>
>  When relaying a request that includes a SourceID AVP in the
>    OC-Supported-Features AVP, a peer report reacting node MUST remove the received SourceID AVP and
>    replace it with a SourceID AVP containing its own DiameterIdentity.
>
> 11. section 5.1.2
>
> added the missed "to"
> changed "PEER_REPORT"-> "PEER"
>
> Note: The transaction state is used when the DOIC node is acting
>       as a peer-report reporting node and needs *to *send OC-OLR reports of
>       type *PEER *in answer messages.  The peer overload reports
>       are only included in answer messages being sent to peers that
>       support the OC_PEER_REPORT feature.
>
>
> "Diameter ID" term is not clarified anywhere.
> Re-phrased the appropriate statement a little bit, changed "Diameter
> ID"->"value"
> Also there are other places in the draft where "Diameter ID" term is used.
>
> The peer supports the OC_PEER_REPORT feature if the received request
>    contains an OC-Supported-Features AVP with the OC-Feature-Vector with
>    the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
>    value that matches the DiameterIdentity of the peer from which
>    the request was received.
>
>
> Agent is meant under "reporting node" here?
>
> Should not SourceID AVP not just stripped from the relayed answer, but
> replaced with the SourceID AVP containing the DiameterIdentity of the agent
> supporting OC_PEER_REPORT feature?
>
> When an agent relays an answer message, a reporting node that
>    supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
>    the OC-Supported-Features AVP.
>
>
> Hard to follow what was wanted to say here:
> Corrected the statement, but this is just my best guess.
>
> The OC-Peer-Algo AVP MUST indicate the overload abatement
>    algorithm that the reporting node wants the reacting nodes to use
>    *when *the reporting node send*s* a peer overload report as a result of
>    becoming overloaded.
>
>
> Should not we add a separate if- statement for the case when the peer does
> not support OC_PEER_REPORT feature when sending an answer message?
>
> 12. section 5.1.1 and 5.1.2
>
> Probably it is more helpful to illustrate OC_PEER_REPORT feature CA using
> sequence diagrams like in the load info conveyance draft.
>
> 13. general.
>
> What about to use the writing for the same terms through the spec?
> Example1: "DOIC node" and "DOIC Node"
> Example2: "peer-report reporting node" and "peer report reporting node"
>
> 14. section 5.2.1.2, 5.2.2, 5.2.3 and general
>
> "peer-type OCS" and "peer report OCS" define the same term?
> Why not to use only one?
>
> Another example: "peer report" and "peer report-type" and "report of type
> PEER"
>
> 15. section 5.2.3
>
> Probably it is better to re-phrase this statement a little bit + corrected
> the misprints.
>
> If a *peer report* reacting node receives an OC-OLR AVP of type peer and the
> SourceID matches the *DiameterIdentity *of the peer from which the *report*
> was received then the report was *generated *by the peer.
>
>
> Similar comment + corrected misprints for the next statement:
>
> If a peer report reacting node receives an OC-OLR AVP of type peer and the
> SourceID does not match the *DiameterIdentity *of the peer from which the*report *was received then the reacting node MUST ignore the overload
> report.
>
>
> Also I think it is useful to use one wording for the same term:
> "Peer Report OLR", "OC-OLR AVP", "OLR"
> Let's use a generic one "peer report"?
>
> Just minor comment: "the existing..." and "a new overload condition" for
> all occurrences if my English is correct.
>
> 16. section 5.2.3
>
> How may it happen that peer report reacting node receives a peer report
> not from the peer that generated it?
> Peer reports can be sent only to peer report reacting node, right? And
> peer reports are not relayed, right?
>
> Best regards,
>
> /Misha
>
>
> 2017-01-09 17:35 GMT+03:00 The IESG :
>
>>
>> The IESG has received a request from the Diameter Maintenance and
>> Extensions WG (dime) to consider the following document:
>> - 'Diameter Agent Overload and the Peer Overload Report'
>>    as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2017-01-23. Exceptionally, comments may be
>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    This specification documents an extension to RFC 7683 (Diameter
>>    Overload Indication Conveyance (DOIC)) base solution.  The extension
>>    defines the Peer overload report type.  The initial use case for the
>>    Peer report is the handling of occurrences of overload of a Diameter
>>    agent.
>>
>> Requirements
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>> The document contains these normative downward references.
>> See RFC 3967 for additional information:
>>     draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload
>> Control (None - )
>> Note that some of these references may already be listed in the
>> acceptable Downref Registry.
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>
>

--001a1142be3c9abcfb054662bed1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi All,

As promised here is the second =
part of the comments (numbering is kept):

17. sect=
ion 5.2.3, 5.2.4 (and further if applicable)

Why n=
ot to use "active OCS" instead of "existing OCS" or &qu=
ot;existing overload conditions"?
Just to be inline with the=
 RFC7683 this draft is extending...

18. section 5.=
2.4

What is meant here? Especially "other ove=
rload reporting node behaviors".
For me it says about all an=
d about nothing at the same time. Please clarify

<=
pre style=3D"box-sizing:border-box;overflow:auto;font-family:"pt mono&=
quot;,monaco,monospace;font-size:14px;padding:10px;margin-top:0px;margin-bo=
ttom:10.5px;line-height:1.214;color:rgb(0,0,0);word-break:break-all;word-wr=
ap:break-word;background-color:rgb(255,253,245);border:1px solid rgb(204,20=
4,204);border-radius:4px">The reporting agent must follow all other overloa=
d reporting node
   behaviors outlined in the DOIC specification.

=

19. section 5.2.5

Seems to be a little bit gr=
ammatically incorrect, "on" -> "to"

If the request matches an active OCS th=
en the reacting node MUST
   apply abatement treatment to the request.
Maybe &=
quot;error response" sounds better than just an "error" in t=
his case:

... agent MUS=
T send an appropriate error response as defined in [RFC7683].
Seems to be wrongly phrased:

 ... then abatement associated with the overload abateme=
nt MUST be ended in a
   controlled fashion.

20. section 6

I do not know why but I do not like the following wording=
:

... used as part of t=
he CER/CEA base Diameter capabilities exchange.

<=
div>Probably this version is better:

... used as part of the Diameter Capabilities Exchange proced=
ure defined in [RFC6733].

21. section 6.1.1=
=C2=A0

The peer report featu=
re defines a new feature bit that (?)is added for the=C2=A0OC-Featur=
e-Vector AVP.=C2=A0

22. section 6.2, similar to comment#16

In the section 5.1.2 it says the following:

=

When receiving a request a DOIC node that suppor=
ts the OC_PEER_REPORT
   feature MUST update transaction state with an indication of whether
   or not the peer from which the request was received supports the
   OC_PEER_REPORT feature.

      Note: The transaction state is used when the DOIC node is acting
      as a peer-report reporting node and needs send OC-OLR reports of
      type PEER_REPORT in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.
So, my gut feelin=
g is that it means that peer report can't be sent thru a non-supporting=
 agent???
If I'm wrong, please clarify that.

Also, just several updates in wording + corrected misprints.
=

The overload report MUST also inc=
lude the Diameter identity of the
   agent that generated the report.  This is necessary to handle the
   case where there is a non-supporting agent between the reporting =
node
   and the reacting node.  Without the indication of the agent that
   generated the overload report, the reacting node could erroneousl=
y
   assume that the report applied to the non-supporting node.  This
   could, in turn, result in unnecessary traffic being either
   diverged or =
throttled.

23. section 6.3 &qu=
ot;SourceID" -> "SourceID AVP" in the section header.

Seems to be all from my side, but probably I have sti=
ll missed something.
Anyway, I'm ready to re-check the new ve=
rsion of the draft when available.

Best regards,

/Misha

2017-01-17 23:23 GMT+03:00 Misha Zaytsev <misha.zaytsev.rus@gmail.com>:
Hi All,

Here are my comments/ques=
tions to an agent overload draft.
This the first part. Later on I=
 will complete my review and send out the second portion of the comments.

1. section 1 (editorial) removed "is"=
; before "feasible".

In the base specification, the goal is to handle abatement of the
   overload occurrence as close to the source of the Diameter traffic as
   feasible.

"scenaios" ->=
; "scenarios"

The Peer overload report type is
   defined in a generic fashion so that it can also be used for other
   Diameter overload scenarios.

2. se=
ction 3.1.1 (editorial) replaced "were"-> "was"

In both of these cases, the=
 occurrence of overload in the single
   agent must by handled by the client in a similar fashion as if the
   client was handling the overload of a directly connected server.<=
/pre>

3. section 3.1.1 (question)

An appropriate error response is sent b=
ack to the originator
   of the request.
Who sends "an appropriate" err=
or response" in this case?

4. section 3.1.2 (=
editorial) changed "to"->"the"

<=
div>
When the client has an active and a standby =
connection to the two
   agents then an alternative strategy for responding to an overload
   report from an agent is to change the standby connection to activ=
e and
   route all traffic through the new active connection.
5. section 3.1.3 (editorial)

An example of this type of deployment includes whe=
n there are Diameter
   agents between administrative domains.
6. section 3.1.3<=
/div>

There is no section 2.2. I guess section 3.1.2 was=
 meant here, right?

Han=
dling of overload of one or both of agents a11 or a12 in this case
   is equivalent to that discussed in section 2.2.

7. section 3.2.1

It is not clear which usag=
e scenario is meant here.

   It is envisioned that abatement algorithms will be defined that will
   support the option for Diameter Endpoints to send peer reports.  For
   instance, it is envisioned that one usage scenario for the rate
   algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
   on by the DIME working group as this document is being written, will
   involve abatement being done on a hop-by-hop basis.

=

8. section 4

Why is throttling to be ap=
plied and not diversion (like in case of redundant agents)?=C2=A0

In this scenario the reacting no=
de should first handle the throttling of the
   overloaded host or realm.
"LOSS" Is it a new t=
ype defined in the scope of this draft?

Note: The goal is to avoid traffic oscillations that might=
 result
      from throttling of messages for both the HOST/REALM overload
      reports and the PEER overload reports.  This is especially a
      concern if both reports are of type LOSS.

=

9. section 5.1.1

Probably it is better =
to describe OC_PEER_REPORT feature in section 5.1?
Otherwise, it =
is used as a well-known one while it is the first place where it is mention=
ed.

Also I think it is better to add more specific=
 in this draft related to peer report handling:
- define Peer Rep=
ort Reacting Node and Peer Report Reporting Node terms explicitly and use t=
hem through the draft and especially starting from section 5.1=C2=A0
- add "Peer Report" prefix to all the described procedure=
s
Example: Capability Announcement -> Peer Report Capability A=
nnouncement

10. section 5.1.1/general
"DiameterIdentity" and "Diameter identity"=

My proposal is to use one term through the spec.

<=
/div>
Under "DOIC node", an agent is meant here?
 When an agent relays a request tha=
t includes a SourceID AVP in the
   OC-Supported-Features AVP, a DOIC node that supports the
   OC_PEER_REPORT feature MUST remove the received SourceID AVP and
   replace it with a SourceID AVP containing its own Diameter identity.

My proposal is to use peer report reacting node=
 here re-phrasing this statement below in the following way:
=

 When relaying a request that inc=
ludes a SourceID AVP in the
   OC-Supported-Features AVP, a peer report reacting node MUST remove the r=
eceived SourceID AVP and
   replace it with a SourceID AVP containing its own DiameterIdentity.
11. section 5.1.2

added the missed &qu=
ot;to"
changed "PEER_REPORT"-> "PEER"=


Note: The transaction =
state is used when the DOIC node is acting
      as a peer-report reporting node and needs to send OC-OLR repor=
ts of
      type PEER in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.

&q=
uot;Diameter ID" term is not clarified anywhere.
Re-phrased =
the appropriate statement a little bit, changed "Diameter ID"->=
;"value"
Also there are other places in the draft where=
 "Diameter ID" term is used.

The peer supports the OC_PEER_REPORT feature if the receiv=
ed request
   contains an OC-Supported-Features AVP with the OC-Feature-Vector with
   the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
   value that matches the DiameterIdentity of the peer from which
   the request was received.

Agent is meant =
under "reporting node" here?

Should not =
SourceID AVP not just stripped from the relayed answer, but replaced with t=
he SourceID AVP containing the DiameterIdentity of the agent supporting OC_=
PEER_REPORT feature?

Wh=
en an agent relays an answer message, a reporting node that
   supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
   the OC-Supported-Features AVP.

Hard to fo=
llow what was wanted to say here:
Corrected the statement, but th=
is is just my best guess.

The OC-Peer-Algo AVP MUST indicate the overload abatement
   algorithm that the reporting node wants the reacting nodes to use
   when the reporting node sends a peer overload report as a =
result of
   becoming overloaded.

Should not we add a =
separate if- statement for the case when the peer does not support OC_PEER_=
REPORT feature when sending an answer message?

12.=
 section 5.1.1 and 5.1.2

Probably it is more helpf=
ul to illustrate OC_PEER_REPORT feature CA using sequence diagrams like in =
the load info conveyance draft.

13. general.
=


What about to use the writing for the same terms throug=
h the spec?
Example1: "DOIC node" and "DOIC Node&q=
uot;
Example2: "peer-report reporting node" and "p=
eer report reporting node"

14. section 5.2.1.=
2, 5.2.2, 5.2.3 and general

"peer-type OCS&qu=
ot; and "peer report OCS" define the same term?
Why not=
 to use only one?

Another example: "peer =
report" and "peer report-type" and "report of type PEER=
"

15. section 5.2.3

<=
div>Probably it is better to re-phrase this statement a little bit + correc=
ted the misprints.

If a=
 peer report reacting node receives an OC-OLR AVP of type peer and t=
he
SourceID matches the DiameterIdentity of the peer from which the =
report
was received then the report was generated by the peer.
<=
div>
Similar comment + corrected misprints for the next state=
ment:

If a peer report =
reacting node receives an OC-OLR AVP of type peer and the
SourceID does not match the DiameterIdentity of the peer from which =
the
report was received then the reacting node MUST ignore the overload
report.

Also I think it is useful to us=
e one wording for the same term:
"Peer Report OLR", &qu=
ot;OC-OLR AVP", "OLR"
Let's use a generic one =
"peer report"?

Just minor comment:=
 "the existing..." and "a new overload condition" for a=
ll occurrences if my English is correct.

16. secti=
on 5.2.3

How may it happen that peer report reacti=
ng node receives a peer report not from the peer that generated it?
Peer reports can be sent only to peer report reacting node, right? And p=
eer reports are not relayed, right?

Best regards,<=
/div>

/Misha


2017-01-09 17:35 GMT+03:00 The IESG <iesg-secretary@ietf.org>:


The IESG has received a request from the Diameter Maintenance and

Extensions WG (dime) to consider the following document:

- 'Diameter Agent Overload and the Peer Overload Report'

=C2=A0 <draft-ietf-dime-agent-overload-08.txt> as Proposed Stand=
ard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailin=
g lists by 2017-01-23. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





=C2=A0 =C2=A0This specification documents an extension to RFC 7683 (Diamete=
r

=C2=A0 =C2=A0Overload Indication Conveyance (DOIC)) base solution.=C2=A0 Th=
e extension

=C2=A0 =C2=A0defines the Peer overload report type.=C2=A0 The initial use c=
ase for the

=C2=A0 =C2=A0Peer report is the handling of occurrences of overload of a Di=
ameter

=C2=A0 =C2=A0agent.



Requirements







The file can be obtained via

https://datatracker.ietf.org/do=
c/draft-ietf-dime-agent-overload/



IESG discussion can be tracked via

https://datatracker.ietf.org/=
doc/draft-ietf-dime-agent-overload/ballot/





No IPR declarations have been submitted directly on this I-D.





The document contains these normative downward references.

See RFC 3967 for additional information:

=C2=A0 =C2=A0 draft-roach-dime-overload-ctrl: A Mechanism for Diameter=
 Overload Control (None - )

Note that some of these references may already be listed in the acceptable =
Downref Registry.





_______________________________________________

DiME mailing list

DiME@ietf.org

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








--001a1142be3c9abcfb054662bed1--


From nobody Thu Jan 19 05:18:51 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B59129444; Thu, 19 Jan 2017 05:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-tdrbuj1Y6l; Thu, 19 Jan 2017 05:18:46 -0800 (PST)
Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 77BDF129439; Thu, 19 Jan 2017 05:18:45 -0800 (PST)
Received: by mail-lf0-x241.google.com with SMTP id h65so5361342lfi.3; Thu, 19 Jan 2017 05:18:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pER8vg3xdpecBsRPJW0xg8KpAyqH3FuQKNM9D8PTJZo=; b=ZERZ0JAwhfmf6NrX6gunNh+X6xlwDG2pSc0kvMcZs4ajlLy1Kw4YXx4JltZASmNkRK Qjf7ah4wIqjKHGNI9Wahj2rU6sNIN4ArR3uZvH19rgv9BJauFEass66J6t7tTrj2IhXf N2+B0HqrNL6aW8sHQBCuKq38tEQJHU/QMXKQJfLKSW0D22fwg0wLrJ5ML0ue2lV/Qn28 PtwvADBDaLOu26ODoTjN0MPPSqkSQlcunrc1L5EbZSEvRcQB1sDflGMbAZXxZ+37TwJR tr56ReDYNmobGslaFNdq6VjgfRA8eQf+oX66KUg9dW9sa2+EvnsF0bh3AqHEdY41Ut1N nbdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pER8vg3xdpecBsRPJW0xg8KpAyqH3FuQKNM9D8PTJZo=; b=PJ+Uwot0y2OBqMmipFtAjzbInUdQaXI8OXFesE/BnYK8ScV0+47UK9A5J7F5DvUig7 PCFFRgkY5gi11rZzaYfJOXZSkrDpTWdEVuHgrnAnFigky4ygzeKHbL4quav4Bg4AUeB2 XTzpYo+z34ADhv5wZMUe3O5eB8xk8t3Ez2gJz7Y89BT7tgvE3uW1XN0GPKKNyEftFJUK +lWMBUr0yVjj4RAxhNsl5shujs/PDBRcuMtIaH+VQguJJ06NrJxnPuW4LJVrnYodKLBd BslmRKmYn9GjHKO+0BFy3p2hU/xmE4uzgmBEQs4/m1x+8KMInQX57NZ9PQpbeQSqoet7 iqqg==
X-Gm-Message-State: AIkVDXJqFQC9+P5Va/vXQTWKpkueI0eDuGE1gUdlk0szqh1Y7m/RoaFVuIwDY0mZknpJyMbQfBoT4Oh9jkWGXQ==
X-Received: by 10.46.72.18 with SMTP id v18mr4130741lja.5.1484831923256; Thu, 19 Jan 2017 05:18:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Thu, 19 Jan 2017 05:18:42 -0800 (PST)
In-Reply-To: 
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com>  
From: Misha Zaytsev 
Date: Thu, 19 Jan 2017 16:18:42 +0300
Message-ID: 
To: ietf@ietf.org
Content-Type: multipart/alternative; boundary=f403045ea2825643e70546725f81
Archived-At: 
Cc: dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-agent-overload@ietf.org, IETF-Announce 
Subject: Re: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 13:18:49 -0000

--f403045ea2825643e70546725f81
Content-Type: text/plain; charset=UTF-8

Hi All,

Just several small comment from my side:

24. section 6.1.1. "OC-Feature-Vector" -> "OC-Feature-Vector AVP" in the
header.

25. section 6.1.2 "OC-Peer-Algo" -> "OC-Peer-Algo AVP" in the header

26. section 6.2 corrected AVP names

This extension makes no changes to the *OC-Sequence-Number* or
*OC-Validity-Duration* AVPs in the OC-OLR AVP.

27. section 6.3

Probably, it is the matter of preference, but I would still propose to
rename SourceID to Source-Identity.


Thanks in advance!

/Misha


2017-01-18 21:40 GMT+03:00 Misha Zaytsev :

> Hi All,
>
> As promised here is the second part of the comments (numbering is kept):
>
> 17. section 5.2.3, 5.2.4 (and further if applicable)
>
> Why not to use "active OCS" instead of "existing OCS" or "existing
> overload conditions"?
> Just to be inline with the RFC7683 this draft is extending...
>
> 18. section 5.2.4
>
> What is meant here? Especially "other overload reporting node behaviors".
> For me it says about all and about nothing at the same time. Please clarify
>
> The reporting agent must follow all other overload reporting node
>    behaviors outlined in the DOIC specification.
>
>
> 19. section 5.2.5
>
> Seems to be a little bit grammatically incorrect, "on" -> "to"
>
> If the request matches an active OCS then the reacting node MUST
>    apply abatement treatment *to *the request.
>
> Maybe "error response" sounds better than just an "error" in this case:
>
> ... agent MUST send an appropriate error response as defined in [RFC7683].
>
> Seems to be wrongly phrased:
>
>  ... then *abatement *associated with the overload *abatement *MUST be ended in a
>    controlled fashion.
>
>
> 20. section 6
>
> I do not know why but I do not like the following wording:
>
> ... used as part of the CER/CEA base Diameter capabilities exchange.
>
>
> Probably this version is better:
>
> ... used as part of the Diameter Capabilities Exchange procedure defined in [RFC6733].
>
>
> 21. section 6.1.1
>
> The peer report feature defines a new feature bit *that (?)*is added for the OC-Feature-Vector AVP.
>
>
> 22. section 6.2, similar to comment#16
>
> In the section 5.1.2 it says the following:
>
> When receiving a request a DOIC node that supports the OC_PEER_REPORT
>    feature MUST update transaction state with *an indication of whether
>    or not the peer from which the request was received supports the
>    OC_PEER_REPORT feature.*
>
>       Note: The transaction state is used when the DOIC node is acting
>       as a peer-report reporting node and needs send OC-OLR reports of
>       type PEER_REPORT in answer messages.  The peer overload reports
>       are only included in answer messages being sent to peers that
>       support the OC_PEER_REPORT feature.
>
> So, my gut feeling is that it means that peer report can't be sent thru a
> non-supporting agent???
> If I'm wrong, please clarify that.
>
> Also, just several updates in wording + corrected misprints.
>
> The overload report MUST also include the Diameter identity of the
>    agent that generated the report.  This is necessary to handle the
>    case where there is a non*-*supporting agent between the reporting node
>    and the reacting node.  Without the indication of the agent that
>    generated the overload *report*, the reacting node could erroneously
>    assume that the report applied to the non-supporting node.  This
>    could, in turn, result in unnecessary traffic being either
>    *diverged* or throttled.
>
>
> 23. section 6.3 "SourceID" -> "SourceID AVP" in the section header.
>
> Seems to be all from my side, but probably I have still missed something.
> Anyway, I'm ready to re-check the new version of the draft when available.
>
> Best regards,
>
> /Misha
>
> 2017-01-17 23:23 GMT+03:00 Misha Zaytsev :
>
>> Hi All,
>>
>> Here are my comments/questions to an agent overload draft.
>> This the first part. Later on I will complete my review and send out the
>> second portion of the comments.
>>
>> 1. section 1 (editorial) removed "is" before "feasible".
>>
>> In the base specification, the goal is to handle abatement of the
>>    overload occurrence as close to the source of the Diameter traffic as
>>    feasible.
>>
>>
>> "scenaios" -> "scenarios"
>>
>> The Peer overload report type is
>>    defined in a generic fashion so that it can also be used for other
>>    Diameter overload *scenarios*.
>>
>>
>> 2. section 3.1.1 (editorial) replaced "were"-> "was"
>>
>> In both of these cases, the occurrence of overload in the single
>>    agent must by handled by the client in a similar fashion as if the
>>    client *was* handling the overload of a directly connected server.
>>
>>
>> 3. section 3.1.1 (question)
>>
>> An appropriate error response is sent back to the originator
>>    of the request.
>>
>> Who sends "an appropriate" error response" in this case?
>>
>> 4. section 3.1.2 (editorial) changed "to"->"the"
>>
>> When the client has an active and a standby connection to the two
>>    agents then an alternative strategy for responding to an overload
>>    report from an agent is to change *the *standby connection to active and
>>    route all traffic through the new active connection.
>>
>>
>> 5. section 3.1.3 (editorial)
>>
>> An example of this type of deployment include*s* when there are Diameter
>>    agents between administrative domains.
>>
>> 6. section 3.1.3
>>
>> There is no section 2.2. I guess section 3.1.2 was meant here, right?
>>
>> Handling of overload of one or both of agents a11 or a12 in this case
>>    is equivalent to that discussed in section 2.2.
>>
>>
>> 7. section 3.2.1
>>
>> It is not clear which usage scenario is meant here.
>>
>>    It is envisioned that abatement algorithms will be defined that will
>>    support the option for Diameter Endpoints to send peer reports.  For
>>    instance, it is envisioned that one usage scenario for the rate
>>    algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
>>    on by the DIME working group as this document is being written, will
>>    involve abatement being done on a hop-by-hop basis.
>>
>>
>> 8. section 4
>>
>> Why is throttling to be applied and not diversion (like in case of
>> redundant agents)?
>>
>> In this scenario the reacting node should first handle the throttling of the
>>    overloaded host or realm.
>>
>> "LOSS" Is it a new type defined in the scope of this draft?
>>
>> Note: The goal is to avoid traffic oscillations that might result
>>       from throttling of messages for both the HOST/REALM overload
>>       reports and the PEER overload reports.  This is especially a
>>       concern if *both reports are of type LOSS*.
>>
>>
>> 9. section 5.1.1
>>
>> Probably it is better to describe OC_PEER_REPORT feature in section 5.1?
>> Otherwise, it is used as a well-known one while it is the first place
>> where it is mentioned.
>>
>> Also I think it is better to add more specific in this draft related to
>> peer report handling:
>> - define Peer Report Reacting Node and Peer Report Reporting Node terms
>> explicitly and use them through the draft and especially starting from
>> section 5.1
>> - add "Peer Report" prefix to all the described procedures
>> Example: Capability Announcement -> Peer Report Capability Announcement
>>
>> 10. section 5.1.1/general
>>
>> "DiameterIdentity" and "Diameter identity"
>> My proposal is to use one term through the spec.
>>
>> Under "DOIC node", an agent is meant here?
>>
>>  When an agent relays a request that includes a SourceID AVP in the
>>    OC-Supported-Features AVP, a DOIC node that supports the
>>    OC_PEER_REPORT feature MUST remove the received SourceID AVP and
>>    replace it with a SourceID AVP containing its own Diameter identity.
>>
>>
>> My proposal is to use peer report reacting node here re-phrasing this
>> statement below in the following way:
>>
>>  When relaying a request that includes a SourceID AVP in the
>>    OC-Supported-Features AVP, a peer report reacting node MUST remove the received SourceID AVP and
>>    replace it with a SourceID AVP containing its own DiameterIdentity.
>>
>> 11. section 5.1.2
>>
>> added the missed "to"
>> changed "PEER_REPORT"-> "PEER"
>>
>> Note: The transaction state is used when the DOIC node is acting
>>       as a peer-report reporting node and needs *to *send OC-OLR reports of
>>       type *PEER *in answer messages.  The peer overload reports
>>       are only included in answer messages being sent to peers that
>>       support the OC_PEER_REPORT feature.
>>
>>
>> "Diameter ID" term is not clarified anywhere.
>> Re-phrased the appropriate statement a little bit, changed "Diameter
>> ID"->"value"
>> Also there are other places in the draft where "Diameter ID" term is used.
>>
>> The peer supports the OC_PEER_REPORT feature if the received request
>>    contains an OC-Supported-Features AVP with the OC-Feature-Vector with
>>    the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
>>    value that matches the DiameterIdentity of the peer from which
>>    the request was received.
>>
>>
>> Agent is meant under "reporting node" here?
>>
>> Should not SourceID AVP not just stripped from the relayed answer, but
>> replaced with the SourceID AVP containing the DiameterIdentity of the agent
>> supporting OC_PEER_REPORT feature?
>>
>> When an agent relays an answer message, a reporting node that
>>    supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
>>    the OC-Supported-Features AVP.
>>
>>
>> Hard to follow what was wanted to say here:
>> Corrected the statement, but this is just my best guess.
>>
>> The OC-Peer-Algo AVP MUST indicate the overload abatement
>>    algorithm that the reporting node wants the reacting nodes to use
>>    *when *the reporting node send*s* a peer overload report as a result of
>>    becoming overloaded.
>>
>>
>> Should not we add a separate if- statement for the case when the peer
>> does not support OC_PEER_REPORT feature when sending an answer message?
>>
>> 12. section 5.1.1 and 5.1.2
>>
>> Probably it is more helpful to illustrate OC_PEER_REPORT feature CA using
>> sequence diagrams like in the load info conveyance draft.
>>
>> 13. general.
>>
>> What about to use the writing for the same terms through the spec?
>> Example1: "DOIC node" and "DOIC Node"
>> Example2: "peer-report reporting node" and "peer report reporting node"
>>
>> 14. section 5.2.1.2, 5.2.2, 5.2.3 and general
>>
>> "peer-type OCS" and "peer report OCS" define the same term?
>> Why not to use only one?
>>
>> Another example: "peer report" and "peer report-type" and "report of type
>> PEER"
>>
>> 15. section 5.2.3
>>
>> Probably it is better to re-phrase this statement a little bit +
>> corrected the misprints.
>>
>> If a *peer report* reacting node receives an OC-OLR AVP of type peer and the
>> SourceID matches the *DiameterIdentity *of the peer from which the *report*
>> was received then the report was *generated *by the peer.
>>
>>
>> Similar comment + corrected misprints for the next statement:
>>
>> If a peer report reacting node receives an OC-OLR AVP of type peer and the
>> SourceID does not match the *DiameterIdentity *of the peer from which the*report *was received then the reacting node MUST ignore the overload
>> report.
>>
>>
>> Also I think it is useful to use one wording for the same term:
>> "Peer Report OLR", "OC-OLR AVP", "OLR"
>> Let's use a generic one "peer report"?
>>
>> Just minor comment: "the existing..." and "a new overload condition" for
>> all occurrences if my English is correct.
>>
>> 16. section 5.2.3
>>
>> How may it happen that peer report reacting node receives a peer report
>> not from the peer that generated it?
>> Peer reports can be sent only to peer report reacting node, right? And
>> peer reports are not relayed, right?
>>
>> Best regards,
>>
>> /Misha
>>
>>
>> 2017-01-09 17:35 GMT+03:00 The IESG :
>>
>>>
>>> The IESG has received a request from the Diameter Maintenance and
>>> Extensions WG (dime) to consider the following document:
>>> - 'Diameter Agent Overload and the Peer Overload Report'
>>>    as Proposed Standard
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final comments on this action. Please send substantive comments to the
>>> ietf@ietf.org mailing lists by 2017-01-23. Exceptionally, comments may
>>> be
>>> sent to iesg@ietf.org instead. In either case, please retain the
>>> beginning of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>>    This specification documents an extension to RFC 7683 (Diameter
>>>    Overload Indication Conveyance (DOIC)) base solution.  The extension
>>>    defines the Peer overload report type.  The initial use case for the
>>>    Peer report is the handling of occurrences of overload of a Diameter
>>>    agent.
>>>
>>> Requirements
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/
>>>
>>> IESG discussion can be tracked via
>>> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot/
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>>> The document contains these normative downward references.
>>> See RFC 3967 for additional information:
>>>     draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload
>>> Control (None - )
>>> Note that some of these references may already be listed in the
>>> acceptable Downref Registry.
>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>>
>>
>

--f403045ea2825643e70546725f81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi All,

Just several small comment from my side:

24. section 6.1.1.=
 "OC-Feature-Vector" -> "OC-Feature-Vector AVP" in t=
he header.

25. section 6.1.2 "OC-Peer-Algo" -> &q=
uot;OC-Peer-Algo AVP" in the header

26. section 6.2 corre=
cted AVP names

This extension makes no changes to the OC-Sequence=
-Number or   OC-Validity-Duration AVPs in the OC-OLR AVP.
27. section 6.3

Probably, it is the matter of preferenc=
e, but I would still propose to rename SourceID to Source-Identity.

=

Thanks in advance!

/Misha


2017-01-18 21:40 GMT+03:00 Mis=
ha Zaytsev <misha.zaytsev.rus@gmail.com>:
Hi All,

As pr=
omised here is the second part of the comments (numbering is kept):

17. section 5.2.3, 5.2.4 (and further if applicable)

Why not to use "active OCS" instead of "=
;existing OCS" or "existing overload conditions"?
=
Just to be inline with the RFC7683 this draft is extending...
18. section 5.2.4

What is meant here? =
Especially "other overload reporting node behaviors".
F=
or me it says about all and about nothing at the same time. Please clarify<=
/div>

The reporting agent mus=
t follow all other overload reporting node
   behaviors outlined in the DOIC specification.

=

19. section 5.2.5

Seems to be a little bit gr=
ammatically incorrect, "on" -> "to"

If the request matches an active OCS th=
en the reacting node MUST
   apply abatement treatment to the request.
Maybe &=
quot;error response" sounds better than just an "error" in t=
his case:

... agent MUS=
T send an appropriate error response as defined in [RFC7683].
Seems to be wrongly phrased:

 ... then abatement associated with the overload abateme=
nt MUST be ended in a
   controlled fashion.

20. section 6

I do not know why but I do not like the following wording=
:

... used as part of t=
he CER/CEA base Diameter capabilities exchange.

<=
div>Probably this version is better:

... used as part of the Diameter Capabilities Exchange proced=
ure defined in [RFC6733].

21. section 6.1.1=
=C2=A0

The peer report featu=
re defines a new feature bit that (?)is added for the=C2=A0OC-Featur=
e-Vector AVP.=C2=A0

22. section 6.2, similar to comment#16

In the section 5.1.2 it says the following:

=

When receiving a request a DOIC node that suppor=
ts the OC_PEER_REPORT
   feature MUST update transaction state with an indication of whether
   or not the peer from which the request was received supports the
   OC_PEER_REPORT feature.

      Note: The transaction state is used when the DOIC node is acting
      as a peer-report reporting node and needs send OC-OLR reports of
      type PEER_REPORT in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.
So, my gut feelin=
g is that it means that peer report can't be sent thru a non-supporting=
 agent???
If I'm wrong, please clarify that.

Also, just several updates in wording + corrected misprints.
=

The overload report MUST also inc=
lude the Diameter identity of the
   agent that generated the report.  This is necessary to handle the
   case where there is a non-supporting agent between the reporting =
node
   and the reacting node.  Without the indication of the agent that
   generated the overload report, the reacting node could erroneousl=
y
   assume that the report applied to the non-supporting node.  This
   could, in turn, result in unnecessary traffic being either
   diverged or =
throttled.

23. section 6.3 &qu=
ot;SourceID" -> "SourceID AVP" in the section header.

Seems to be all from my side, but probably I have sti=
ll missed something.
Anyway, I'm ready to re-check the new ve=
rsion of the draft when available.

Best regards,

/Misha

2017-01-1=
7 23:23 GMT+03:00 Misha Zaytsev <misha.zaytsev.rus@gmail.com=
>:
Hi All,
Here are my comments/questions to an agent overload draft.<=
/div>
This the first part. Later on I will complete my review and send =
out the second portion of the comments.

1. se=
ction 1 (editorial) removed "is" before "feasible".

In the base specification,=
 the goal is to handle abatement of the
   overload occurrence as close to the source of the Diameter traffic as
   feasible.

"scenaios" ->=
; "scenarios"

The Peer overload report type is
   defined in a generic fashion so that it can also be used for other
   Diameter overload scenarios.

2. se=
ction 3.1.1 (editorial) replaced "were"-> "was"

In both of these cases, the=
 occurrence of overload in the single
   agent must by handled by the client in a similar fashion as if the
   client was handling the overload of a directly connected server.<=
/pre>

3. section 3.1.1 (question)

An appropriate error response is sent b=
ack to the originator
   of the request.
Who sends "an appropriate" err=
or response" in this case?

4. section 3.1.2 (=
editorial) changed "to"->"the"

<=
div>
When the client has an active and a standby =
connection to the two
   agents then an alternative strategy for responding to an overload
   report from an agent is to change the standby connection to activ=
e and
   route all traffic through the new active connection.
5. section 3.1.3 (editorial)

An example of this type of deployment includes whe=
n there are Diameter
   agents between administrative domains.
6. section 3.1.3<=
/div>

There is no section 2.2. I guess section 3.1.2 was=
 meant here, right?

Han=
dling of overload of one or both of agents a11 or a12 in this case
   is equivalent to that discussed in section 2.2.

7. section 3.2.1

It is not clear which usag=
e scenario is meant here.

   It is envisioned that abatement algorithms will be defined that will
   support the option for Diameter Endpoints to send peer reports.  For
   instance, it is envisioned that one usage scenario for the rate
   algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
   on by the DIME working group as this document is being written, will
   involve abatement being done on a hop-by-hop basis.

=

8. section 4

Why is throttling to be ap=
plied and not diversion (like in case of redundant agents)?=C2=A0

In this scenario the reacting no=
de should first handle the throttling of the
   overloaded host or realm.
"LOSS" Is it a new t=
ype defined in the scope of this draft?

Note: The goal is to avoid traffic oscillations that might=
 result
      from throttling of messages for both the HOST/REALM overload
      reports and the PEER overload reports.  This is especially a
      concern if both reports are of type LOSS.

=

9. section 5.1.1

Probably it is better =
to describe OC_PEER_REPORT feature in section 5.1?
Otherwise, it =
is used as a well-known one while it is the first place where it is mention=
ed.

Also I think it is better to add more specific=
 in this draft related to peer report handling:
- define Peer Rep=
ort Reacting Node and Peer Report Reporting Node terms explicitly and use t=
hem through the draft and especially starting from section 5.1=C2=A0
- add "Peer Report" prefix to all the described procedure=
s
Example: Capability Announcement -> Peer Report Capability A=
nnouncement

10. section 5.1.1/general
"DiameterIdentity" and "Diameter identity"=

My proposal is to use one term through the spec.

<=
/div>
Under "DOIC node", an agent is meant here?
 When an agent relays a request tha=
t includes a SourceID AVP in the
   OC-Supported-Features AVP, a DOIC node that supports the
   OC_PEER_REPORT feature MUST remove the received SourceID AVP and
   replace it with a SourceID AVP containing its own Diameter identity.

My proposal is to use peer report reacting node=
 here re-phrasing this statement below in the following way:
=

 When relaying a request that inc=
ludes a SourceID AVP in the
   OC-Supported-Features AVP, a peer report reacting node MUST remove the r=
eceived SourceID AVP and
   replace it with a SourceID AVP containing its own DiameterIdentity.
11. section 5.1.2

added the missed &qu=
ot;to"
changed "PEER_REPORT"-> "PEER"=


Note: The transaction =
state is used when the DOIC node is acting
      as a peer-report reporting node and needs to send OC-OLR repor=
ts of
      type PEER in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.

&q=
uot;Diameter ID" term is not clarified anywhere.
Re-phrased =
the appropriate statement a little bit, changed "Diameter ID"->=
;"value"
Also there are other places in the draft where=
 "Diameter ID" term is used.

The peer supports the OC_PEER_REPORT feature if the receiv=
ed request
   contains an OC-Supported-Features AVP with the OC-Feature-Vector with
   the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
   value that matches the DiameterIdentity of the peer from which
   the request was received.

Agent is meant =
under "reporting node" here?

Should not =
SourceID AVP not just stripped from the relayed answer, but replaced with t=
he SourceID AVP containing the DiameterIdentity of the agent supporting OC_=
PEER_REPORT feature?

Wh=
en an agent relays an answer message, a reporting node that
   supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
   the OC-Supported-Features AVP.

Hard to fo=
llow what was wanted to say here:
Corrected the statement, but th=
is is just my best guess.

The OC-Peer-Algo AVP MUST indicate the overload abatement
   algorithm that the reporting node wants the reacting nodes to use
   when the reporting node sends a peer overload report as a =
result of
   becoming overloaded.

Should not we add a =
separate if- statement for the case when the peer does not support OC_PEER_=
REPORT feature when sending an answer message?

12.=
 section 5.1.1 and 5.1.2

Probably it is more helpf=
ul to illustrate OC_PEER_REPORT feature CA using sequence diagrams like in =
the load info conveyance draft.

13. general.
=


What about to use the writing for the same terms throug=
h the spec?
Example1: "DOIC node" and "DOIC Node&q=
uot;
Example2: "peer-report reporting node" and "p=
eer report reporting node"

14. section 5.2.1.=
2, 5.2.2, 5.2.3 and general

"peer-type OCS&qu=
ot; and "peer report OCS" define the same term?
Why not=
 to use only one?

Another example: "peer =
report" and "peer report-type" and "report of type PEER=
"

15. section 5.2.3

<=
div>Probably it is better to re-phrase this statement a little bit + correc=
ted the misprints.

If a=
 peer report reacting node receives an OC-OLR AVP of type peer and t=
he
SourceID matches the DiameterIdentity of the peer from which the =
report
was received then the report was generated by the peer.
<=
div>
Similar comment + corrected misprints for the next state=
ment:

If a peer report =
reacting node receives an OC-OLR AVP of type peer and the
SourceID does not match the DiameterIdentity of the peer from which =
the
report was received then the reacting node MUST ignore the overload
report.

Also I think it is useful to us=
e one wording for the same term:
"Peer Report OLR", &qu=
ot;OC-OLR AVP", "OLR"
Let's use a generic one =
"peer report"?

Just minor comment:=
 "the existing..." and "a new overload condition" for a=
ll occurrences if my English is correct.

16. secti=
on 5.2.3

How may it happen that peer report reacti=
ng node receives a peer report not from the peer that generated it?
Peer reports can be sent only to peer report reacting node, right? And p=
eer reports are not relayed, right?

Best regards,<=
/div>

/Misha


2017-01-09 17:35 GMT+03:00 =
The IESG <iesg-secretary@ietf.org>:


The IESG has received a request from the Diameter Maintenance and

Extensions WG (dime) to consider the following document:

- 'Diameter Agent Overload and the Peer Overload Report'

=C2=A0 <draft-ietf-dime-agent-overload-08.txt> as Proposed Stand=
ard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailin=
g lists by 2017-01-23. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





=C2=A0 =C2=A0This specification documents an extension to RFC 7683 (Diamete=
r

=C2=A0 =C2=A0Overload Indication Conveyance (DOIC)) base solution.=C2=A0 Th=
e extension

=C2=A0 =C2=A0defines the Peer overload report type.=C2=A0 The initial use c=
ase for the

=C2=A0 =C2=A0Peer report is the handling of occurrences of overload of a Di=
ameter

=C2=A0 =C2=A0agent.



Requirements







The file can be obtained via

https://datatracker.ietf.org/do=
c/draft-ietf-dime-agent-overload/



IESG discussion can be tracked via

https://datatracker.ietf.org/=
doc/draft-ietf-dime-agent-overload/ballot/





No IPR declarations have been submitted directly on this I-D.





The document contains these normative downward references.

See RFC 3967 for additional information:

=C2=A0 =C2=A0 draft-roach-dime-overload-ctrl: A Mechanism for Diameter=
 Overload Control (None - )

Note that some of these references may already be listed in the acceptable =
Downref Registry.





_______________________________________________

DiME mailing list

DiME@ietf.org

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











--f403045ea2825643e70546725f81--


From nobody Thu Jan 19 10:47:15 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B77129477; Thu, 19 Jan 2017 10:47:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qmon2ohZ6qpK; Thu, 19 Jan 2017 10:47:12 -0800 (PST)
Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751F51293DB; Thu, 19 Jan 2017 10:47:11 -0800 (PST)
Received: by mail-lf0-x244.google.com with SMTP id x1so6434870lff.0; Thu, 19 Jan 2017 10:47:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/XrthfwKg71jYPrOlNWI+NuwdJrbIuEnfNgndB+D7n4=; b=XAQd/3qWsFN2HGx4mFS3NXfb3DFYGPq1z4OVdMIXCFHytAlFimvpCrdeS86LfJZ6nP AKgtVH+Kb6lPKeg/W7BveQtzqdA17GAvk7jvdveCY+GSg1qrGSM1+tR9GQiz6rfFWvld 4tNBv8rznvqk6RXWPeWrTFyL3ve2gAWbqE0Z/4nF7+9qg9lz/oynrdto7rvL61Oeo58x KYyGCAN537kWANixpoCw7uOb+hC/8o3O8aCArcumvsMpEs88+Ydo8fUkAHMsdux7Yyzn vVN4hnAHyt/oTAEvdkgyQmILWVwsFeH7CdtWxkCHZgnA+q8/RVt7ph0pEjZIJMnd4RkS smig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/XrthfwKg71jYPrOlNWI+NuwdJrbIuEnfNgndB+D7n4=; b=nxhwlcYH1d3SiKeRp7NtTkIvjmhpaRqQsU9MMku97cyh8fxp+5WtqtyWTbkvOVlXrP r3r3F+rpm/Pup4TcvNNUVEv1kAbtvPG88Vu1uBBASSDdS9sP5r6jDCP/RppZFx3HKosr Acqk2bH9vBKmKYYqkPfn6TM6DAQEIVDZ2zP+ST2kIm2QWyX6AutikgHXOf1bZx7k7gSp Mday7UtQMuQ1Cw7o82IZpYGdfl4gJI/YKAdQlwuUO4yHuphweTyUp0LnXPFapFfCiqQy JD1EGC0Ccu/2AQTxi6kayzMmyYiyR4m/1mYFqt3qqBT7YoLsY9vDOnzBOe1s/hgU+bEp 8Phg==
X-Gm-Message-State: AIkVDXLW1XnJ8QCT/g3Om7pXEiBgDTTIFzMelTWHvCSU8F0JG1bTxelQ1miqFvnUyt2BZFssb+XwGHk+f0SBiQ==
X-Received: by 10.46.1.153 with SMTP id f25mr4859916lji.47.1484851629409; Thu, 19 Jan 2017 10:47:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Thu, 19 Jan 2017 10:47:08 -0800 (PST)
In-Reply-To: 
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com>   
From: Misha Zaytsev 
Date: Thu, 19 Jan 2017 21:47:08 +0300
Message-ID: 
To: ietf@ietf.org
Content-Type: multipart/alternative; boundary=001a1142be3cea4b75054676f513
Archived-At: 
Cc: dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-agent-overload@ietf.org, IETF-Announce 
Subject: Re: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 18:47:14 -0000

--001a1142be3cea4b75054676f513
Content-Type: text/plain; charset=UTF-8

Hi All,

Just more minor comments from me to have all in place :)

28. section 6.4.

6.4.  Attribute Value Pair *F*lag *R*ules

29. section 7.1

7.1.  AVP *C*odes


30. section 7.2

7.2.  New *R*egistries


/Misha

2017-01-19 16:18 GMT+03:00 Misha Zaytsev :

> Hi All,
>
> Just several small comment from my side:
>
> 24. section 6.1.1. "OC-Feature-Vector" -> "OC-Feature-Vector AVP" in the
> header.
>
> 25. section 6.1.2 "OC-Peer-Algo" -> "OC-Peer-Algo AVP" in the header
>
> 26. section 6.2 corrected AVP names
>
> This extension makes no changes to the *OC-Sequence-Number* or
> *OC-Validity-Duration* AVPs in the OC-OLR AVP.
>
> 27. section 6.3
>
> Probably, it is the matter of preference, but I would still propose to
> rename SourceID to Source-Identity.
>
>
> Thanks in advance!
>
> /Misha
>
>
> 2017-01-18 21:40 GMT+03:00 Misha Zaytsev :
>
>> Hi All,
>>
>> As promised here is the second part of the comments (numbering is kept):
>>
>> 17. section 5.2.3, 5.2.4 (and further if applicable)
>>
>> Why not to use "active OCS" instead of "existing OCS" or "existing
>> overload conditions"?
>> Just to be inline with the RFC7683 this draft is extending...
>>
>> 18. section 5.2.4
>>
>> What is meant here? Especially "other overload reporting node behaviors".
>> For me it says about all and about nothing at the same time. Please
>> clarify
>>
>> The reporting agent must follow all other overload reporting node
>>    behaviors outlined in the DOIC specification.
>>
>>
>> 19. section 5.2.5
>>
>> Seems to be a little bit grammatically incorrect, "on" -> "to"
>>
>> If the request matches an active OCS then the reacting node MUST
>>    apply abatement treatment *to *the request.
>>
>> Maybe "error response" sounds better than just an "error" in this case:
>>
>> ... agent MUST send an appropriate error response as defined in [RFC7683].
>>
>> Seems to be wrongly phrased:
>>
>>  ... then *abatement *associated with the overload *abatement *MUST be ended in a
>>    controlled fashion.
>>
>>
>> 20. section 6
>>
>> I do not know why but I do not like the following wording:
>>
>> ... used as part of the CER/CEA base Diameter capabilities exchange.
>>
>>
>> Probably this version is better:
>>
>> ... used as part of the Diameter Capabilities Exchange procedure defined in [RFC6733].
>>
>>
>> 21. section 6.1.1
>>
>> The peer report feature defines a new feature bit *that (?)*is added for the OC-Feature-Vector AVP.
>>
>>
>> 22. section 6.2, similar to comment#16
>>
>> In the section 5.1.2 it says the following:
>>
>> When receiving a request a DOIC node that supports the OC_PEER_REPORT
>>    feature MUST update transaction state with *an indication of whether
>>    or not the peer from which the request was received supports the
>>    OC_PEER_REPORT feature.*
>>
>>       Note: The transaction state is used when the DOIC node is acting
>>       as a peer-report reporting node and needs send OC-OLR reports of
>>       type PEER_REPORT in answer messages.  The peer overload reports
>>       are only included in answer messages being sent to peers that
>>       support the OC_PEER_REPORT feature.
>>
>> So, my gut feeling is that it means that peer report can't be sent thru a
>> non-supporting agent???
>> If I'm wrong, please clarify that.
>>
>> Also, just several updates in wording + corrected misprints.
>>
>> The overload report MUST also include the Diameter identity of the
>>    agent that generated the report.  This is necessary to handle the
>>    case where there is a non*-*supporting agent between the reporting node
>>    and the reacting node.  Without the indication of the agent that
>>    generated the overload *report*, the reacting node could erroneously
>>    assume that the report applied to the non-supporting node.  This
>>    could, in turn, result in unnecessary traffic being either
>>    *diverged* or throttled.
>>
>>
>> 23. section 6.3 "SourceID" -> "SourceID AVP" in the section header.
>>
>> Seems to be all from my side, but probably I have still missed something.
>> Anyway, I'm ready to re-check the new version of the draft when available.
>>
>> Best regards,
>>
>> /Misha
>>
>> 2017-01-17 23:23 GMT+03:00 Misha Zaytsev :
>>
>>> Hi All,
>>>
>>> Here are my comments/questions to an agent overload draft.
>>> This the first part. Later on I will complete my review and send out the
>>> second portion of the comments.
>>>
>>> 1. section 1 (editorial) removed "is" before "feasible".
>>>
>>> In the base specification, the goal is to handle abatement of the
>>>    overload occurrence as close to the source of the Diameter traffic as
>>>    feasible.
>>>
>>>
>>> "scenaios" -> "scenarios"
>>>
>>> The Peer overload report type is
>>>    defined in a generic fashion so that it can also be used for other
>>>    Diameter overload *scenarios*.
>>>
>>>
>>> 2. section 3.1.1 (editorial) replaced "were"-> "was"
>>>
>>> In both of these cases, the occurrence of overload in the single
>>>    agent must by handled by the client in a similar fashion as if the
>>>    client *was* handling the overload of a directly connected server.
>>>
>>>
>>> 3. section 3.1.1 (question)
>>>
>>> An appropriate error response is sent back to the originator
>>>    of the request.
>>>
>>> Who sends "an appropriate" error response" in this case?
>>>
>>> 4. section 3.1.2 (editorial) changed "to"->"the"
>>>
>>> When the client has an active and a standby connection to the two
>>>    agents then an alternative strategy for responding to an overload
>>>    report from an agent is to change *the *standby connection to active and
>>>    route all traffic through the new active connection.
>>>
>>>
>>> 5. section 3.1.3 (editorial)
>>>
>>> An example of this type of deployment include*s* when there are Diameter
>>>    agents between administrative domains.
>>>
>>> 6. section 3.1.3
>>>
>>> There is no section 2.2. I guess section 3.1.2 was meant here, right?
>>>
>>> Handling of overload of one or both of agents a11 or a12 in this case
>>>    is equivalent to that discussed in section 2.2.
>>>
>>>
>>> 7. section 3.2.1
>>>
>>> It is not clear which usage scenario is meant here.
>>>
>>>    It is envisioned that abatement algorithms will be defined that will
>>>    support the option for Diameter Endpoints to send peer reports.  For
>>>    instance, it is envisioned that one usage scenario for the rate
>>>    algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
>>>    on by the DIME working group as this document is being written, will
>>>    involve abatement being done on a hop-by-hop basis.
>>>
>>>
>>> 8. section 4
>>>
>>> Why is throttling to be applied and not diversion (like in case of
>>> redundant agents)?
>>>
>>> In this scenario the reacting node should first handle the throttling of the
>>>    overloaded host or realm.
>>>
>>> "LOSS" Is it a new type defined in the scope of this draft?
>>>
>>> Note: The goal is to avoid traffic oscillations that might result
>>>       from throttling of messages for both the HOST/REALM overload
>>>       reports and the PEER overload reports.  This is especially a
>>>       concern if *both reports are of type LOSS*.
>>>
>>>
>>> 9. section 5.1.1
>>>
>>> Probably it is better to describe OC_PEER_REPORT feature in section 5.1?
>>> Otherwise, it is used as a well-known one while it is the first place
>>> where it is mentioned.
>>>
>>> Also I think it is better to add more specific in this draft related to
>>> peer report handling:
>>> - define Peer Report Reacting Node and Peer Report Reporting Node terms
>>> explicitly and use them through the draft and especially starting from
>>> section 5.1
>>> - add "Peer Report" prefix to all the described procedures
>>> Example: Capability Announcement -> Peer Report Capability Announcement
>>>
>>> 10. section 5.1.1/general
>>>
>>> "DiameterIdentity" and "Diameter identity"
>>> My proposal is to use one term through the spec.
>>>
>>> Under "DOIC node", an agent is meant here?
>>>
>>>  When an agent relays a request that includes a SourceID AVP in the
>>>    OC-Supported-Features AVP, a DOIC node that supports the
>>>    OC_PEER_REPORT feature MUST remove the received SourceID AVP and
>>>    replace it with a SourceID AVP containing its own Diameter identity.
>>>
>>>
>>> My proposal is to use peer report reacting node here re-phrasing this
>>> statement below in the following way:
>>>
>>>  When relaying a request that includes a SourceID AVP in the
>>>    OC-Supported-Features AVP, a peer report reacting node MUST remove the received SourceID AVP and
>>>    replace it with a SourceID AVP containing its own DiameterIdentity.
>>>
>>> 11. section 5.1.2
>>>
>>> added the missed "to"
>>> changed "PEER_REPORT"-> "PEER"
>>>
>>> Note: The transaction state is used when the DOIC node is acting
>>>       as a peer-report reporting node and needs *to *send OC-OLR reports of
>>>       type *PEER *in answer messages.  The peer overload reports
>>>       are only included in answer messages being sent to peers that
>>>       support the OC_PEER_REPORT feature.
>>>
>>>
>>> "Diameter ID" term is not clarified anywhere.
>>> Re-phrased the appropriate statement a little bit, changed "Diameter
>>> ID"->"value"
>>> Also there are other places in the draft where "Diameter ID" term is
>>> used.
>>>
>>> The peer supports the OC_PEER_REPORT feature if the received request
>>>    contains an OC-Supported-Features AVP with the OC-Feature-Vector with
>>>    the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
>>>    value that matches the DiameterIdentity of the peer from which
>>>    the request was received.
>>>
>>>
>>> Agent is meant under "reporting node" here?
>>>
>>> Should not SourceID AVP not just stripped from the relayed answer, but
>>> replaced with the SourceID AVP containing the DiameterIdentity of the agent
>>> supporting OC_PEER_REPORT feature?
>>>
>>> When an agent relays an answer message, a reporting node that
>>>    supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
>>>    the OC-Supported-Features AVP.
>>>
>>>
>>> Hard to follow what was wanted to say here:
>>> Corrected the statement, but this is just my best guess.
>>>
>>> The OC-Peer-Algo AVP MUST indicate the overload abatement
>>>    algorithm that the reporting node wants the reacting nodes to use
>>>    *when *the reporting node send*s* a peer overload report as a result of
>>>    becoming overloaded.
>>>
>>>
>>> Should not we add a separate if- statement for the case when the peer
>>> does not support OC_PEER_REPORT feature when sending an answer message?
>>>
>>> 12. section 5.1.1 and 5.1.2
>>>
>>> Probably it is more helpful to illustrate OC_PEER_REPORT feature CA
>>> using sequence diagrams like in the load info conveyance draft.
>>>
>>> 13. general.
>>>
>>> What about to use the writing for the same terms through the spec?
>>> Example1: "DOIC node" and "DOIC Node"
>>> Example2: "peer-report reporting node" and "peer report reporting node"
>>>
>>> 14. section 5.2.1.2, 5.2.2, 5.2.3 and general
>>>
>>> "peer-type OCS" and "peer report OCS" define the same term?
>>> Why not to use only one?
>>>
>>> Another example: "peer report" and "peer report-type" and "report of
>>> type PEER"
>>>
>>> 15. section 5.2.3
>>>
>>> Probably it is better to re-phrase this statement a little bit +
>>> corrected the misprints.
>>>
>>> If a *peer report* reacting node receives an OC-OLR AVP of type peer and the
>>> SourceID matches the *DiameterIdentity *of the peer from which the *report*
>>> was received then the report was *generated *by the peer.
>>>
>>>
>>> Similar comment + corrected misprints for the next statement:
>>>
>>> If a peer report reacting node receives an OC-OLR AVP of type peer and the
>>> SourceID does not match the *DiameterIdentity *of the peer from which the*report *was received then the reacting node MUST ignore the overload
>>> report.
>>>
>>>
>>> Also I think it is useful to use one wording for the same term:
>>> "Peer Report OLR", "OC-OLR AVP", "OLR"
>>> Let's use a generic one "peer report"?
>>>
>>> Just minor comment: "the existing..." and "a new overload condition" for
>>> all occurrences if my English is correct.
>>>
>>> 16. section 5.2.3
>>>
>>> How may it happen that peer report reacting node receives a peer report
>>> not from the peer that generated it?
>>> Peer reports can be sent only to peer report reacting node, right? And
>>> peer reports are not relayed, right?
>>>
>>> Best regards,
>>>
>>> /Misha
>>>
>>>
>>> 2017-01-09 17:35 GMT+03:00 The IESG :
>>>
>>>>
>>>> The IESG has received a request from the Diameter Maintenance and
>>>> Extensions WG (dime) to consider the following document:
>>>> - 'Diameter Agent Overload and the Peer Overload Report'
>>>>    as Proposed Standard
>>>>
>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>> final comments on this action. Please send substantive comments to the
>>>> ietf@ietf.org mailing lists by 2017-01-23. Exceptionally, comments may
>>>> be
>>>> sent to iesg@ietf.org instead. In either case, please retain the
>>>> beginning of the Subject line to allow automated sorting.
>>>>
>>>> Abstract
>>>>
>>>>
>>>>    This specification documents an extension to RFC 7683 (Diameter
>>>>    Overload Indication Conveyance (DOIC)) base solution.  The extension
>>>>    defines the Peer overload report type.  The initial use case for the
>>>>    Peer report is the handling of occurrences of overload of a Diameter
>>>>    agent.
>>>>
>>>> Requirements
>>>>
>>>>
>>>>
>>>> The file can be obtained via
>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/
>>>>
>>>> IESG discussion can be tracked via
>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot/
>>>>
>>>>
>>>> No IPR declarations have been submitted directly on this I-D.
>>>>
>>>>
>>>> The document contains these normative downward references.
>>>> See RFC 3967 for additional information:
>>>>     draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload
>>>> Control (None - )
>>>> Note that some of these references may already be listed in the
>>>> acceptable Downref Registry.
>>>>
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>
>>>
>>>
>>
>

--001a1142be3cea4b75054676f513
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi All,

Just more minor comments from m=
e to have all in place :)

28. section 6.4.

6.4.  Attribute Value Pair Flag R=
ules
29. section 7.1

7.1.  AVP Codes

30. sectio=
n 7.2

7.2.  New Registries=


/Misha

2017-01-19 16:18 GMT+03:00 Misha Zaytsev <=
span dir=3D"ltr"><misha.zaytsev.rus@gmail.com>:
Hi =
All,

Just several small comment from my side:

24.=
 section 6.1.1. "OC-Feature-Vector" -> "OC-Feature-Vector=
 AVP" in the header.

25. section 6.1.2 "OC-Peer-Algo=
" -> "OC-Peer-Algo AVP" in the header

26. se=
ction 6.2 corrected AVP names

This extension makes no changes to the=
 OC-Sequence-Number or   OC-Validity-Duration AVPs in the OC-=
OLR AVP.

27. section 6.3

Probably, it is the matt=
er of preference, but I would still propose to rename SourceID to Source-Id=
entity.


Thanks in advance!

/Misha


201=
7-01-18 21:40 GMT+03:00 Misha Zaytsev <misha.zaytsev.rus@gmail.c=
om>:
Hi Al=
l,

As promised here is the second part of the comments (=
numbering is kept):

17. section 5.2.3, 5.2.4 (and =
further if applicable)

Why not to use "active=
 OCS" instead of "existing OCS" or "existing overload c=
onditions"?
Just to be inline with the RFC7683 this draft is=
 extending...

18. section 5.2.4

What is meant here? Especially "other overload reporting node b=
ehaviors".
For me it says about all and about nothing at the=
 same time. Please clarify

The reporting agent must follow all other overload reporting node
   behaviors outlined in the DOIC specification.

=

19. section 5.2.5

Seems to be a little bit gr=
ammatically incorrect, "on" -> "to"

If the request matches an active OCS th=
en the reacting node MUST
   apply abatement treatment to the request.
Maybe &=
quot;error response" sounds better than just an "error" in t=
his case:

... agent MUS=
T send an appropriate error response as defined in [RFC7683].
Seems to be wrongly phrased:

 ... then abatement associated with the overload abateme=
nt MUST be ended in a
   controlled fashion.

20. section 6

I do not know why but I do not like the following wording=
:

... used as part of t=
he CER/CEA base Diameter capabilities exchange.

<=
div>Probably this version is better:

... used as part of the Diameter Capabilities Exchange proced=
ure defined in [RFC6733].

21. section 6.1.1=
=C2=A0

The peer report featu=
re defines a new feature bit that (?)is added for the=C2=A0OC-Featur=
e-Vector AVP.=C2=A0

22. section 6.2, similar to comment#16

In the section 5.1.2 it says the following:

=

When receiving a request a DOIC node that suppor=
ts the OC_PEER_REPORT
   feature MUST update transaction state with an indication of whether
   or not the peer from which the request was received supports the
   OC_PEER_REPORT feature.

      Note: The transaction state is used when the DOIC node is acting
      as a peer-report reporting node and needs send OC-OLR reports of
      type PEER_REPORT in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.
So, my gut feelin=
g is that it means that peer report can't be sent thru a non-supporting=
 agent???
If I'm wrong, please clarify that.

Also, just several updates in wording + corrected misprints.
=

The overload report MUST also inc=
lude the Diameter identity of the
   agent that generated the report.  This is necessary to handle the
   case where there is a non-supporting agent between the reporting =
node
   and the reacting node.  Without the indication of the agent that
   generated the overload report, the reacting node could erroneousl=
y
   assume that the report applied to the non-supporting node.  This
   could, in turn, result in unnecessary traffic being either
   diverged or =
throttled.

23. section 6.3 &qu=
ot;SourceID" -> "SourceID AVP" in the section header.

Seems to be all from my side, but probably I have sti=
ll missed something.
Anyway, I'm ready to re-check the new ve=
rsion of the draft when available.

Best regards,

/Misha
<=
br>
2017-01-17 23:23 GMT+03:00 Misha Zaytsev <misha.zaytsev.rus@gmail.com>:
Hi All,

Here are my comments=
/questions to an agent overload draft.
This the first part. Later=
 on I will complete my review and send out the second portion of the commen=
ts.

1. section 1 (editorial) removed "is=
" before "feasible".

In the base specification, the goal is to handle abatement of =
the
   overload occurrence as close to the source of the Diameter traffic as
   feasible.

"scenaios" ->=
; "scenarios"

The Peer overload report type is
   defined in a generic fashion so that it can also be used for other
   Diameter overload scenarios.

2. se=
ction 3.1.1 (editorial) replaced "were"-> "was"

In both of these cases, the=
 occurrence of overload in the single
   agent must by handled by the client in a similar fashion as if the
   client was handling the overload of a directly connected server.<=
/pre>

3. section 3.1.1 (question)

An appropriate error response is sent b=
ack to the originator
   of the request.
Who sends "an appropriate" err=
or response" in this case?

4. section 3.1.2 (=
editorial) changed "to"->"the"

<=
div>
When the client has an active and a standby =
connection to the two
   agents then an alternative strategy for responding to an overload
   report from an agent is to change the standby connection to activ=
e and
   route all traffic through the new active connection.
5. section 3.1.3 (editorial)

An example of this type of deployment includes whe=
n there are Diameter
   agents between administrative domains.
6. section 3.1.3<=
/div>

There is no section 2.2. I guess section 3.1.2 was=
 meant here, right?

Han=
dling of overload of one or both of agents a11 or a12 in this case
   is equivalent to that discussed in section 2.2.

7. section 3.2.1

It is not clear which usag=
e scenario is meant here.

   It is envisioned that abatement algorithms will be defined that will
   support the option for Diameter Endpoints to send peer reports.  For
   instance, it is envisioned that one usage scenario for the rate
   algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
   on by the DIME working group as this document is being written, will
   involve abatement being done on a hop-by-hop basis.

=

8. section 4

Why is throttling to be ap=
plied and not diversion (like in case of redundant agents)?=C2=A0

In this scenario the reacting no=
de should first handle the throttling of the
   overloaded host or realm.
"LOSS" Is it a new t=
ype defined in the scope of this draft?

Note: The goal is to avoid traffic oscillations that might=
 result
      from throttling of messages for both the HOST/REALM overload
      reports and the PEER overload reports.  This is especially a
      concern if both reports are of type LOSS.

=

9. section 5.1.1

Probably it is better =
to describe OC_PEER_REPORT feature in section 5.1?
Otherwise, it =
is used as a well-known one while it is the first place where it is mention=
ed.

Also I think it is better to add more specific=
 in this draft related to peer report handling:
- define Peer Rep=
ort Reacting Node and Peer Report Reporting Node terms explicitly and use t=
hem through the draft and especially starting from section 5.1=C2=A0
- add "Peer Report" prefix to all the described procedure=
s
Example: Capability Announcement -> Peer Report Capability A=
nnouncement

10. section 5.1.1/general
"DiameterIdentity" and "Diameter identity"=

My proposal is to use one term through the spec.

<=
/div>
Under "DOIC node", an agent is meant here?
 When an agent relays a request tha=
t includes a SourceID AVP in the
   OC-Supported-Features AVP, a DOIC node that supports the
   OC_PEER_REPORT feature MUST remove the received SourceID AVP and
   replace it with a SourceID AVP containing its own Diameter identity.

My proposal is to use peer report reacting node=
 here re-phrasing this statement below in the following way:
=

 When relaying a request that inc=
ludes a SourceID AVP in the
   OC-Supported-Features AVP, a peer report reacting node MUST remove the r=
eceived SourceID AVP and
   replace it with a SourceID AVP containing its own DiameterIdentity.
11. section 5.1.2

added the missed &qu=
ot;to"
changed "PEER_REPORT"-> "PEER"=


Note: The transaction =
state is used when the DOIC node is acting
      as a peer-report reporting node and needs to send OC-OLR repor=
ts of
      type PEER in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.

&q=
uot;Diameter ID" term is not clarified anywhere.
Re-phrased =
the appropriate statement a little bit, changed "Diameter ID"->=
;"value"
Also there are other places in the draft where=
 "Diameter ID" term is used.

The peer supports the OC_PEER_REPORT feature if the receiv=
ed request
   contains an OC-Supported-Features AVP with the OC-Feature-Vector with
   the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
   value that matches the DiameterIdentity of the peer from which
   the request was received.

Agent is meant =
under "reporting node" here?

Should not =
SourceID AVP not just stripped from the relayed answer, but replaced with t=
he SourceID AVP containing the DiameterIdentity of the agent supporting OC_=
PEER_REPORT feature?

Wh=
en an agent relays an answer message, a reporting node that
   supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
   the OC-Supported-Features AVP.

Hard to fo=
llow what was wanted to say here:
Corrected the statement, but th=
is is just my best guess.

The OC-Peer-Algo AVP MUST indicate the overload abatement
   algorithm that the reporting node wants the reacting nodes to use
   when the reporting node sends a peer overload report as a =
result of
   becoming overloaded.

Should not we add a =
separate if- statement for the case when the peer does not support OC_PEER_=
REPORT feature when sending an answer message?

12.=
 section 5.1.1 and 5.1.2

Probably it is more helpf=
ul to illustrate OC_PEER_REPORT feature CA using sequence diagrams like in =
the load info conveyance draft.

13. general.
=


What about to use the writing for the same terms throug=
h the spec?
Example1: "DOIC node" and "DOIC Node&q=
uot;
Example2: "peer-report reporting node" and "p=
eer report reporting node"

14. section 5.2.1.=
2, 5.2.2, 5.2.3 and general

"peer-type OCS&qu=
ot; and "peer report OCS" define the same term?
Why not=
 to use only one?

Another example: "peer =
report" and "peer report-type" and "report of type PEER=
"

15. section 5.2.3

<=
div>Probably it is better to re-phrase this statement a little bit + correc=
ted the misprints.

If a=
 peer report reacting node receives an OC-OLR AVP of type peer and t=
he
SourceID matches the DiameterIdentity of the peer from which the =
report
was received then the report was generated by the peer.
<=
div>
Similar comment + corrected misprints for the next state=
ment:

If a peer report =
reacting node receives an OC-OLR AVP of type peer and the
SourceID does not match the DiameterIdentity of the peer from which =
the
report was received then the reacting node MUST ignore the overload
report.

Also I think it is useful to us=
e one wording for the same term:
"Peer Report OLR", &qu=
ot;OC-OLR AVP", "OLR"
Let's use a generic one =
"peer report"?

Just minor comment:=
 "the existing..." and "a new overload condition" for a=
ll occurrences if my English is correct.

16. secti=
on 5.2.3

How may it happen that peer report reacti=
ng node receives a peer report not from the peer that generated it?
Peer reports can be sent only to peer report reacting node, right? And p=
eer reports are not relayed, right?

Best regards,<=
/div>

/Misha


2017-01-09 17:35 GMT+03:00 The IESG <iesg-secretary@iet=
f.org>:


The IESG has received a request from the Diameter Maintenance and

Extensions WG (dime) to consider the following document:

- 'Diameter Agent Overload and the Peer Overload Report'

=C2=A0 <draft-ietf-dime-agent-overload-08.txt> as Proposed Stand=
ard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailin=
g lists by 2017-01-23. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





=C2=A0 =C2=A0This specification documents an extension to RFC 7683 (Diamete=
r

=C2=A0 =C2=A0Overload Indication Conveyance (DOIC)) base solution.=C2=A0 Th=
e extension

=C2=A0 =C2=A0defines the Peer overload report type.=C2=A0 The initial use c=
ase for the

=C2=A0 =C2=A0Peer report is the handling of occurrences of overload of a Di=
ameter

=C2=A0 =C2=A0agent.



Requirements







The file can be obtained via

https://datatracker.ietf.org/do=
c/draft-ietf-dime-agent-overload/



IESG discussion can be tracked via

https://datatracker.ietf.org/=
doc/draft-ietf-dime-agent-overload/ballot/





No IPR declarations have been submitted directly on this I-D.





The document contains these normative downward references.

See RFC 3967 for additional information:

=C2=A0 =C2=A0 draft-roach-dime-overload-ctrl: A Mechanism for Diameter=
 Overload Control (None - )

Note that some of these references may already be listed in the acceptable =
Downref Registry.





_______________________________________________

DiME mailing list

DiME@ietf.org

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














--001a1142be3cea4b75054676f513--


From nobody Fri Jan 20 09:16:45 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E336C129490 for ; Fri, 20 Jan 2017 09:16:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 m1t0NF3cc1Ki for ; Fri, 20 Jan 2017 09:16:41 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 7CB16126B6D for ; Fri, 20 Jan 2017 09:16:41 -0800 (PST)
Received: from [67.139.165.143] (port=62869 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cUcni-003MYm-5a; Fri, 20 Jan 2017 09:16:41 -0800
To: Misha Zaytsev , dime@ietf.org
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com> 
From: Steve Donovan 
Message-ID: <1ccf026a-ba8d-ca26-f258-47cc78b49a1f@usdonovans.com>
Date: Fri, 20 Jan 2017 09:16:33 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B464943CB6BE9BAB3E42BA76"
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 17:16:43 -0000

This is a multi-part message in MIME format.
--------------B464943CB6BE9BAB3E42BA76
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Misha,

Thanks for the detailed review.

In the future this type of message only needs to go to the DIME mailing 
list.

I will deal with all of your comments in one email.

Regards,

Steve

On 1/17/17 12:23 PM, Misha Zaytsev wrote:
> Hi All,
>
> Here are my comments/questions to an agent overload draft.
> This the first part. Later on I will complete my review and send out 
> the second portion of the comments.
>
> 1. section 1 (editorial) removed "is" before "feasible".
>
> In the base specification, the goal is to handle abatement of the
>     overload occurrence as close to the source of the Diameter traffic as
>     feasible.
>
> "scenaios" -> "scenarios"
>
> The Peer overload report type is
>     defined in a generic fashion so that it can also be used for other
>     Diameter overload*scenarios*.
>
> 2. section 3.1.1 (editorial) replaced "were"-> "was"
>
> In both of these cases, the occurrence of overload in the single
>     agent must by handled by the client in a similar fashion as if the
>     client*was*  handling the overload of a directly connected server.
>
> 3. section 3.1.1 (question)
>
> An appropriate error response is sent back to the originator
>     of the request.
> Who sends "an appropriate" error response" in this case?
>
> 4. section 3.1.2 (editorial) changed "to"->"the"
>
> When the client has an active and a standby connection to the two
>     agents then an alternative strategy for responding to an overload
>     report from an agent is to change*the *standby connection to active and
>     route all traffic through the new active connection.
>
> 5. section 3.1.3 (editorial)
>
> An example of this type of deployment include*s*  when there are Diameter
>     agents between administrative domains.
> 6. section 3.1.3
>
> There is no section 2.2. I guess section 3.1.2 was meant here, right?
>
> Handling of overload of one or both of agents a11 or a12 in this case
>     is equivalent to that discussed in section 2.2.
>
> 7. section 3.2.1
>
> It is not clear which usage scenario is meant here.
>
>     It is envisioned that abatement algorithms will be defined that will
>     support the option for Diameter Endpoints to send peer reports.  For
>     instance, it is envisioned that one usage scenario for the rate
>     algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
>     on by the DIME working group as this document is being written, will
>     involve abatement being done on a hop-by-hop basis.
> 8. section 4
> Why is throttling to be applied and not diversion (like in case of 
> redundant agents)?
> In this scenario the reacting node should first handle the throttling of the
>     overloaded host or realm.
> "LOSS" Is it a new type defined in the scope of this draft?
> Note: The goal is to avoid traffic oscillations that might result
>        from throttling of messages for both the HOST/REALM overload
>        reports and the PEER overload reports.  This is especially a
>        concern if*both reports are of type LOSS*.
> 9. section 5.1.1
> Probably it is better to describe OC_PEER_REPORT feature in section 5.1?
> Otherwise, it is used as a well-known one while it is the first place 
> where it is mentioned.
> Also I think it is better to add more specific in this draft related 
> to peer report handling:
> - define Peer Report Reacting Node and Peer Report Reporting Node 
> terms explicitly and use them through the draft and especially 
> starting from section 5.1
> - add "Peer Report" prefix to all the described procedures
> Example: Capability Announcement -> Peer Report Capability Announcement
> 10. section 5.1.1/general
> "DiameterIdentity" and "Diameter identity"
> My proposal is to use one term through the spec.
> Under "DOIC node", an agent is meant here?
>   When an agent relays a request that includes a SourceID AVP in the
>     OC-Supported-Features AVP, a DOIC node that supports the
>     OC_PEER_REPORT feature MUST remove the received SourceID AVP and
>     replace it with a SourceID AVP containing its own Diameter identity.
> My proposal is to use peer report reacting node here re-phrasing this 
> statement below in the following way:
>   When relaying a request that includes a SourceID AVP in the
>     OC-Supported-Features AVP, a peer report reacting node MUST remove the received SourceID AVP and
>     replace it with a SourceID AVP containing its own DiameterIdentity.
> 11. section 5.1.2
> added the missed "to"
> changed "PEER_REPORT"-> "PEER"
> Note: The transaction state is used when the DOIC node is acting
>        as a peer-report reporting node and needs*to *send OC-OLR reports of
>        type*PEER *in answer messages.  The peer overload reports
>        are only included in answer messages being sent to peers that
>        support the OC_PEER_REPORT feature.
> "Diameter ID" term is not clarified anywhere.
> Re-phrased the appropriate statement a little bit, changed "Diameter 
> ID"->"value"
> Also there are other places in the draft where "Diameter ID" term is used.
> The peer supports the OC_PEER_REPORT feature if the received request
>     contains an OC-Supported-Features AVP with the OC-Feature-Vector with
>     the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
>     value that matches the DiameterIdentity of the peer from which
>     the request was received.
> Agent is meant under "reporting node" here?
> Should not SourceID AVP not just stripped from the relayed answer, but 
> replaced with the SourceID AVP containing the DiameterIdentity of the 
> agent supporting OC_PEER_REPORT feature?
> When an agent relays an answer message, a reporting node that
>     supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
>     the OC-Supported-Features AVP.
> Hard to follow what was wanted to say here:
> Corrected the statement, but this is just my best guess.
> The OC-Peer-Algo AVP MUST indicate the overload abatement
>     algorithm that the reporting node wants the reacting nodes to use
>     *when *the reporting node send*s*  a peer overload report as a result of
>     becoming overloaded.
> Should not we add a separate if- statement for the case when the peer 
> does not support OC_PEER_REPORT feature when sending an answer message?
> 12. section 5.1.1 and 5.1.2
> Probably it is more helpful to illustrate OC_PEER_REPORT feature CA 
> using sequence diagrams like in the load info conveyance draft.
> 13. general.
> What about to use the writing for the same terms through the spec?
> Example1: "DOIC node" and "DOIC Node"
> Example2: "peer-report reporting node" and "peer report reporting node"
> 14. section 5.2.1.2, 5.2.2, 5.2.3 and general
> "peer-type OCS" and "peer report OCS" define the same term?
> Why not to use only one?
> Another example: "peer report" and "peer report-type" and "report of 
> type PEER"
> 15. section 5.2.3
> Probably it is better to re-phrase this statement a little bit + 
> corrected the misprints.
> If a*peer report*  reacting node receives an OC-OLR AVP of type peer and the
> SourceID matches the*DiameterIdentity *of the peer from which the*report*
> was received then the report was*generated *by the peer.
> Similar comment + corrected misprints for the next statement:
> If a peer report reacting node receives an OC-OLR AVP of type peer and the
> SourceID does not match the*DiameterIdentity *of the peer from which the
> *report *was received then the reacting node MUST ignore the overload
> report.
> Also I think it is useful to use one wording for the same term:
> "Peer Report OLR", "OC-OLR AVP", "OLR"
> Let's use a generic one "peer report"?
> Just minor comment: "the existing..." and "a new overload condition" 
> for all occurrences if my English is correct.
> 16. section 5.2.3
> How may it happen that peer report reacting node receives a peer 
> report not from the peer that generated it?
> Peer reports can be sent only to peer report reacting node, right? And 
> peer reports are not relayed, right?
> Best regards,
> /Misha
> 2017-01-09 17:35 GMT+03:00 The IESG  >:
>
>     The IESG has received a request from the Diameter Maintenance and
>     Extensions WG (dime) to consider the following document: -
>     'Diameter Agent Overload and the Peer Overload Report'  
>      as Proposed Standard The
>     IESG plans to make a decision in the next few weeks, and solicits
>     final comments on this action. Please send substantive comments to
>     the ietf@ietf.org  mailing lists by
>     2017-01-23. Exceptionally, comments may be sent to iesg@ietf.org
>      instead. In either case, please retain the
>     beginning of the Subject line to allow automated sorting. Abstract
>        This specification documents an extension to RFC 7683 (Diameter
>        Overload Indication Conveyance (DOIC)) base solution.  The
>     extension    defines the Peer overload report type.  The initial
>     use case for the    Peer report is the handling of occurrences of
>     overload of a Diameter    agent. Requirements The file can be
>     obtained via
>     https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/
>     
>     IESG discussion can be tracked via
>     https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot/
>     
>     No IPR declarations have been submitted directly on this I-D. The
>     document contains these normative downward references. See RFC
>     3967 for additional information:    
>     draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload
>     Control (None - ) Note that some of these references may already
>     be listed in the acceptable Downref Registry.
>     _______________________________________________ DiME mailing list
>     DiME@ietf.org 
>     https://www.ietf.org/mailman/listinfo/dime
>      
>

--------------B464943CB6BE9BAB3E42BA76
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Misha,

    

    Thanks for the detailed review.  

    

    In the future this type of message only needs to go to the DIME
    mailing list.

    

    I will deal with all of your comments in one email.

    

    Regards,

    

    Steve

    

    
On 1/17/17 12:23 PM, Misha Zaytsev
      wrote:

    

    

      
Hi All,
        


        

        
Here are my comments/questions to an agent overload draft.

        
This the first part. Later on I will complete my review and
          send out the second portion of the comments.

        


        

        

          
1. section 1 (editorial) removed "is" before "feasible".

          


          

          

            
In the base specification, the goal is to handle abatement of the
   overload occurrence as close to the source of the Diameter traffic as
   feasible.

          

        

        


        

        
"scenaios" -> "scenarios"

        


        

        

          
The Peer overload report type is
   defined in a generic fashion so that it can also be used for other
   Diameter overload scenarios.

        

        


        

        
2. section 3.1.1 (editorial) replaced "were"-> "was"

        


        

        

          
In both of these cases, the occurrence of overload in the single
   agent must by handled by the client in a similar fashion as if the
   client was handling the overload of a directly connected server.

        

        


        

        
3. section 3.1.1 (question)

        


        

        

          
An appropriate error response is sent back to the originator
   of the request.

        

        
Who sends "an appropriate" error response" in this case?

        


        

        
4. section 3.1.2 (editorial) changed "to"->"the"

        


        

        

          
When the client has an active and a standby connection to the two
   agents then an alternative strategy for responding to an overload
   report from an agent is to change the standby connection to active and
   route all traffic through the new active connection.

        

        


        

        
5. section 3.1.3 (editorial)

        


        

        

          
An example of this type of deployment includes when there are Diameter
   agents between administrative domains.

        

        
6. section 3.1.3

        


        

        
There is no section 2.2. I guess section 3.1.2 was meant
          here, right?

        


        

        

          
Handling of overload of one or both of agents a11 or a12 in this case
   is equivalent to that discussed in section 2.2.

        

        


        

        
7. section 3.2.1

        


        

        
It is not clear which usage scenario is meant here.

        


        

        

          
   It is envisioned that abatement algorithms will be defined that will
   support the option for Diameter Endpoints to send peer reports.  For
   instance, it is envisioned that one usage scenario for the rate
   algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
   on by the DIME working group as this document is being written, will
   involve abatement being done on a hop-by-hop basis.


8. section 4


Why is throttling to be applied and not diversion (like in case of redundant agents)? 


In this scenario the reacting node should first handle the throttling of the
   overloaded host or realm.
"LOSS" Is it a new type defined in the scope of this draft?


Note: The goal is to avoid traffic oscillations that might result
      from throttling of messages for both the HOST/REALM overload
      reports and the PEER overload reports.  This is especially a
      concern if both reports are of type LOSS.


9. section 5.1.1


Probably it is better to describe OC_PEER_REPORT feature in section 5.1?
Otherwise, it is used as a well-known one while it is the first place where it is mentioned.


Also I think it is better to add more specific in this draft related to peer report handling:
- define Peer Report Reacting Node and Peer Report Reporting Node terms explicitly and use them through the draft and especially starting from section 5.1 

- add "Peer Report" prefix to all the described procedures
Example: Capability Announcement -> Peer Report Capability Announcement


10. section 5.1.1/general


"DiameterIdentity" and "Diameter identity"
My proposal is to use one term through the spec.


Under "DOIC node", an agent is meant here?


 When an agent relays a request that includes a SourceID AVP in the
   OC-Supported-Features AVP, a DOIC node that supports the
   OC_PEER_REPORT feature MUST remove the received SourceID AVP and
   replace it with a SourceID AVP containing its own Diameter identity.


My proposal is to use peer report reacting node here re-phrasing this statement below in the following way:



 When relaying a request that includes a SourceID AVP in the
   OC-Supported-Features AVP, a peer report reacting node MUST remove the received SourceID AVP and
   replace it with a SourceID AVP containing its own DiameterIdentity.
11. section 5.1.2


added the missed "to"
changed "PEER_REPORT"-> "PEER"


Note: The transaction state is used when the DOIC node is acting
      as a peer-report reporting node and needs to send OC-OLR reports of
      type PEER in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.


"Diameter ID" term is not clarified anywhere.
Re-phrased the appropriate statement a little bit, changed "Diameter ID"->"value"
Also there are other places in the draft where "Diameter ID" term is used.


The peer supports the OC_PEER_REPORT feature if the received request
   contains an OC-Supported-Features AVP with the OC-Feature-Vector with
   the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
   value that matches the DiameterIdentity of the peer from which
   the request was received.


Agent is meant under "reporting node" here?


Should not SourceID AVP not just stripped from the relayed answer, but replaced with the SourceID AVP containing the DiameterIdentity of the agent supporting OC_PEER_REPORT feature?


When an agent relays an answer message, a reporting node that
   supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
   the OC-Supported-Features AVP.


Hard to follow what was wanted to say here:
Corrected the statement, but this is just my best guess.


The OC-Peer-Algo AVP MUST indicate the overload abatement
   algorithm that the reporting node wants the reacting nodes to use
   when the reporting node sends a peer overload report as a result of
   becoming overloaded.


Should not we add a separate if- statement for the case when the peer does not support OC_PEER_REPORT feature when sending an answer message?


12. section 5.1.1 and 5.1.2


Probably it is more helpful to illustrate OC_PEER_REPORT feature CA using sequence diagrams like in the load info conveyance draft.


13. general.


What about to use the writing for the same terms through the spec?
Example1: "DOIC node" and "DOIC Node"
Example2: "peer-report reporting node" and "peer report reporting node"


14. section 5.2.1.2, 5.2.2, 5.2.3 and general


"peer-type OCS" and "peer report OCS" define the same term?
Why not to use only one?



Another example: "peer report" and "peer report-type" and "report of type PEER"



15. section 5.2.3


Probably it is better to re-phrase this statement a little bit + corrected the misprints.


If a peer report reacting node receives an OC-OLR AVP of type peer and the
SourceID matches the DiameterIdentity of the peer from which the report
was received then the report was generated by the peer.


Similar comment + corrected misprints for the next statement:


If a peer report reacting node receives an OC-OLR AVP of type peer and the
SourceID does not match the DiameterIdentity of the peer from which the
report was received then the reacting node MUST ignore the overload
report.


Also I think it is useful to use one wording for the same term:
"Peer Report OLR", "OC-OLR AVP", "OLR"
Let's use a generic one "peer report"?


Just minor comment: "the existing..." and "a new overload condition" for all occurrences if my English is correct.


16. section 5.2.3


How may it happen that peer report reacting node receives a peer report not from the peer that generated it?
Peer reports can be sent only to peer report reacting node, right? And peer reports are not relayed, right?


Best regards,


/Misha




2017-01-09 17:35 GMT+03:00 The IESG <iesg-secretary@ietf.org>:



The IESG has received a request from the Diameter Maintenance and

Extensions WG (dime) to consider the following document:

- 'Diameter Agent Overload and the Peer Overload Report'

  <draft-ietf-dime-agent-overload-08.txt> as Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2017-01-23. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





   This specification documents an extension to RFC 7683 (Diameter

   Overload Indication Conveyance (DOIC)) base solution.  The extension

   defines the Peer overload report type.  The initial use case for the

   Peer report is the handling of occurrences of overload of a Diameter

   agent.



Requirements







The file can be obtained via

https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/



IESG discussion can be tracked via

https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot/





No IPR declarations have been submitted directly on this I-D.





The document contains these normative downward references.

See RFC 3967 for additional information:

    draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload Control (None - )

Note that some of these references may already be listed in the acceptable Downref Registry.





_______________________________________________

DiME mailing list

DiME@ietf.org

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











--------------B464943CB6BE9BAB3E42BA76--


From nobody Fri Jan 20 09:51:11 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C7312966C for ; Fri, 20 Jan 2017 09:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRMe_ZgFMqEj for ; Fri, 20 Jan 2017 09:51:05 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B1D127076 for ; Fri, 20 Jan 2017 09:51:05 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id v186so62653574lfa.1 for ; Fri, 20 Jan 2017 09:51:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fYDXchFbdM+fG4+jUd/j51RWrEuKLetTOK6C/7JKVQ4=; b=jsYYYQOOyA+nyYwPheNV8F56u4N4PnZ+AcGbQES+zd85QbEZ7NYxSK+y745zMPHfIv +UnBJM8GlNa0mvtGpBfI/d9h6zFzKrJ6gDpIX1aA7O2KaC8j/VlVyc5GfxBJO7ktFdaT 6pofAVcq3gsN0MBxDIK9xpJNMUpfalohMZAvp9BEUTjaNXsHWpI2UZlHLFJxFqQWwgF7 FApqc3H8zbhLnkyfPd/0MrGNCSrsyVw+dkMsi15OK+8TW8MPedpZt8AcY6CEawd1Ck+S wrzb+a07MUuq1IMQYcJUT7M51v6ihCesQ59s1uWUv3ny8azJpQNdEMYiYXQE5GhrNS8F V34A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fYDXchFbdM+fG4+jUd/j51RWrEuKLetTOK6C/7JKVQ4=; b=R6gGD8KtVy2agj9uMeJHXjBIqRj4cFJDXSm26Y54L9LizSG7xxz/b56pOGDfL9LoPE L/ahUGSeWqCEYMLK3i8YtzGZhXD8uEvO4mOTdVbIDUWZTW+Y3qp0PU1jAETSv5XdmLMI O3HtLa5IkWNm+aeq01q9V63e05iSEq7TUPwXI1eKPGMnn/ibvbIfRMTVD3xZnxD9df/5 RXHGYnnQUEWcn4N1qZw/k3ePpSo2bxcTmRSO6PCBo5zHnT6g7wOL3Th0ge11jnEHM8W9 uMkDA5mOKLjK1Mt/hqlaxITwvTp/nOJYlEyqZf2I5LVIGocZ+Qxn2GfoH44EbG0Yj+a8 oGLg==
X-Gm-Message-State: AIkVDXIBfl9qFATk9B+GfCiDaMBSKq89uTsqGp4CWKZmBpM531u6F9cvbXXxzn8fTy8SeicLUTkuy9fa1clHjw==
X-Received: by 10.25.20.152 with SMTP id 24mr4641409lfu.152.1484934663195; Fri, 20 Jan 2017 09:51:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Fri, 20 Jan 2017 09:51:02 -0800 (PST)
In-Reply-To: <1ccf026a-ba8d-ca26-f258-47cc78b49a1f@usdonovans.com>
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com>  <1ccf026a-ba8d-ca26-f258-47cc78b49a1f@usdonovans.com>
From: Misha Zaytsev 
Date: Fri, 20 Jan 2017 20:51:02 +0300
Message-ID: 
To: Steve Donovan 
Content-Type: multipart/alternative; boundary=001a113fb1721d52f005468a4b3f
Archived-At: 
Cc: dime@ietf.org
Subject: Re: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 17:51:10 -0000

--001a113fb1721d52f005468a4b3f
Content-Type: text/plain; charset=UTF-8

Hi Steve,

OK, thanks for the note! Next time I will use only DIME mailing list.
Let's hope no one suffered much from my "spam" :)

Will be waiting for your answers.
And as I said in one of my mails, I'm ready to re-check the draft when new
version is available.

/Misha



2017-01-20 20:16 GMT+03:00 Steve Donovan :

> Misha,
>
> Thanks for the detailed review.
>
> In the future this type of message only needs to go to the DIME mailing
> list.
>
> I will deal with all of your comments in one email.
>
> Regards,
>
> Steve
>
>
> On 1/17/17 12:23 PM, Misha Zaytsev wrote:
>
> Hi All,
>
> Here are my comments/questions to an agent overload draft.
> This the first part. Later on I will complete my review and send out the
> second portion of the comments.
>
> 1. section 1 (editorial) removed "is" before "feasible".
>
> In the base specification, the goal is to handle abatement of the
>    overload occurrence as close to the source of the Diameter traffic as
>    feasible.
>
>
> "scenaios" -> "scenarios"
>
> The Peer overload report type is
>    defined in a generic fashion so that it can also be used for other
>    Diameter overload *scenarios*.
>
>
> 2. section 3.1.1 (editorial) replaced "were"-> "was"
>
> In both of these cases, the occurrence of overload in the single
>    agent must by handled by the client in a similar fashion as if the
>    client *was* handling the overload of a directly connected server.
>
>
> 3. section 3.1.1 (question)
>
> An appropriate error response is sent back to the originator
>    of the request.
>
> Who sends "an appropriate" error response" in this case?
>
> 4. section 3.1.2 (editorial) changed "to"->"the"
>
> When the client has an active and a standby connection to the two
>    agents then an alternative strategy for responding to an overload
>    report from an agent is to change *the *standby connection to active and
>    route all traffic through the new active connection.
>
>
> 5. section 3.1.3 (editorial)
>
> An example of this type of deployment include*s* when there are Diameter
>    agents between administrative domains.
>
> 6. section 3.1.3
>
> There is no section 2.2. I guess section 3.1.2 was meant here, right?
>
> Handling of overload of one or both of agents a11 or a12 in this case
>    is equivalent to that discussed in section 2.2.
>
>
> 7. section 3.2.1
>
> It is not clear which usage scenario is meant here.
>
>    It is envisioned that abatement algorithms will be defined that will
>    support the option for Diameter Endpoints to send peer reports.  For
>    instance, it is envisioned that one usage scenario for the rate
>    algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
>    on by the DIME working group as this document is being written, will
>    involve abatement being done on a hop-by-hop basis.
>
> 8. section 4
> Why is throttling to be applied and not diversion (like in case of
> redundant agents)?
>
> In this scenario the reacting node should first handle the throttling of the
>    overloaded host or realm.
>
> "LOSS" Is it a new type defined in the scope of this draft?
>
> Note: The goal is to avoid traffic oscillations that might result
>       from throttling of messages for both the HOST/REALM overload
>       reports and the PEER overload reports.  This is especially a
>       concern if *both reports are of type LOSS*.
>
> 9. section 5.1.1
> Probably it is better to describe OC_PEER_REPORT feature in section 5.1?
> Otherwise, it is used as a well-known one while it is the first place
> where it is mentioned.
> Also I think it is better to add more specific in this draft related to
> peer report handling:
> - define Peer Report Reacting Node and Peer Report Reporting Node terms
> explicitly and use them through the draft and especially starting from
> section 5.1
> - add "Peer Report" prefix to all the described procedures
> Example: Capability Announcement -> Peer Report Capability Announcement
> 10. section 5.1.1/general
> "DiameterIdentity" and "Diameter identity"
> My proposal is to use one term through the spec.
> Under "DOIC node", an agent is meant here?
>
>  When an agent relays a request that includes a SourceID AVP in the
>    OC-Supported-Features AVP, a DOIC node that supports the
>    OC_PEER_REPORT feature MUST remove the received SourceID AVP and
>    replace it with a SourceID AVP containing its own Diameter identity.
>
> My proposal is to use peer report reacting node here re-phrasing this
> statement below in the following way:
>
>  When relaying a request that includes a SourceID AVP in the
>    OC-Supported-Features AVP, a peer report reacting node MUST remove the received SourceID AVP and
>    replace it with a SourceID AVP containing its own DiameterIdentity.
>
> 11. section 5.1.2
> added the missed "to"
> changed "PEER_REPORT"-> "PEER"
>
> Note: The transaction state is used when the DOIC node is acting
>       as a peer-report reporting node and needs *to *send OC-OLR reports of
>       type *PEER *in answer messages.  The peer overload reports
>       are only included in answer messages being sent to peers that
>       support the OC_PEER_REPORT feature.
>
> "Diameter ID" term is not clarified anywhere.
> Re-phrased the appropriate statement a little bit, changed "Diameter
> ID"->"value"
> Also there are other places in the draft where "Diameter ID" term is used.
>
> The peer supports the OC_PEER_REPORT feature if the received request
>    contains an OC-Supported-Features AVP with the OC-Feature-Vector with
>    the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
>    value that matches the DiameterIdentity of the peer from which
>    the request was received.
>
> Agent is meant under "reporting node" here?
> Should not SourceID AVP not just stripped from the relayed answer, but
> replaced with the SourceID AVP containing the DiameterIdentity of the agent
> supporting OC_PEER_REPORT feature?
>
> When an agent relays an answer message, a reporting node that
>    supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
>    the OC-Supported-Features AVP.
>
> Hard to follow what was wanted to say here:
> Corrected the statement, but this is just my best guess.
>
> The OC-Peer-Algo AVP MUST indicate the overload abatement
>    algorithm that the reporting node wants the reacting nodes to use
>    *when *the reporting node send*s* a peer overload report as a result of
>    becoming overloaded.
>
> Should not we add a separate if- statement for the case when the peer does
> not support OC_PEER_REPORT feature when sending an answer message?
> 12. section 5.1.1 and 5.1.2
> Probably it is more helpful to illustrate OC_PEER_REPORT feature CA using
> sequence diagrams like in the load info conveyance draft.
> 13. general.
> What about to use the writing for the same terms through the spec?
> Example1: "DOIC node" and "DOIC Node"
> Example2: "peer-report reporting node" and "peer report reporting node"
> 14. section 5.2.1.2, 5.2.2, 5.2.3 and general
> "peer-type OCS" and "peer report OCS" define the same term?
> Why not to use only one?
> Another example: "peer report" and "peer report-type" and "report of type
> PEER"
> 15. section 5.2.3
> Probably it is better to re-phrase this statement a little bit + corrected
> the misprints.
>
> If a *peer report* reacting node receives an OC-OLR AVP of type peer and the
> SourceID matches the *DiameterIdentity *of the peer from which the *report*
> was received then the report was *generated *by the peer.
>
> Similar comment + corrected misprints for the next statement:
>
> If a peer report reacting node receives an OC-OLR AVP of type peer and the
> SourceID does not match the *DiameterIdentity *of the peer from which the*report *was received then the reacting node MUST ignore the overload
> report.
>
> Also I think it is useful to use one wording for the same term:
> "Peer Report OLR", "OC-OLR AVP", "OLR"
> Let's use a generic one "peer report"?
> Just minor comment: "the existing..." and "a new overload condition" for
> all occurrences if my English is correct.
> 16. section 5.2.3
> How may it happen that peer report reacting node receives a peer report
> not from the peer that generated it?
> Peer reports can be sent only to peer report reacting node, right? And
> peer reports are not relayed, right?
> Best regards,
> /Misha
> 2017-01-09 17:35 GMT+03:00 The IESG :
>>
>> The IESG has received a request from the Diameter Maintenance and
>> Extensions WG (dime) to consider the following document: - 'Diameter Agent
>> Overload and the Peer Overload Report'   
>> as Proposed Standard The IESG plans to make a decision in the next few
>> weeks, and solicits final comments on this action. Please send substantive
>> comments to the ietf@ietf.org mailing lists by 2017-01-23.
>> Exceptionally, comments may be sent to iesg@ietf.org instead. In either
>> case, please retain the beginning of the Subject line to allow automated
>> sorting. Abstract    This specification documents an extension to RFC 7683
>> (Diameter    Overload Indication Conveyance (DOIC)) base solution.  The
>> extension    defines the Peer overload report type.  The initial use case
>> for the    Peer report is the handling of occurrences of overload of a
>> Diameter    agent. Requirements The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ IESG
>> discussion can be tracked via https://datatracker.ietf.org/d
>> oc/draft-ietf-dime-agent-overload/ballot/ No IPR declarations have been
>> submitted directly on this I-D. The document contains these normative
>> downward references. See RFC 3967 for additional information:
>> draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload
>> Control (None - ) Note that some of these references may already be listed
>> in the acceptable Downref Registry. _______________________________________________
>> DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/l
>> istinfo/dime
>
>

--001a113fb1721d52f005468a4b3f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Steve,

OK, thanks for the note! Next=
 time I will use only DIME mailing list.
Let's hope no one su=
ffered much from my "spam" :)

Will be wa=
iting for your answers.
And as I said in one of my mails, I'm=
 ready to re-check the draft when new version is available.

<=
/div>
/Misha



2017-01-20 20:16 GMT+03:00 Steve D=
onovan <srdonovan@usdonovans.com>:

 =20
   =20
 =20
  

    Misha,

    

    Thanks for the detailed review.=C2=A0 

    

    In the future this type of message only needs to go to the DIME
    mailing list.

    

    I will deal with all of your comments in one email.

    

    Regards,

    

    Steve


    

    
On 1/17/17 12:23 P=
M, Misha Zaytsev
      wrote:

    

    

      
Hi All,
        


        

        
Here are my comments/questions to an agent overload draft.
        
This the first part. Later on I will complete my review and
          send out the second portion of the comments.

        


        

        

          
1. section 1 (editorial) removed "is" before "=
;feasible".

          


          

          

            
In the base specification, the goal =
is to handle abatement of the
   overload occurrence as close to the source of the Diameter traffic as
   feasible.

          

        

        


        

        
"scenaios" -> "scenarios"

        


        

        

          
The Peer overload report type is
   defined in a generic fashion so that it can also be used for other
   Diameter overload scenarios.

        

        


        

        
2. section 3.1.1 (editorial) replaced "were"-> &q=
uot;was"

        


        

        

          
In both of these cases, the occurrence=
 of overload in the single
   agent must by handled by the client in a similar fashion as if the
   client was handling the overload of a directly connected server.<=
/pre>
        

        


        

        
3. section 3.1.1 (question)

        


        

        

          
An appropriate error response is sent =
back to the originator
   of the request.

        

        
Who sends "an appropriate" error response" in t=
his case?

        


        

        
4. section 3.1.2 (editorial) changed "to"->"=
the"

        


        

        

          
When the client has an active and a st=
andby connection to the two
   agents then an alternative strategy for responding to an overload
   report from an agent is to change the standby connection to activ=
e and
   route all traffic through the new active connection.

        

        


        

        
5. section 3.1.3 (editorial)

        


        

        

          
An example of this type of deployment =
includes when there are Diameter
   agents between administrative domains.

        

        
6. section 3.1.3

        


        

        
There is no section 2.2. I guess section 3.1.2 was meant
          here, right?

        


        

        

          
Handling of overload of one or both of=
 agents a11 or a12 in this case
   is equivalent to that discussed in section 2.2.

        

        


        

        
7. section 3.2.1

        


        

        
It is not clear which usage scenario is meant here.

        


        

        

          
   It is envisioned that abatement alg=
orithms will be defined that will
   support the option for Diameter Endpoints to send peer reports.  For
   instance, it is envisioned that one usage scenario for the rate
   algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
   on by the DIME working group as this document is being written, will
   involve abatement being done on a hop-by-hop basis.


8. section 4


Why is throttling to be applied and not diversion (like in case =
of redundant agents)?=C2=A0


In this scenario the reacting node sh=
ould first handle the throttling of the
   overloaded host or realm.
"LOSS" Is it a new t=
ype defined in the scope of this draft?


Note: The goal is to avoid traffic os=
cillations that might result
      from throttling of messages for both the HOST/REALM overload
      reports and the PEER overload reports.  This is especially a
      concern if both reports are of type LOSS.


9. section 5.1.1


Probably it is better to describe OC_PEER_REPORT feature in sect=
ion 5.1?
Otherwise, it is used as a well-known one while it is th=
e first place where it is mentioned.


Also I think it is better to add more specific in this draft rel=
ated to peer report handling:
- define Peer Report Reacting Node =
and Peer Report Reporting Node terms explicitly and use them through the dr=
aft and especially starting from section 5.1=C2=A0

- add "Peer Report" prefix to all the described proced=
ures
Example: Capability Announcement -> Peer Report Capabilit=
y Announcement


10. section 5.1.1/general


"DiameterIdentity" and "Diameter identity"
My proposal is to use one term through the spec.


Under "DOIC node", an agent is meant here?


 When an agent relays a request that =
includes a SourceID AVP in the
   OC-Supported-Features AVP, a DOIC node that supports the
   OC_PEER_REPORT feature MUST remove the received SourceID AVP and
   replace it with a SourceID AVP containing its own Diameter identity.


My proposal is to use peer report reacting node here re-phrasing=
 this statement below in the following way:



 When relaying a request that include=
s a SourceID AVP in the
   OC-Supported-Features AVP, a peer report reacting node MUST remove the r=
eceived SourceID AVP and
   replace it with a SourceID AVP containing its own DiameterIdentity.
11. section 5.1.2


added the missed "to"
changed "PEER_REP=
ORT"-> "PEER"


Note: The transaction state is used w=
hen the DOIC node is acting
      as a peer-report reporting node and needs to send OC-OLR repor=
ts of
      type PEER in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.


"Diameter ID" term is not clarified anywhere.
Re-phrased the appropriate statement a little bit, changed "Diameter=
 ID"->"value"
Also there are other places in th=
e draft where "Diameter ID" term is used.


The peer supports the OC_PEER_REPORT =
feature if the received request
   contains an OC-Supported-Features AVP with the OC-Feature-Vector with
   the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
   value that matches the DiameterIdentity of the peer from which
   the request was received.


Agent is meant under "reporting node" here?


Should not SourceID AVP not just stripped from the relayed answe=
r, but replaced with the SourceID AVP containing the DiameterIdentity of th=
e agent supporting OC_PEER_REPORT feature?


When an agent relays an answer messag=
e, a reporting node that
   supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
   the OC-Supported-Features AVP.


Hard to follow what was wanted to say here:
Corrected =
the statement, but this is just my best guess.


The OC-Peer-Algo AVP MUST indicate th=
e overload abatement
   algorithm that the reporting node wants the reacting nodes to use
   when the reporting node sends a peer overload report as a =
result of
   becoming overloaded.


Should not we add a separate if- statement for the case when the=
 peer does not support OC_PEER_REPORT feature when sending an answer messag=
e?


12. section 5.1.1 and 5.1.2


Probably it is more helpful to illustrate OC_PEER_REPORT feature=
 CA using sequence diagrams like in the load info conveyance draft.


13. general.


What about to use the writing for the same terms through the spe=
c?
Example1: "DOIC node" and "DOIC Node"
Example2: "peer-report reporting node" and "peer repor=
t reporting node"


14. section 5.2.1.2, 5.2.2, 5.2.3 and general


"peer-type OCS" and "peer report OCS" define=
 the same term?
Why not to use only one?



Another example: "peer report" and "peer report-t=
ype" and "report of type PEER"



15. section 5.2.3


Probably it is better to re-phrase this statement a little bit +=
 corrected the misprints.


If a peer report reacting node=
 receives an OC-OLR AVP of type peer and the
SourceID matches the DiameterIdentity of the peer from which the =
report
was received then the report was generated by the peer.
<=
div>

Similar comment + corrected misprints for the next statement:


If a peer report reacting node receiv=
es an OC-OLR AVP of type peer and the
SourceID does not match the DiameterIdentity of the peer from which =
the
report was received then the reacting node MUST ignore the overload
report.


Also I think it is useful to use one wording for the same t=
erm:
"Peer Report OLR", "OC-OLR AVP", "O=
LR"
Let's use a generic one "peer report"?


Just minor comment: "the existing..." and "a new =
overload condition" for all occurrences if my English is correct.


16. section 5.2.3


How may it happen that peer report reacting node receives a peer=
 report not from the peer that generated it?
Peer reports can be =
sent only to peer report reacting node, right? And peer reports are not rel=
ayed, right?


Best regards,


/Misha




2017-01-09 17:35 GMT+03:00 The IESG <iesg=
-secretary@ietf.org>:



The IESG has received a request from the Diameter Maintenance and

Extensions WG (dime) to consider the following document:

- 'Diameter Agent Overload and the Peer Overload Report'

=C2=A0 <draft-ietf-dime-agent-overload-08.txt> as Proposed Stand=
ard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailin=
g lists by 2017-01-23. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





=C2=A0 =C2=A0This specification documents an extension to RFC 7683 (Diamete=
r

=C2=A0 =C2=A0Overload Indication Conveyance (DOIC)) base solution.=C2=A0 Th=
e extension

=C2=A0 =C2=A0defines the Peer overload report type.=C2=A0 The initial use c=
ase for the

=C2=A0 =C2=A0Peer report is the handling of occurrences of overload of a Di=
ameter

=C2=A0 =C2=A0agent.



Requirements







The file can be obtained via

https://datatracker.ietf.org/do=
c/draft-ietf-dime-agent-overload/



IESG discussion can be tracked via

https://datatracker.ietf.org/=
doc/draft-ietf-dime-agent-overload/ballot/





No IPR declarations have been submitted directly on this I-D.





The document contains these normative downward references.

See RFC 3967 for additional information:

=C2=A0 =C2=A0 draft-roach-dime-overload-ctrl: A Mechanism for Diameter=
 Overload Control (None - )

Note that some of these references may already be listed in the acceptable =
Downref Registry.





_______________________________________________

DiME mailing list

DiME@ietf.org

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














--001a113fb1721d52f005468a4b3f--


From nobody Sun Jan 22 17:27:10 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AC112954C for ; Sun, 22 Jan 2017 17:27:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oV_T_tkP1XR for ; Sun, 22 Jan 2017 17:27:07 -0800 (PST)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82ECF129542 for ; Sun, 22 Jan 2017 17:27:07 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id y143so36597694pfb.0 for ; Sun, 22 Jan 2017 17:27:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Z/n34YDFh2ZQkLCTq8K0LSpJbDcNAun34/rS8s9cX+Q=; b=dw6blaDMVAzMCK5M9J6BsYmpVT82XiEnzELH0gjiCctPtGAenNJT0FJDM/NS2/RBnn RY6VbEpJPgPwRBHc4vNOzKxu3LsxLt+OPo+MHZrSVpMlFDbqFHjYcdviPxmulZQjJtXI 1e1BJVI14moY6d0TK8njm0GP3KsGy3DKBWXWuW5pqJ9XIj5NJV9kTv9oqrXmsY96lPGW Uwux6R/paYZ9A35w8qbtsF7STsmjrBFPlo0bgpTQ33kn1Q1NNODQFirbtEOJBN1hKD+p 74NkOExq1LWSU2VFD25Uf2oBbgfiIAkrNxsNeWXWkA2bndxgvtnS5ZbEA3NNOL6G0mWP Wh9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Z/n34YDFh2ZQkLCTq8K0LSpJbDcNAun34/rS8s9cX+Q=; b=fQGL/qOdBIm6e+OJSYSrnzOLKc2YD2DSZT1HcepDbKxrs8xAFzkwHOCyOLh0URrRt/ BUdeIR5vTCFl/wZx06dMY/OGe7H3Ykf3V4r2PW7K52APvGaV6+B9ahuxRw/R9CioPjJM h3IuJt0EnXR9u/l7SUujBq/D75Cl0s312lkvZ59576DLm+HQyAUrSJl15aCA9jfTr8x+ WoZuHRt2Oz74j3w8TcDU9Pnbczc9zNMiXLNxwkMVB5GnVuAfiCoi1o27wGr9Q/WPEiXH 1A5Io/5lDEnP3HpNzHkXMg4adhrK8v168/t3JzxthIzxzBmR0yMyXGOv3IzhdSFbAF7e W3nQ==
X-Gm-Message-State: AIkVDXIdVen682Y/tihwCl25atFKmHSTC9W29owhPNSm7iweW/gkvJg66BbbMbDDsoac8Q==
X-Received: by 10.84.175.234 with SMTP id t97mr39339912plb.145.1485134826654;  Sun, 22 Jan 2017 17:27:06 -0800 (PST)
Received: from ?IPv6:2601:647:4200:e520:8583:f294:1c72:5b68? ([2601:647:4200:e520:8583:f294:1c72:5b68]) by smtp.gmail.com with ESMTPSA id d29sm20033268pfk.83.2017.01.22.17.27.05 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jan 2017 17:27:05 -0800 (PST)
From: "jouni.nospam" 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Message-Id: 
Date: Sun, 22 Jan 2017 17:27:07 -0800
To: dime@ietf.org
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jan 2017 01:27:09 -0000

Folks,

This mail starts the WGLC #3 for draft-ietf-dime-doic-rate-control-04.
The WGLC ends next Sunday 2/5/2017 (PDT).

Please, read & review the draft, provide your support or opposition =
and/or comments to the list.

Just reminding.. no comments/reviews on the document, I cannot conclude =
the WGLC has passed.


Regards,
	Jouni=


From nobody Mon Jan 23 03:23:31 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1302129B11 for ; Mon, 23 Jan 2017 03:23:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.5
X-Spam-Level: 
X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3urSk3OppP8 for ; Mon, 23 Jan 2017 03:23:28 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740631295DC for ; Mon, 23 Jan 2017 03:23:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3F12DBDCC; Mon, 23 Jan 2017 11:23:26 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0O5YyRGgqNA; Mon, 23 Jan 2017 11:23:24 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 762D2BDF9; Mon, 23 Jan 2017 11:23:23 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485170604; bh=GtRD6LH3VGb/w3bVOVZGHxc+UCI6/VvRtOr+xhdJs1s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=OKUf+5iIZnYV2c8Zr8VEAwdydT53SmTO/GHAKeNqmisKCNyQbRD9skAKLsovlAa/7 5puunQ62m9ymNaoqbxCnXRA2ccU6ajmwBnJpEoRluM0vhSh/3RJOWIKZDHY14zFWVY 0YyuhLfneSuqCwZrW5AiATPL+B8gQmFCZEywSH3c=
To: Steve Donovan , Misha Zaytsev , dime@ietf.org
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com>  <1ccf026a-ba8d-ca26-f258-47cc78b49a1f@usdonovans.com>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <94bbf194-777f-1309-9b95-c1b2fab0201e@cs.tcd.ie>
Date: Mon, 23 Jan 2017 11:23:23 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <1ccf026a-ba8d-ca26-f258-47cc78b49a1f@usdonovans.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060409030800020402090900"
Archived-At: 
Subject: Re: [Dime] Last Call:  (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Jan 2017 11:23:31 -0000

This is a cryptographically signed message in MIME format.

--------------ms060409030800020402090900
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi all,

On 20/01/17 17:16, Steve Donovan wrote:
> Misha,
>=20
> Thanks for the detailed review.
>=20
> In the future this type of message only needs to go to the DIME mailing=

> list.

Actually sending IETF last call comments to ietf@ietf.org
is entirely valid - that's partly how we get review from
outside the WG. But sending comments to the WG list is
also ok.

>=20
> I will deal with all of your comments in one email.

Great. I'll hold off moving this forward until we've gotten
those handled. I assume that a revised I-D will be needed.

Thanks,
S.


>=20
> Regards,
>=20
> Steve
>=20
> On 1/17/17 12:23 PM, Misha Zaytsev wrote:
>> Hi All,
>>
>> Here are my comments/questions to an agent overload draft.
>> This the first part. Later on I will complete my review and send out
>> the second portion of the comments.
>>
>> 1. section 1 (editorial) removed "is" before "feasible".
>>
>> In the base specification, the goal is to handle abatement of the
>>     overload occurrence as close to the source of the Diameter traffic=
 as
>>     feasible.
>>
>> "scenaios" -> "scenarios"
>>
>> The Peer overload report type is
>>     defined in a generic fashion so that it can also be used for other=

>>     Diameter overload*scenarios*.
>>
>> 2. section 3.1.1 (editorial) replaced "were"-> "was"
>>
>> In both of these cases, the occurrence of overload in the single
>>     agent must by handled by the client in a similar fashion as if the=

>>     client*was*  handling the overload of a directly connected server.=

>>
>> 3. section 3.1.1 (question)
>>
>> An appropriate error response is sent back to the originator
>>     of the request.
>> Who sends "an appropriate" error response" in this case?
>>
>> 4. section 3.1.2 (editorial) changed "to"->"the"
>>
>> When the client has an active and a standby connection to the two
>>     agents then an alternative strategy for responding to an overload
>>     report from an agent is to change*the *standby connection to
>> active and
>>     route all traffic through the new active connection.
>>
>> 5. section 3.1.3 (editorial)
>>
>> An example of this type of deployment include*s*  when there are Diame=
ter
>>     agents between administrative domains.
>> 6. section 3.1.3
>>
>> There is no section 2.2. I guess section 3.1.2 was meant here, right?
>>
>> Handling of overload of one or both of agents a11 or a12 in this case
>>     is equivalent to that discussed in section 2.2.
>>
>> 7. section 3.2.1
>>
>> It is not clear which usage scenario is meant here.
>>
>>     It is envisioned that abatement algorithms will be defined that wi=
ll
>>     support the option for Diameter Endpoints to send peer reports.  F=
or
>>     instance, it is envisioned that one usage scenario for the rate
>>     algorithm, [I-D.ietf-dime-doic-rate-control], which is being worke=
d
>>     on by the DIME working group as this document is being written, wi=
ll
>>     involve abatement being done on a hop-by-hop basis.
>> 8. section 4
>> Why is throttling to be applied and not diversion (like in case of
>> redundant agents)?
>> In this scenario the reacting node should first handle the throttling
>> of the
>>     overloaded host or realm.
>> "LOSS" Is it a new type defined in the scope of this draft?
>> Note: The goal is to avoid traffic oscillations that might result
>>        from throttling of messages for both the HOST/REALM overload
>>        reports and the PEER overload reports.  This is especially a
>>        concern if*both reports are of type LOSS*.
>> 9. section 5.1.1
>> Probably it is better to describe OC_PEER_REPORT feature in section 5.=
1?
>> Otherwise, it is used as a well-known one while it is the first place
>> where it is mentioned.
>> Also I think it is better to add more specific in this draft related
>> to peer report handling:
>> - define Peer Report Reacting Node and Peer Report Reporting Node
>> terms explicitly and use them through the draft and especially
>> starting from section 5.1
>> - add "Peer Report" prefix to all the described procedures
>> Example: Capability Announcement -> Peer Report Capability Announcemen=
t
>> 10. section 5.1.1/general
>> "DiameterIdentity" and "Diameter identity"
>> My proposal is to use one term through the spec.
>> Under "DOIC node", an agent is meant here?
>>   When an agent relays a request that includes a SourceID AVP in the
>>     OC-Supported-Features AVP, a DOIC node that supports the
>>     OC_PEER_REPORT feature MUST remove the received SourceID AVP and
>>     replace it with a SourceID AVP containing its own Diameter identit=
y.
>> My proposal is to use peer report reacting node here re-phrasing this
>> statement below in the following way:
>>   When relaying a request that includes a SourceID AVP in the
>>     OC-Supported-Features AVP, a peer report reacting node MUST remove=

>> the received SourceID AVP and
>>     replace it with a SourceID AVP containing its own DiameterIdentity=
=2E
>> 11. section 5.1.2
>> added the missed "to"
>> changed "PEER_REPORT"-> "PEER"
>> Note: The transaction state is used when the DOIC node is acting
>>        as a peer-report reporting node and needs*to *send OC-OLR
>> reports of
>>        type*PEER *in answer messages.  The peer overload reports
>>        are only included in answer messages being sent to peers that
>>        support the OC_PEER_REPORT feature.
>> "Diameter ID" term is not clarified anywhere.
>> Re-phrased the appropriate statement a little bit, changed "Diameter
>> ID"->"value"
>> Also there are other places in the draft where "Diameter ID" term is
>> used.
>> The peer supports the OC_PEER_REPORT feature if the received request
>>     contains an OC-Supported-Features AVP with the OC-Feature-Vector w=
ith
>>     the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
>>     value that matches the DiameterIdentity of the peer from which
>>     the request was received.
>> Agent is meant under "reporting node" here?
>> Should not SourceID AVP not just stripped from the relayed answer, but=

>> replaced with the SourceID AVP containing the DiameterIdentity of the
>> agent supporting OC_PEER_REPORT feature?
>> When an agent relays an answer message, a reporting node that
>>     supports the OC_PEER_REPORT feature MUST strip any SourceID AVP fr=
om
>>     the OC-Supported-Features AVP.
>> Hard to follow what was wanted to say here:
>> Corrected the statement, but this is just my best guess.
>> The OC-Peer-Algo AVP MUST indicate the overload abatement
>>     algorithm that the reporting node wants the reacting nodes to use
>>     *when *the reporting node send*s*  a peer overload report as a
>> result of
>>     becoming overloaded.
>> Should not we add a separate if- statement for the case when the peer
>> does not support OC_PEER_REPORT feature when sending an answer message=
?
>> 12. section 5.1.1 and 5.1.2
>> Probably it is more helpful to illustrate OC_PEER_REPORT feature CA
>> using sequence diagrams like in the load info conveyance draft.
>> 13. general.
>> What about to use the writing for the same terms through the spec?
>> Example1: "DOIC node" and "DOIC Node"
>> Example2: "peer-report reporting node" and "peer report reporting node=
"
>> 14. section 5.2.1.2, 5.2.2, 5.2.3 and general
>> "peer-type OCS" and "peer report OCS" define the same term?
>> Why not to use only one?
>> Another example: "peer report" and "peer report-type" and "report of
>> type PEER"
>> 15. section 5.2.3
>> Probably it is better to re-phrase this statement a little bit +
>> corrected the misprints.
>> If a*peer report*  reacting node receives an OC-OLR AVP of type peer
>> and the
>> SourceID matches the*DiameterIdentity *of the peer from which the*repo=
rt*
>> was received then the report was*generated *by the peer.
>> Similar comment + corrected misprints for the next statement:
>> If a peer report reacting node receives an OC-OLR AVP of type peer and=

>> the
>> SourceID does not match the*DiameterIdentity *of the peer from which t=
he
>> *report *was received then the reacting node MUST ignore the overload
>> report.
>> Also I think it is useful to use one wording for the same term:
>> "Peer Report OLR", "OC-OLR AVP", "OLR"
>> Let's use a generic one "peer report"?
>> Just minor comment: "the existing..." and "a new overload condition"
>> for all occurrences if my English is correct.
>> 16. section 5.2.3
>> How may it happen that peer report reacting node receives a peer
>> report not from the peer that generated it?
>> Peer reports can be sent only to peer report reacting node, right? And=

>> peer reports are not relayed, right?
>> Best regards,
>> /Misha
>> 2017-01-09 17:35 GMT+03:00 The IESG > >:
>>
>>     The IESG has received a request from the Diameter Maintenance and
>>     Extensions WG (dime) to consider the following document: -
>>     'Diameter Agent Overload and the Peer Overload Report'    =20
>>  as Proposed Standard The
>>     IESG plans to make a decision in the next few weeks, and solicits
>>     final comments on this action. Please send substantive comments to=

>>     the ietf@ietf.org  mailing lists by
>>     2017-01-23. Exceptionally, comments may be sent to iesg@ietf.org
>>      instead. In either case, please retain the
>>     beginning of the Subject line to allow automated sorting. Abstract=

>>        This specification documents an extension to RFC 7683 (Diameter=

>>        Overload Indication Conveyance (DOIC)) base solution.  The
>>     extension    defines the Peer overload report type.  The initial
>>     use case for the    Peer report is the handling of occurrences of
>>     overload of a Diameter    agent. Requirements The file can be
>>     obtained via
>>     https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/
>>     =

>>     IESG discussion can be tracked via
>>   =20
>> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot=
/
>>   =20
>> 
>>     No IPR declarations have been submitted directly on this I-D. The
>>     document contains these normative downward references. See RFC
>>     3967 for additional information:      =20
>> draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload
>>     Control (None - ) Note that some of these references may already
>>     be listed in the acceptable Downref Registry.
>>     _______________________________________________ DiME mailing list
>>     DiME@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/dime
>>     
>=20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20


--------------ms060409030800020402090900
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMjMx
MTIzMjNaMC8GCSqGSIb3DQEJBDEiBCDD/vMqOwtlQAyz/I4fH1EoyXrXo8CoOrIg0Ooye32x
TTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQASwvymWgRA+vxR6drlQDhUrYlW7v6tJFW0w+nmI4auHb3B0pXMWUkS
TCNVkGxCqy21ijtLy8TrY8ECmPv6BXk676TeENd6LXPEVImJ5MDafb2EjTGqwb59tLai42Pi
8aqi5wi+neWGp/Sr49hy/ewkXUVK+q1DaVVk9vM1qNtQNMSHsW2hLUvDK7VjEVf4PP4Jua9a
oW3Dp1jhJArDwfzxiUiABr7L9ceN9eoRKMyy7BPndiOpkQYGmhvqkfpwbP0wzwdgTagqh6wN
Rh7igWci7nnsaJ1xHWaX9v+AzqU5ZnSigLxbAupk8iEj7MpJHoicVQ4QS5kUBvohumidOzH5
AAAAAAAA
--------------ms060409030800020402090900--


From nobody Tue Jan 24 07:25:27 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4F6129A55 for ; Tue, 24 Jan 2017 07:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.057
X-Spam-Level: 
X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NneqexhzAD0 for ; Tue, 24 Jan 2017 07:25:24 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0121.outbound.protection.outlook.com [104.47.2.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022B8129A53 for ; Tue, 24 Jan 2017 07:25:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U7K+y7PRV/hewdWtP5G5HySYYakG/XiWS4Dj4/oB/Fs=; b=Kv493A7t+Dk2d8Ey695RPv+6HiR8bo9H0K0TvhY6nX7Hffed4Q+W3qrdFnkj7hntB9UJhqa978rZ0bsM81N2pZ4t4lgymwhNfZikiqQW1oS/jeQDnG8oqMV9ReAdG2QeZM6VAYDZGj1Sha51a/obCVv502Ol6IInBJMnk3F8wIU=
Received: from HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) by HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Tue, 24 Jan 2017 15:25:21 +0000
Received: from HE1PR0701MB2857.eurprd07.prod.outlook.com ([10.168.91.147]) by HE1PR0701MB2857.eurprd07.prod.outlook.com ([10.168.91.147]) with mapi id 15.01.0874.012; Tue, 24 Jan 2017 15:25:21 +0000
From: "Gardella, Maryse (Nokia - FR)" 
To: Yuval Lifshitz , "dime@ietf.org" 
Thread-Topic: RFC4006bis - Subscription-Id-Extension AVP
Thread-Index: AdJtpzBPVPEgVuSXSxiP12VbbHIMngFfVP8w
Date: Tue, 24 Jan 2017 15:25:21 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=maryse.gardella@nokia.com; 
x-originating-ip: [135.245.240.250]
x-ms-office365-filtering-correlation-id: fcd60c3e-4224-4aa7-5d4f-08d4446d361c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2857; 
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2857; 7:wF2rzg+7rBHEHV+mQxyuyrzjAtjoCI35SrHTmdAH3xL1s31GrQJ0ZEsj1taoCfIeY6IQW8a4GCFRdtzIeXo4Nu1KtVyatF3A17++TqNo8X54gvEvG9svhm+RxvYHoJTOJQy7AjywH37bbojX/Vzwy3s+RqXO8YIlvG097rj0CacwO8wDeNLVRqQqDvdf2cO3fvtlx4sib58+I1a0Mi9LfwdILY3LxeakNuj5LU50Z33cRcqBd6lfJyawzrxz85btpy9gGcKnkxLNLg7zLDOxt+VttmIithrKsfdQ65OWCqzQ8DJEY3gxv4ZX6FiYl8Z5FvKtxbszndq15Www6YDN5pxNxto7lvUHmvDHtuqGUBLct3YMb+UFANjLA+mkhLZB15db8jotFlPzQyV8ZBr3Jguc8LVOeiWXozlQ7GHyFYkW/db27jffynLK5UKJvOjC/OlQRq/XYis7kyFG4CBs6g==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123558021)(20161123562025)(6072148); SRVR:HE1PR0701MB2857; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2857; 
x-forefront-prvs: 0197AFBD92
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39410400002)(39840400002)(39850400002)(39450400003)(199003)(53754006)(189002)(122556002)(8936002)(230783001)(68736007)(9326002)(86362001)(19609705001)(81166006)(81156014)(8676002)(53936002)(66066001)(2900100001)(76176999)(54356999)(102836003)(101416001)(106356001)(236005)(5001770100001)(5660300001)(50986999)(77096006)(6116002)(92566002)(105586002)(790700001)(3846002)(107886002)(3660700001)(3280700002)(99286003)(6306002)(7696004)(55016002)(189998001)(38730400001)(7736002)(25786008)(74316002)(606005)(6436002)(229853002)(2906002)(54896002)(7906003)(9686003)(97736004)(2501003)(33656002)(6506006)(2950100002)(21314002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2857; H:HE1PR0701MB2857.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB28573F830861577D13DBC916FC750HE1PR0701MB2857_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2017 15:25:21.4433 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2857
Archived-At: 
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Jan 2017 15:25:26 -0000

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

Hi Yuval,

Thanks for continuing on this.
I am not sure to understand the difference between "may" and "must", since =
with  "May" we can end having the M-bit set by the RFC4006bis CC client.
I guess from the protocol's perspective "may" and "must" makes no differenc=
e right?

BR
Maryse

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz
Sent: vendredi 13 janvier 2017 15:24
To: dime@ietf.org
Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi All,
As part of the RFC4006bis work there are several AVPs that we plan on makin=
g future proof (See also: https://trac.ietf.org/trac/dime/ticket/95). For e=
xample, Subscription-Id AVP cannot be extended to new types without changin=
g the enumeration in Subscription-Id-Type AVP, which in turn requires a new=
 application ID (something we really want to avoid).
To solve this issue we propose adding a new, extendable AVP. In this exampl=
e:

Subscription-Id-Extension ::=3D < AVP Header: XXX >
                             [ Subscription-Id-E164 ]
                             [ Subscription-Id-IMSI ]
                             [ Subscription-Id-SIP-URI ]
                             [ Subscription-Id-NAI ]
                             [ Subscription-Id-Private ]
                            *[ AVP ]

When looking into Subscription-ID-Extension AVP  header flags I ran into a =
problem. The existing Subscription-ID AVP (and its sub-AVPs) are all marked=
 with the M-bit as a "must", probably because they hold the subscriber's na=
me which is critical information.
However, in order for a RFC4006bis CC client to be able to communicate with=
 an RFC4006 CC-server, they will have to be marked as "may".

Would appreciate your point of view on that topic?

Best Regards,

Yuval


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











Hi Yuval, 


 


Thanks for continuing on this.


I am not sure to understand the difference between &=
#8220;may” and “must”, since with  “May”=
 we can end having the M-bit set by the RFC4006bis CC client.

I guess from the protocol’s perspective “=
;may” and “must” makes no difference right?

 


BR


Maryse


 






From: DiME [mailto:dime-bounces@ietf.org] =
On Behalf Of
Yuval Lifshitz

Sent: vendredi 13 janvier 2017 15:24

To: dime@ietf.org

Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP






 


Hi All,


As part of the RFC4006bis work there are several AVP=
s that we plan on making future proof (See also:
https://trac.ietf.org=
/trac/dime/ticket/95). For example, Subscription-Id AVP cannot be exten=
ded to new types without changing the enumeration in Subscription-Id-Type A=
VP, which in turn requires a new application
 ID (something we really want to avoid).


To solve this issue we propose adding a new, extenda=
ble AVP. In this example:


 


Subscription-Id-Extension ::=3D < AVP Heade=
r: XXX >


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-E164 ]


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-IMSI ]


        &nb=
sp;            =
        [ Subscription-Id-SIP-URI ]=



       &nbs=
p;            &=
nbsp;        [ Subscription-Id-NAI ]


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-Private ]=



       &nbs=
p;            &=
nbsp;       *[ AVP ]


 


When looking into Subscription-ID-Extension AVP &nbs=
p;header flags I ran into a problem. The existing Subscription-ID AVP (and =
its sub-AVPs) are all marked with the M-bit as a “must”, probab=
ly because they hold the subscriber’s name which is
 critical information.


However, in order for a RFC4006bis CC client to be a=
ble to communicate with an RFC4006 CC-server, they will have to be marked a=
s “may”.



 


Would appreciate your point of view on that topic?


 


Best Regards,


 


Yuval


 






--_000_HE1PR0701MB28573F830861577D13DBC916FC750HE1PR0701MB2857_--


From nobody Wed Jan 25 00:30:02 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925EE129891 for ; Wed, 25 Jan 2017 00:30:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.433
X-Spam-Level: 
X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 qXFMRpsYu91S for ; Wed, 25 Jan 2017 00:29:58 -0800 (PST)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6357112986E for ; Wed, 25 Jan 2017 00:29:58 -0800 (PST)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 03:29:56 -0500
From: Yuval Lifshitz 
To: "Gardella, Maryse (Nokia - FR)" , "dime@ietf.org" 
Thread-Topic: RFC4006bis - Subscription-Id-Extension AVP
Thread-Index: AdJtpzBPVPEgVuSXSxiP12VbbHIMngFfVP8wAO+8a8A=
Date: Wed, 25 Jan 2017 08:29:55 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.142.1]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE497002AC18wtlexchp1sandvi_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2017 08:30:00 -0000

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

Hi Maryse,
The idea is the following:

*         If the CC client want to work with RFC4006bis only CC server, and=
 want to make sure that the subscription ID is understood by the server, it=
 may set the M-bit. Any RFC4006 server will reply with DIAMETER_AVP_UNSUPPO=
RTED (5001)

*         If the CC client is not sure whether the CC servers are RFC4006 o=
r RFC4006bis, or have a mix of servers, and want to work with both, it may =
not set the M-bit

o   In this case it would send both AVPs for the old types, so that the new=
 AVP will be ignored by the RFC4006 servers

o   In a case of a new type of subscription, not covered in RFC4006, it may=
 send the new AVP with the M-bit set, causing any old server to reply with =
DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP without the M=
-bit set, here the server would just ignore the AVP, but would probably rep=
ly DIAMETER_MISSING_AVP (5005) as it will not have any subscription ID

Yuval

From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]
Sent: Tuesday, January 24, 2017 5:25 PM
To: Yuval Lifshitz; dime@ietf.org
Subject: RE: RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

Thanks for continuing on this.
I am not sure to understand the difference between "may" and "must", since =
with  "May" we can end having the M-bit set by the RFC4006bis CC client.
I guess from the protocol's perspective "may" and "must" makes no differenc=
e right?

BR
Maryse

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz
Sent: vendredi 13 janvier 2017 15:24
To: dime@ietf.org
Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi All,
As part of the RFC4006bis work there are several AVPs that we plan on makin=
g future proof (See also: https://trac.ietf.org/trac/dime/ticket/95). For e=
xample, Subscription-Id AVP cannot be extended to new types without changin=
g the enumeration in Subscription-Id-Type AVP, which in turn requires a new=
 application ID (something we really want to avoid).
To solve this issue we propose adding a new, extendable AVP. In this exampl=
e:

Subscription-Id-Extension ::=3D < AVP Header: XXX >
                             [ Subscription-Id-E164 ]
                             [ Subscription-Id-IMSI ]
                             [ Subscription-Id-SIP-URI ]
                             [ Subscription-Id-NAI ]
                             [ Subscription-Id-Private ]
                            *[ AVP ]

When looking into Subscription-ID-Extension AVP  header flags I ran into a =
problem. The existing Subscription-ID AVP (and its sub-AVPs) are all marked=
 with the M-bit as a "must", probably because they hold the subscriber's na=
me which is critical information.
However, in order for a RFC4006bis CC client to be able to communicate with=
 an RFC4006 CC-server, they will have to be marked as "may".

Would appreciate your point of view on that topic?

Best Regards,

Yuval


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











Hi Maryse,<=
/span>


The idea is the follow=
ing: 



·        
If the CC client want to work with RFC4006bis only CC server, an=
d want to make sure that the subscription ID is understood by the server, i=
t may set the M-bit. Any RFC4006 server
 will reply with DIAMETER_AVP_UNSUPPORTED (5001)


·        
If the CC client is not sure whether the CC servers are RFC4006 =
or RFC4006bis, or have a mix of servers, and want to work with both, it may=
 not set the M-bit



o  
In this case it would send both AVPs for the old types, so that =
the new AVP will be ignored by the RFC4006 servers



o  
In a case of a new type of subscription, not covered in RFC4006,=
 it may send the new AVP with the M-bit set, causing any old server to repl=
y with DIAMETER_AVP_UNSUPPORTED (5001).
 It may also send the new AVP without the M-bit set, here the server would =
just ignore the AVP, but would probably reply DIAMETER_MISSING_AVP (5005) a=
s it will not have any subscription ID


 


Yuval


 






From: Gardella=
, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]


Sent: Tuesday, January 24, 2017 5:25 PM

To: Yuval Lifshitz; dime@ietf.org

Subject: RE: RFC4006bis - Subscription-Id-Extension AVP






 


Hi Yuval, 


 


Thanks for continuing on this.


I am not sure to understand the difference between &=
#8220;may” and “must”, since with  “May”=
 we can end having the M-bit set by the RFC4006bis CC client.

I guess from the protocol’s perspective “=
;may” and “must” makes no difference right?

 


BR


Maryse


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Yuval Lifshitz

Sent: vendredi 13 janvier 2017 15:24

To: dime@ietf.org

Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP






 


Hi All,


As part of the RFC4006bis work there are several AVP=
s that we plan on making future proof (See also:
https://trac.ietf.org=
/trac/dime/ticket/95). For example, Subscription-Id AVP cannot be exten=
ded to new types without changing the enumeration in Subscription-Id-Type A=
VP, which in turn requires a new application
 ID (something we really want to avoid).


To solve this issue we propose adding a new, extenda=
ble AVP. In this example:


 


Subscription-Id-Extension ::=3D < AVP Heade=
r: XXX >


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-E164 ]


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-IMSI ]


        &nb=
sp;            =
        [ Subscription-Id-SIP-URI ]=



       &nbs=
p;            &=
nbsp;        [ Subscription-Id-NAI ]


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-Private ]=



       &nbs=
p;            &=
nbsp;       *[ AVP ]


 


When looking into Subscription-ID-Extension AVP &nbs=
p;header flags I ran into a problem. The existing Subscription-ID AVP (and =
its sub-AVPs) are all marked with the M-bit as a “must”, probab=
ly because they hold the subscriber’s name which is
 critical information.


However, in order for a RFC4006bis CC client to be a=
ble to communicate with an RFC4006 CC-server, they will have to be marked a=
s “may”.



 


Would appreciate your point of view on that topic?


 


Best Regards,


 


Yuval


 






--_000_C43C255C7106314F8D13D03FA20CFE497002AC18wtlexchp1sandvi_--


From nobody Thu Jan 26 08:56:05 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5871298AA for ; Thu, 26 Jan 2017 08:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.433
X-Spam-Level: 
X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ4rdXKX5vD8 for ; Thu, 26 Jan 2017 08:56:02 -0800 (PST)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCE91297F1 for ; Thu, 26 Jan 2017 08:56:02 -0800 (PST)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 11:56:00 -0500
From: Yuval Lifshitz 
To: "dime@ietf.org" 
Thread-Topic: RFC4006bis - ticket #95 and #97
Thread-Index: AdJ39RFFAo5XXXiiS0yH0jN0vLU02g==
Date: Thu, 26 Jan 2017 16:56:00 +0000
Message-ID: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.196.10]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Dime] RFC4006bis - ticket #95 and #97
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2017 16:56:03 -0000

Dear All,

I have tried to tackle the following 2 tickets:
https://trac.ietf.org/trac/dime/ticket/97
https://trac.ietf.org/trac/dime/ticket/95
As part of the RFC4006bis effort.=20
As the changes are quite extensive, and don't fit nicely into a short text =
diff I would really appreciate if you can review and comment on the github =
commits:
As part of ticket #95:
https://github.com/lbertz02/rfc4006bis/commit/c2dc75ac9fe199397de67b4ce46c2=
7be75f88bd5 - future proofing User Equipment
https://github.com/lbertz02/rfc4006bis/commit/c221682beaafe0d6478261e7b9929=
dd547ad76b0 - future proofing Subscription IDs
https://github.com/lbertz02/rfc4006bis/commit/70c4f33df1cf6e728d3b8842f310a=
7c8bef7ec71 - future proofing Redirect Server
As part of ticket #97:
https://github.com/lbertz02/rfc4006bis/commit/4b280d705363e1e81172f4557e8b6=
70e09391f2b - add QoS to F-U-I and finish future proofing Redirect Server
If you feel that textual diffs would make it easier for you, let me know an=
d I will prepare them.

Best Regards,

Yuval


From nobody Thu Jan 26 13:35:43 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391E7129BC8 for ; Thu, 26 Jan 2017 13:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuYj6DKKfriZ for ; Thu, 26 Jan 2017 13:35:40 -0800 (PST)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E921298CE for ; Thu, 26 Jan 2017 13:35:39 -0800 (PST)
Received: by mail-lf0-x22f.google.com with SMTP id v186so152609458lfa.1 for ; Thu, 26 Jan 2017 13:35:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3HGGMJv3IstnZ59OhgB6QO4nTM+5HeI3d3k3ihDL4qg=; b=Fs+zTxjP59hxa0fZSS5k+FqsS226wctoPMrgwfinTptgPXS5Cz/aRgpnbEN3bN+jdF Ytk/7JMmZ5cE+SElAJ/fGzEmZ69DIEabPJ+tXw8ltXYNdtV3xIQo2tLg/8y1h2wDuqxv dOtQ4uuvkMiv/WcHGu4ts4Khukkc0s/5Bvu6co8c7GRgDfYjQiyodVtdIs8zgxv+BvEt fjVRHyZQM97p+qHbQt9svuHcZbEw8sN58+MbRiXRPlR2BgvcERiIcXIRra3R4M4Ti8rf UrLXam/04vsBfIWLw2HcJ/tysmJhQl3cUp1KDnBl62q9uI9cCzyrkXB4HWPRhuNkZX6I kWEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3HGGMJv3IstnZ59OhgB6QO4nTM+5HeI3d3k3ihDL4qg=; b=fXxz9AtSW3n2mZ8xFVh9/rSuCHMEVHcOkvcu2mvtKCTZITwhhDC1EYmZ/p1pyY1FJL CaCtjGVV7oBwnQB2rX9LjyGqPnVAI3XACjoPw3+hwPF/ZOIXyM42uErq/OqoJZxSWKNq wnAIZ11dzmbF4USrvjnkH9Arxvzw4YtUygksHes6zwlZy7WOe0VNMEgifivymuX/F00d xenc7e89zmy66W6q9KZVBVY+xkn+ISJ3mepoq+g2WnqT8UXBl3Vbvni66qRBTvp9LHWM 7GTW3Rx3q4rujlI1duamT2K6PoOI3TF1FjZCn50JxOMKq5YQ6tCkLa/CnzyjbHVVf4lf QqEg==
X-Gm-Message-State: AIkVDXJk4UU4RaxTjy8Svi8v/aC18/yMMayGdwBPjQ5dFWTA3SgMK4D8egTAXl4cqbjEEZayoXPIHHLJGWKSUg==
X-Received: by 10.25.79.79 with SMTP id a15mr1682964lfk.58.1485466537428; Thu, 26 Jan 2017 13:35:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Thu, 26 Jan 2017 13:35:36 -0800 (PST)
In-Reply-To: 
References: 
From: Misha Zaytsev 
Date: Fri, 27 Jan 2017 00:35:36 +0300
Message-ID: 
To: "jouni.nospam" 
Content-Type: multipart/alternative; boundary=94eb2c1cdb0a4a0c8d0547062180
Archived-At: 
Cc: dime@ietf.org
Subject: Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2017 21:35:42 -0000

--94eb2c1cdb0a4a0c8d0547062180
Content-Type: text/plain; charset=UTF-8

Hi,

Here are my comments to the draft:

1. section 1.


If the service requests that result in Diameter transactions *increase
*quickly...


2. section 1. corrected misprints

Consider the case where a reacting *(?)* node is handling 100 service
   requests per second, where each of these service requests results in
   one Diameter transaction being sent to a *reporting *node.  If the
   *reporting *node is approaching an overload state, or is already in an
   overload state, it will send a Diameter overload report requesting a
   percentage reduction in traffic sent.  Assume for this discussion
   that the reporting node requests a 10% reduction.  The reacting node
   will then abate (diverting or throttling) ten Diameter transactions *per*
   second, sending the remaining 90 transactions per second to the
   *reporting *node.


3. section 1, reporting nodes -> reporting node's

The reacting node will continue to honor the *reporting node's
request* for a 10% reduction in traffic.


4. section 1, question

Can't it we simplify the description and make it shorter at the same time?
Loss algorithm is about the case with a specific traffic rate. Thus, the
amount of the abated traffic directly depends on its rate.
In this case the reporting node just says to a reacting one: "I want you to
send less traffic".
While rate algorithm is about the traffic rate itself. In this case a
reporting node says to a reacting one: "I want you to sent traffic slower"

This is just an idea/proposal in which way the description can be
simplified.
If this is the matter of preference, then OK.

Also, could it be clarified the meaning of the following statement?
What potential to make the situation worse is meant here?

This control feedback loop has the potential to make the situation worse.


5. section 5.1/general

report-type -> report type
DiameterID -> DiameterIdentity

6. section 5.5./general

Rate algorithm -> rate algorithm (if not at the beginning of the statement)

7. section 5.5

Probably "MUST" is to be used?

When sending an overload report for the *rate* algorithm, the OC-
   Maximum-Rate AVP *MUST be* included and the OC-Reduction-Percentage
AVP *MUST not
   be* included.


8. section 5.6

Once a determination is made by the reacting node that an individual
   Diameter request is to be subjected to abatement treatment then the
   procedures for throttling and diversion defined in [RFC7683] and
   [I-D.ietf-dime-agent-overload] *are applied*.


9. section 6.1.1

Probably, it is better to use bit representation of 4, isn't it?

OLR_RATE_ALGORITHM (0x000000000000000*100*)


10. section 6.2.1 corrected misprints

The OC-Maximum-Rate AVP (AVP code TBD1) is *of* type Unsigned32 and
   describes the maximum rate *that* the sender is requested to send
   traffic.


11. section 7.1

To be honest, I do not see the value of the text in this section. It just
formulates already defined things in a shorter form.
Is it really worth having it in the spec?

In general, let me state my personal opinion: I think we should take only
really meaningful info from SIP RFC, not just pull the content with the
appropriate changes to be inline with Diameter RFC7683...

12. section 7.2

It is clear that the reacting nodes may send less than the specified
OC-Maximum-Rate value.
They should not send more than the specified OC-Maximum-Rate value, right?

Not sure what is the purpose of the 2nd paragraph...

Note that the AVP for the rate algorithm is an upper bound (in
   request messages per second) on the traffic sent by the reacting node
   to the reporting node.  The reacting node may send traffic at a rate
   significantly lower than the upper bound, for a variety of reasons.

   In other words, when multiple reacting nodes are being controlled by
   an overloaded reporting node, at any given time some reacting nodes
   may receive requests at a rate below its target maximum Diameter
   request rate while others above that target rate.  But the resulting
   request rate presented to the overloaded reporting node will converge
   towards the target Diameter request rate.


The things below are already described in the above sections, aren't they?
If so, what is the reason behind to duplicate the info?

Upon detection of overload, and the determination to invoke overload
   controls, the reporting node MUST follow the specifications in
   [RFC7683] to notify its clients of the allocated target maximum
   Diameter request rate and to notify them that the rate overload
   abatement is in effect.

   The reporting node MUST use the OC-Maximum-Rate AVP defined in this
   specification to communicate a target maximum Diameter request rate
   to each of its clients.


13. Upper case in section titles for section 7.3.1, 7.3.2, 7.3.3, 8.1 and
8.2

14. section 9.  apply-> are applied (if my understanding is correct)

As such, all of the security considerations outlined in [RFC7683] are
applied to the rate overload
   abatement mechanism.


If more issues are found, I will add them to the list later on.

Best regards,

/Misha



2017-01-23 4:27 GMT+03:00 jouni.nospam :

> Folks,
>
> This mail starts the WGLC #3 for draft-ietf-dime-doic-rate-control-04.
> The WGLC ends next Sunday 2/5/2017 (PDT).
>
> Please, read & review the draft, provide your support or opposition and/or
> comments to the list.
>
> Just reminding.. no comments/reviews on the document, I cannot conclude
> the WGLC has passed.
>
>
> Regards,
>         Jouni
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

--94eb2c1cdb0a4a0c8d0547062180
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

Here are my comments to the draft:<=
/div>

1. section 1.
=C2=A0
If the service requests that result in Diameter transacti=
ons increase quickly...

2. section 1.=
 corrected misprints

Co=
nsider the case where a reacting (?) node is handling 100 service
   requests per second, where each of these service requests results in
   one Diameter transaction being sent to a reporting node.  If the
   reporting node is approaching an overload state, or is already in=
 an
   overload state, it will send a Diameter overload report requesting a
   percentage reduction in traffic sent.  Assume for this discussion
   that the reporting node requests a 10% reduction.  The reacting node
   will then abate (diverting or throttling) ten Diameter transactions p=
er
   second, sending the remaining 90 transactions per second to the
   reporting node.

3. section 1, repo=
rting nodes -> reporting node's

The reacting node will continue to honor the reporting =
node's request for a 10% reduction in traffic.  
4. section 1, question

Can't it w=
e simplify the description and make it shorter at the same time?
=
Loss algorithm is about the case with a specific traffic rate. Thus, the am=
ount of the abated traffic directly depends on its rate.
In this =
case the reporting node just says to a reacting one: "I want you to se=
nd less traffic".
While rate algorithm is about the traffic =
rate itself. In this case a reporting node says to a reacting one: "I =
want you to sent traffic slower"

This is just=
 an idea/proposal in which way the description can be simplified.
If this is the matter of preference, then OK.

Als=
o, could it be clarified the meaning of the following statement?
=
What potential to make the situation worse is meant here?

This control feedback loop has the poten=
tial to make the situation worse.

5. section=
 5.1/general

report-type -> report type
DiameterID -> DiameterIdentity

6. section 5.=
5./general

Rate algorithm -> rate algorithm (if=
 not at the beginning of the statement)

7. section=
 5.5

Probably "MUST" is to be used?

When sending an overload re=
port for the rate algorithm, the OC-
   Maximum-Rate AVP MUST be included and the OC-Reduction-Percentage=
 AVP MUST not
   be included.

8. section 5.6

Once a determination is made by =
the reacting node that an individual
   Diameter request is to be subjected to abatement treatment then the
   procedures for throttling and diversion defined in [RFC7683] and
   [I-D.ietf-dime-agent-overload] are applied.

<=
/div>
9. section 6.1.1

Probably, it is better =
to use bit representation of 4, isn't it?

OLR_RATE_ALGORITHM (0x000000000000000100)

10. section 6.2.1 corrected misprints

The OC-Maximum-Rate AVP (AVP cod=
e TBD1) is of type Unsigned32 and
   describes the maximum rate that the sender is requested to send
   traffic.

11. section 7.1

To be honest, I do not see the value of the text in this section. =
It just formulates already defined things in a shorter form.
Is i=
t really worth having it in the spec?

In general, =
let me state my personal opinion: I think we should take only really meanin=
gful info from SIP RFC, not just pull the content with the appropriate chan=
ges to be inline with Diameter RFC7683...

12. sect=
ion 7.2

It is clear that the reacting nodes may se=
nd less than the specified OC-Maximum-Rate value.
They should not=
 send more than the specified OC-Maximum-Rate value, right?

<=
/div>
Not sure what is the purpose of the 2nd paragraph...
Note that the AVP for the rate algo=
rithm is an upper bound (in
   request messages per second) on the traffic sent by the reacting node
   to the reporting node.  The reacting node may send traffic at a rate
   significantly lower than the upper bound, for a variety of reasons.

   In other words, when multiple reacting nodes are being controlled by
   an overloaded reporting node, at any given time some reacting nodes
   may receive requests at a rate below its target maximum Diameter
   request rate while others above that target rate.  But the resulting
   request rate presented to the overloaded reporting node will converge
   towards the target Diameter request rate.

The things below are already described in the above sections, aren't t=
hey?
If so, what is the reason behind to duplicate the info?

Upon detection of overload,=
 and the determination to invoke overload
   controls, the reporting node MUST follow the specifications in
   [RFC7683] to notify its clients of the allocated target maximum
   Diameter request rate and to notify them that the rate overload
   abatement is in effect.

   The reporting node MUST use the OC-Maximum-Rate AVP defined in this
   specification to communicate a target maximum Diameter request rate
   to each of its clients.

13. Upper case in=
 section titles for section 7.3.1, 7.3.2, 7.3.3, 8.1 and 8.2

=

14. section 9. =C2=A0apply-> are applied (if my understanding=
 is correct)

As such, a=
ll of the security considerations outlined in [RFC7683] are applied to the =
rate overload
   abatement mechanism.

If more issues are f=
ound, I will add them to the list later on.

Best r=
egards,

/Misha



2017-01=
-23 4:27 GMT+03:00 jouni.nospam <jouni.nospam@gmail.com>:
Folks,



This mail starts the WGLC #3 for draft-ietf-dime-doic-rate-control-04.=


The WGLC ends next Sunday 2/5/2017 (PDT).



Please, read & review the draft, provide your support or opposition and=
/or comments to the list.



Just reminding.. no comments/reviews on the document, I cannot conclude the=
 WGLC has passed.





Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jouni

_______________________________________________

DiME mailing list

DiME@ietf.org

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





--94eb2c1cdb0a4a0c8d0547062180--


From nobody Sat Jan 28 13:07:20 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2478129868 for ; Sat, 28 Jan 2017 13:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLYFYiQRG-hz for ; Sat, 28 Jan 2017 13:07:17 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F9012988A for ; Sat, 28 Jan 2017 13:07:16 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id x1so91111670lff.0 for ; Sat, 28 Jan 2017 13:07:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8u+qSg9mz9vGIGo/NguXdXJb9RnZyhqxog2NupKjr4U=; b=F/a5cs+e/Qt0g5gEn6YgFqxG0EBzw+lrM+6vq12yG2AyJtDQc1QoFmjVgNZQWb0DbT XPd+Y0q0dqG1Kf73OODEKLIQwyo5/cew45UTmFOfSKiMW8riwXzHXQeDcnk1rMHgrEFm ugUCHCS+bC//GrdtLx/VoHR7ry6A1Ip2zWkIfRaWjtwZHBLFZsgrOGbSx+XFlFY+4n8l cTtMyCTPkQFTReySniLfbpubP2/msWwQlxfxvn1MkcZ+DVi3N94+Ael47BhZ7T1o/Ck9 unv3M/w8WeF0sG/uX3DWoiAb6+/nXOybiTWEsLWBa7Ul76i4GXNbZaaQtDq6I7DN7jmv BUuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8u+qSg9mz9vGIGo/NguXdXJb9RnZyhqxog2NupKjr4U=; b=POhvwhPg4fBFilTmIbwqDwnrim0yanWlb7uSTONRr89VupsYjw3u9+ezGwwBinE6Wy GwXNUuKv5L/UcJ7MOqdy8Bn5R/AtG80+tgpHG/HjXQRebWUHsgRjdacpvj+Tx3dstH/C SdXMd0pGQQbWch2bvsCQCNvCzyNIsmcPDZ8OX4xvmmOoChB/gcnaexnWhbZZ5ie1z/VI /lJoJR8uzZ2MnuWVEFcX9hKj12D+om/VljrXF/PHlDZHZ1Vt2Ulr/kcDgU09nThKgwd/ D+rs9Wv3tJ6NmTcZoJLJtuCipw9CrCyW70RSoIH2Un2bn9Qi6NyCV+EuXG0302PZZ9iG XHGw==
X-Gm-Message-State: AIkVDXJyP/eQkhA5qXvmwfgWLSAs8epDfI163n9hsYcUO3jnwZnAPdYdp7r44ewLEMQbr4qFF8dqed0xs3s4vw==
X-Received: by 10.25.79.79 with SMTP id a15mr4818489lfk.58.1485637634650; Sat, 28 Jan 2017 13:07:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Sat, 28 Jan 2017 13:07:13 -0800 (PST)
In-Reply-To: 
References:   
From: Misha Zaytsev 
Date: Sun, 29 Jan 2017 00:07:13 +0300
Message-ID: 
To: Yuval Lifshitz 
Content-Type: multipart/alternative; boundary=94eb2c1cdb0a7a78da05472df777
Archived-At: 
Cc: "dime@ietf.org" , "Gardella, Maryse \(Nokia - FR\)" 
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jan 2017 21:07:19 -0000

--94eb2c1cdb0a7a78da05472df777
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Yuval,

May I ask you several questions to be able to understand the whole
situation:

1. Why are you proposing to add new extendable AVPs only for *some *of the
AVPs listed in section 12?
I think the same concern is applicable for all these AVPs, isn't?

2. Could you clarify what official procedure to assign new available values
is meant here?
It is not working w/o defining new Application-ID as you mentioned above?


12.16.  Subscription-Id-Type AVP

   As defined in Section 8.47, the Subscription-Id-Type AVP includes
   Enumerated type values 0 - 4.  IANA has created and is maintaining a
   namespace for this AVP.  All remaining values are available for
   assignment by a Designated Expert [RFC2434].


Excuse me in advance if what I'm asking about are well-known things.
But still please clarify them at least for me...

Thanks a lot in advance!

/Misha

2017-01-25 11:29 GMT+03:00 Yuval Lifshitz :

> Hi Maryse,
>
> The idea is the following:
>
> =C2=B7         If the CC client want to work with RFC4006bis only CC serv=
er,
> and want to make sure that the subscription ID is understood by the serve=
r,
> it may set the M-bit. Any RFC4006 server will reply with
> DIAMETER_AVP_UNSUPPORTED (5001)
>
> =C2=B7         If the CC client is not sure whether the CC servers are RF=
C4006
> or RFC4006bis, or have a mix of servers, and want to work with both, it m=
ay
> not set the M-bit
>
> o   In this case it would send both AVPs for the old types, so that the
> new AVP will be ignored by the RFC4006 servers
>
> o   In a case of a new type of subscription, not covered in RFC4006, it
> may send the new AVP with the M-bit set, causing any old server to reply
> with DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP withou=
t
> the M-bit set, here the server would just ignore the AVP, but would
> probably reply DIAMETER_MISSING_AVP (5005) as it will not have any
> subscription ID
>
>
>
> Yuval
>
>
>
> *From:* Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]
> *Sent:* Tuesday, January 24, 2017 5:25 PM
> *To:* Yuval Lifshitz; dime@ietf.org
> *Subject:* RE: RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> Hi Yuval,
>
>
>
> Thanks for continuing on this.
>
> I am not sure to understand the difference between =E2=80=9Cmay=E2=80=9D =
and =E2=80=9Cmust=E2=80=9D, since
> with  =E2=80=9CMay=E2=80=9D we can end having the M-bit set by the RFC400=
6bis CC client.
>
> I guess from the protocol=E2=80=99s perspective =E2=80=9Cmay=E2=80=9D and=
 =E2=80=9Cmust=E2=80=9D makes no
> difference right?
>
>
>
> BR
>
> Maryse
>
>
>
> *From:* DiME [mailto:dime-bounces@ietf.org ] *On
> Behalf Of *Yuval Lifshitz
> *Sent:* vendredi 13 janvier 2017 15:24
> *To:* dime@ietf.org
> *Subject:* [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> Hi All,
>
> As part of the RFC4006bis work there are several AVPs that we plan on
> making future proof (See also: https://trac.ietf.org/trac/dime/ticket/95)=
.
> For example, Subscription-Id AVP cannot be extended to new types without
> changing the enumeration in Subscription-Id-Type AVP, which in turn
> requires a new application ID (something we really want to avoid).
>
> To solve this issue we propose adding a new, extendable AVP. In this
> example:
>
>
>
> Subscription-Id-Extension ::=3D < AVP Header: XXX >
>
>                              [ Subscription-Id-E164 ]
>
>                              [ Subscription-Id-IMSI ]
>
>                              [ Subscription-Id-SIP-URI ]
>
>                              [ Subscription-Id-NAI ]
>
>                              [ Subscription-Id-Private ]
>
>                             *[ AVP ]
>
>
>
> When looking into Subscription-ID-Extension AVP  header flags I ran into =
a
> problem. The existing Subscription-ID AVP (and its sub-AVPs) are all mark=
ed
> with the M-bit as a =E2=80=9Cmust=E2=80=9D, probably because they hold th=
e subscriber=E2=80=99s
> name which is critical information.
>
> However, in order for a RFC4006bis CC client to be able to communicate
> with an RFC4006 CC-server, they will have to be marked as =E2=80=9Cmay=E2=
=80=9D.
>
>
>
> Would appreciate your point of view on that topic?
>
>
>
> Best Regards,
>
>
>
> Yuval
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
>

--94eb2c1cdb0a7a78da05472df777
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Yuval,

May I ask you several questio=
ns to be able to understand the whole situation:

1=
. Why are you proposing to add new extendable AVPs only for some of =
the AVPs listed in section 12?
I think the same concern is applic=
able for all these AVPs, isn't?

2. Could you c=
larify what official procedure to assign new available values is meant here=
?
It is not working w/o defining new Application-ID as you mentio=
ned above?


12.16.  Subscr=
iption-Id-Type AVP

   As defined in Section 8.47, the Subscription-Id-Type AVP includes
   Enumerated type values 0 - 4.  IANA has created and is maintaining a
   namespace for this AVP.  All remaining values are available for
   assignment by a Designated Expert [RFC2434].

<=
div>Excuse me in advance if what I'm asking about are well-known things=
.
But still please clarify them at least for me...

=

Thanks a lot in advance!

/Misha

2017-01-25 11=
:29 GMT+03:00 Yuval Lifshitz <ylifshitz@sandvine.com>:<=
br>











Hi Maryse,


The idea is the follow=
ing: 



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
If the CC client want to work with RFC4006bis only CC server, and w=
ant to make sure that the subscription ID is understood by the server, it m=
ay set the M-bit. Any RFC4006 server
 will reply with DIAMETER_AVP_UNSUPPORTED (5001)


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
If the CC client is not sure whether the CC servers are RFC4006 or =
RFC4006bis, or have a mix of servers, and want to work with both, it may no=
t set the M-bit



o=C2=A0=C2=A0
In this case it would send both AVPs for the old types, so that the=
 new AVP will be ignored by the RFC4006 servers



o=C2=A0=C2=A0
In a case of a new type of subscription, not covered in RFC4006, it=
 may send the new AVP with the M-bit set, causing any old server to reply w=
ith DIAMETER_AVP_UNSUPPORTED (5001).
 It may also send the new AVP without the M-bit set, here the server would =
just ignore the AVP, but would probably reply DIAMETER_MISSING_AVP (5005) a=
s it will not have any subscription ID


=C2=A0


Yuval


=C2=A0






From: Gardella=
, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]


Sent: Tuesday, January 24, 2017 5:25 PM

To: Yuval Lifshitz; dime@ietf.org

Subject: RE: RFC4006bis - Subscription-Id-Extension AVP






=C2=A0


Hi Yuval, 


=C2=A0


Thanks for continuing on this.


I am not sure to understand the difference between =
=E2=80=9Cmay=E2=80=9D and =E2=80=9Cmust=E2=80=9D, since with =C2=A0=E2=80=
=9CMay=E2=80=9D we can end having the M-bit set by the RFC4006bis CC client=
.


I guess from the protocol=E2=80=99s perspective =E2=
=80=9Cmay=E2=80=9D and =E2=80=9Cmust=E2=80=9D makes no difference right?=



=C2=A0


BR


Maryse


=C2=A0






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Yuval Lifshitz

Sent: vendredi 13 janvier 2017 15:24

To: dime@ietf.org=


Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP<=
/u>






=C2=A0


Hi All,


As part of the RFC4006bis work there are several AVP=
s that we plan on making future proof (See also:
htt=
ps://trac.ietf.org/trac/dime/ticket/95). For example, Subscription=
-Id AVP cannot be extended to new types without changing the enumeration in=
 Subscription-Id-Type AVP, which in turn requires a new application
 ID (something we really want to avoid).


To solve this issue we propose adding a new, extenda=
ble AVP. In this example:


=C2=A0


Subscription-Id-Extension ::=3D < AVP Heade=
r: XXX >


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ Subscription-Id-E164 ]


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ Subscription-Id-IMSI ]


=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[ Subscription-Id-SIP-URI ]=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ Subscription-Id-NAI ]=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ Subscription-Id-Private =
]


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *[ AVP ]

=C2=A0


When looking into Subscription-ID-Extension AVP =C2=
=A0header flags I ran into a problem. The existing Subscription-ID AVP (and=
 its sub-AVPs) are all marked with the M-bit as a =E2=80=9Cmust=E2=80=9D, p=
robably because they hold the subscriber=E2=80=99s name which is
 critical information.


However, in order for a RFC4006bis CC client to be a=
ble to communicate with an RFC4006 CC-server, they will have to be marked a=
s =E2=80=9Cmay=E2=80=9D.



=C2=A0


Would appreciate your point of view on that topic?


=C2=A0


Best Regards,


=C2=A0


Yuval


=C2=A0







_______________________________________________

DiME mailing list

DiME@ietf.org

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





--94eb2c1cdb0a7a78da05472df777--


From nobody Sun Jan 29 00:29:40 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78B2126FDC for ; Sun, 29 Jan 2017 00:29:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.434
X-Spam-Level: 
X-Spam-Status: No, score=-4.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 vNbF4u3F_3C8 for ; Sun, 29 Jan 2017 00:29:37 -0800 (PST)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0523124281 for ; Sun, 29 Jan 2017 00:29:36 -0800 (PST)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Sun, 29 Jan 2017 03:29:33 -0500
From: Yuval Lifshitz 
To: Misha Zaytsev 
Thread-Topic: [Dime] RFC4006bis - Subscription-Id-Extension AVP
Thread-Index: AdJtpzBPVPEgVuSXSxiP12VbbHIMngFfVP8wAO+8a8AAvDx6gAALc80g
Date: Sun, 29 Jan 2017 08:29:33 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.142.2]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "dime@ietf.org" , "Gardella, Maryse \(Nokia - FR\)" 
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jan 2017 08:29:39 -0000

SGkgTWlzaGEsDQpUaGVyZSBpcyBub3RoaW5nIOKAnHdlbGwga25vd27igJ0gaW4gdGhlc2UgaXNz
dWVzIGFuZCBJ4oCZbGwgYmUgaGFwcHkgdG8gY2xhcmlmeSENCg0KKDEpIER1cmluZyBJRVRGOTYg
YSBxdWVzdGlvbiBjYW1lIHJlZ2FyZGluZyB0aGUgc3VwcG9ydCBvZiB0aGUgSU1FSSB1c2VyIGVx
dWlwbWVudCB0eXBlIOKAkyBjdXJyZW50bHkgbm90IG9uZSBvZiB0aGUgZW51bWVyYXRlZCB0eXBl
cyBvZiB0aGUgVXNlci1FcXVpcG1lbnQtSW5mby1UeXBlIEFWUCAoSU1FSVNWIGlzIHRoZXJlIGJ1
dCBub3QgSU1FSSkuIEFzIGEgcmVzdWx0IG9mIHRoaXMgZGlzY3Vzc2lvbiwgYW5kIGR1ZSB0byB0
aGUgZW51bSBleHRlbnNpb24gbGltaXRhdGlvbnMgKHNlZSBoZXJlOiBodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvcmZjNzQyMyNzZWN0aW9uLTUuNiksIHdlIHdlcmUgYXNrZWQgdG8gZG8gYW4g
YW5hbHlzaXMgb24gd2hpY2ggZW51bWVyYXRlZCBBVlBzIHJlcXVpcmVzIGV4dGVuc2liaWxpdHku
IFRoZSByZXN1bHRzIHdlcmUgY2FwdHVyZWQgaW4gdGhlIGZvbGxvd2luZyB0aWNrZXQ6IGh0dHBz
Oi8vdHJhYy5pZXRmLm9yZy90cmFjL2RpbWUvdGlja2V0Lzk1ICANCkZvciBiZXR0ZXIgY2xhcml0
eSBJ4oCZbSBwb3N0aW5nIGhlcmUgdGhlIGFjdHVhbCBhbmFseXNpcyBvZiBBVlBzLiBTb21lIG9m
IHRoZW0gZGlkbuKAmXQgbmVlZCB0byBiZSBleHRlbnNpYmxlIChpbiBvdXIgdmlldyksIHNvbWUg
b2YgdGhlbSB3ZXJlIGFscmVhZHkgZXh0ZW5zaWJsZSBhbmQgdGhlIHJlc3Qgd2VyZSBhZGRlZCB0
byB0aGUgdGlja2V0Og0KDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IEFWUMKgIFNlY3Rpb27CoMKgwqDCoMKgwqDCoMKgwqDCoCANCsKgwqDCoEF0dHJpYnV0ZSBOYW1l
wqDCoMKgIENvZGUgRGVmaW5lZCBEYXRhIFR5cGUgDQrCoMKgwqAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KwqDCoCBDQy1Nb25lecKgwqDCoMKgwqDCoMKgwqDCoCA0
MTPCoCA4LjIywqDCoCBHcm91cGVkwqDCoMKgIC0gbm90IGV4dGVuc2libGUsIGRvZXMgbm90IG5l
ZWQgdG8gYmUNCsKgwqAgQ29zdC1JbmZvcm1hdGlvbsKgIDQyM8KgIDguN8KgwqDCoCBHcm91cGVk
wqDCoMKgIC0gbm90IGV4dGVuc2libGUsIGRvZXMgbm90IG5lZWQgdG8gYmUNCsKgwqAgRmluYWwt
VW5pdC3CoMKgwqDCoMKgwqAgNDMwwqAgOC4zNMKgwqAgR3JvdXBlZMKgwqDCoCAtIG5vdCBleHRl
bnNpYmxlLCB3aWxsIGJlIHJlcGxhY2VkIGJ5IFFvUy1GaW5hbC1Vbml0LUluZGljYXRpb24gdGhh
dCB3aWxsIGJlIGV4dGVuc2libGUNCsKgwqDCoMKgIEluZGljYXRpb27CoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCANCsKgwqDCoEdyYW50ZWQt
U2VydmljZS3CoCA0MzHCoCA4LjE3wqDCoCBHcm91cGVkwqDCoMKgIC0gZXh0ZW5zaWJsZQ0KwqDC
oMKgwqAgVW5pdMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoA0KwqDCoMKgRy1TLVUtUG9vbC3CoMKgwqDCoMKgwqAgNDU3
wqAgOC4zMMKgwqAgR3JvdXBlZMKgwqDCoCAtIG5vdCBleHRlbnNpYmxlLCBkb2VzIG5vdCBuZWVk
IHRvIGJlDQrCoMKgwqDCoCBSZWZlcmVuY2XCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIA0KwqDCoMKgTXVsdGlwbGUtU2VydmljZXMgNDU2
wqAgOC4xNsKgwqAgR3JvdXBlZMKgwqDCoCAtIGV4dGVuc2libGUNCsKgwqDCoCAtQ3JlZGl0LUNv
bnRyb2zCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgDQrC
oMKgwqBSZWRpcmVjdC1TZXJ2ZXLCoMKgIDQzNMKgIDguMzfCoMKgIEdyb3VwZWTCoMKgwqAgLSBu
b3QgZXh0ZW5zaWJsZSwgaGFzIGEgcHJvYmxlbSBzaW1pbGFyIHRvIGVxdWlwbWVudCB0eXBlIGFz
IGl0IGNvbnRhaW5zIGFuIGVudW1lcmF0ZWQgdHlwZS92YWx1ZSBBVlBzDQrCoMKgIFJlcXVlc3Rl
ZC1TZXJ2aWNlIDQzN8KgIDguMTjCoMKgIEdyb3VwZWTCoMKgwqAgLSBleHRlbnNpYmxlDQrCoMKg
wqDCoCAtVW5pdMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCANCsKgwqDCoFNlcnZpY2UtUGFyYW1ldGVyIDQ0MMKgIDguNDPC
oMKgIEdyb3VwZWTCoMKgwqAgLSBub3QgZXh0ZW5zaWJsZSwgZG9lcyBub3QgbmVlZCB0byBiZQ0K
wqDCoMKgwqAgLUluZm/CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgDQrCoMKgwqBTdWJzY3JpcHRpb24tSWTCoMKgIDQ0M8Kg
IDguNDbCoMKgIEdyb3VwZWTCoMKgwqAgLSBub3QgZXh0ZW5zaWJsZSwgaGFzIGEgcHJvYmxlbSBz
aW1pbGFyIHRvIGVxdWlwbWVudCB0eXBlIGFzIGl0IGNvbnRhaW5zIGFuIGVudW1lcmF0ZWQgdHlw
ZS92YWx1ZSBBVlBzDQrCoMKgIFVuaXQtVmFsdWXCoMKgwqDCoMKgwqDCoCA0NDXCoCA4LjjCoCDC
oMKgR3JvdXBlZMKgwqDCoCAtIG5vdCBleHRlbnNpYmxlLCBkb2VzIG5vdCBuZWVkIHRvIGJlDQrC
oMKgIFVzZWQtU2VydmljZS1Vbml0IDQ0NsKgIDguMTnCoMKgIEdyb3VwZWTCoMKgwqAgLSBleHRl
bnNpYmxlDQrCoMKgIFVzZXItRXF1aXBtZW50wqDCoMKgIDQ1OMKgIDguNDnCoMKgIEdyb3VwZWTC
oMKgwqAgLSBub3QgZXh0ZW5zaWJsZSwgd2lsbCBiZSByZXBsYWNlZCBieSBhbiBBVlAgdGhhdCB3
aWxsIGJlIGV4dGVuc2libGUNCsKgwqDCoMKgIC1JbmZvwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIA0KDQpXb3VsZCBhcHBy
ZWNpYXRlIHlvdXIgY29tbWVudHMgaWYgeW91IHRoaW5rIGRpZmZlcmVudGx5IGFib3V0IGFueSBv
ZiB0aGUgQVZQcyBhYm92ZSwgb3IgdGhhdCB3ZSBoYXZlIG1pc3NlZCBvdGhlciBBVlBzIHRoYXQg
bmVlZHMgdG8uDQoNCigyKSBFLmcgYWRkaW5nIG5ldyBzdWJzY3JpcHRpb24gSUQuIA0KDQpVbmxp
a2UgU3Vic2NyaXB0aW9uLUlkLVR5cGUgQVZQIHdoaWNoIGNhbm5vdCBiZSBleHRlbmRlZCB0byBh
IG5ldyB0eXBlIHdpdGhvdXQgYSBuZXcgYXBwbGljYXRpb24gSUQsIGEgbmV3IEFWUCBiZWluZyBw
cm9wb3NlZCBpbiBSRkM0MDA2YmlzIGlzOg0KDQogIFN1YnNjcmlwdGlvbi1JZC1FeHRlbnNpb24g
Ojo9IDwgQVZQIEhlYWRlcjogWFhYID4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWyBT
dWJzY3JpcHRpb24tSWQtRTE2NCBdDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsgU3Vi
c2NyaXB0aW9uLUlkLUlNU0kgXQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIFN1YnNj
cmlwdGlvbi1JZC1TSVAtVVJJIF0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWyBTdWJz
Y3JpcHRpb24tSWQtTkFJIF0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWyBTdWJzY3Jp
cHRpb24tSWQtUHJpdmF0ZSBdDQogICAgICAgICAgICAgICAgICAgICAgICAgICAqWyBBVlAgXQ0K
DQpTbywgaW4gb3JkZXIgdG8gYWRkIGEgbmV3IHR5cGUgKHBvc3QgUkZDNDAwNmJpcyksIHlvdSB3
b3VsZCBuZWVkIHRvIHN1Ym1pdCBkcmFmdCB3aXRoIGFuIEFWUCBkZWZpbml0aW9uIGluIGl0IHRv
IGNvdWxkIGJlIGFkZGVkIHRvIHRoZSBTdWJzY3JpcHRpb24tSWQtRXh0ZW5zaW9uIGFzIGl0IGlz
IGV4dGVuc2libGUuDQpUaGlzIG5ldyBkcmFmdCB3b3VsZCBiZSBjb21wbGlhbnQgd2l0aCBSRkM0
MDA2YmlzIGFuZCB3aWxsIHRoZXJlZm9yZSBub3QgcmVxdWlyZSBhIG5ldyBhcHBsaWNhdGlvbiBJ
RC4NCg0KQmVzdCBSZWdhcmRzLA0KDQpZdXZhbA0KDQoNCkZyb206IE1pc2hhIFpheXRzZXYgW21h
aWx0bzptaXNoYS56YXl0c2V2LnJ1c0BnbWFpbC5jb21dIA0KU2VudDogU2F0dXJkYXksIEphbnVh
cnkgMjgsIDIwMTcgMTE6MDcgUE0NClRvOiBZdXZhbCBMaWZzaGl0eg0KQ2M6IEdhcmRlbGxhLCBN
YXJ5c2UgKE5va2lhIC0gRlIpOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFJG
QzQwMDZiaXMgLSBTdWJzY3JpcHRpb24tSWQtRXh0ZW5zaW9uIEFWUA0KDQpIaSBZdXZhbCwNCg0K
TWF5IEkgYXNrIHlvdSBzZXZlcmFsIHF1ZXN0aW9ucyB0byBiZSBhYmxlIHRvIHVuZGVyc3RhbmQg
dGhlIHdob2xlIHNpdHVhdGlvbjoNCg0KMS4gV2h5IGFyZSB5b3UgcHJvcG9zaW5nIHRvIGFkZCBu
ZXcgZXh0ZW5kYWJsZSBBVlBzIG9ubHkgZm9yIHNvbWUgb2YgdGhlIEFWUHMgbGlzdGVkIGluIHNl
Y3Rpb24gMTI/DQpJIHRoaW5rIHRoZSBzYW1lIGNvbmNlcm4gaXMgYXBwbGljYWJsZSBmb3IgYWxs
IHRoZXNlIEFWUHMsIGlzbid0Pw0KDQoyLiBDb3VsZCB5b3UgY2xhcmlmeSB3aGF0IG9mZmljaWFs
IHByb2NlZHVyZSB0byBhc3NpZ24gbmV3IGF2YWlsYWJsZSB2YWx1ZXMgaXMgbWVhbnQgaGVyZT8N
Ckl0IGlzIG5vdCB3b3JraW5nIHcvbyBkZWZpbmluZyBuZXcgQXBwbGljYXRpb24tSUQgYXMgeW91
IG1lbnRpb25lZCBhYm92ZT8NCg0KDQoxMi4xNi4gIFN1YnNjcmlwdGlvbi1JZC1UeXBlIEFWUA0K
DQogICBBcyBkZWZpbmVkIGluIFNlY3Rpb24gOC40NywgdGhlIFN1YnNjcmlwdGlvbi1JZC1UeXBl
IEFWUCBpbmNsdWRlcw0KICAgRW51bWVyYXRlZCB0eXBlIHZhbHVlcyAwIC0gNC4gIElBTkEgaGFz
IGNyZWF0ZWQgYW5kIGlzIG1haW50YWluaW5nIGENCiAgIG5hbWVzcGFjZSBmb3IgdGhpcyBBVlAu
ICBBbGwgcmVtYWluaW5nIHZhbHVlcyBhcmUgYXZhaWxhYmxlIGZvcg0KICAgYXNzaWdubWVudCBi
eSBhIERlc2lnbmF0ZWQgRXhwZXJ0IFtSRkMyNDM0XS4NCg0KRXhjdXNlIG1lIGluIGFkdmFuY2Ug
aWYgd2hhdCBJJ20gYXNraW5nIGFib3V0IGFyZSB3ZWxsLWtub3duIHRoaW5ncy4NCkJ1dCBzdGls
bCBwbGVhc2UgY2xhcmlmeSB0aGVtIGF0IGxlYXN0IGZvciBtZS4uLg0KDQpUaGFua3MgYSBsb3Qg
aW4gYWR2YW5jZSENCg0KL01pc2hhDQoNCjIwMTctMDEtMjUgMTE6MjkgR01UKzAzOjAwIFl1dmFs
IExpZnNoaXR6IDx5bGlmc2hpdHpAc2FuZHZpbmUuY29tPjoNCkhpIE1hcnlzZSwNClRoZSBpZGVh
IGlzIHRoZSBmb2xsb3dpbmc6IA0K4oCiwqDCoMKgwqDCoMKgwqDCoCBJZiB0aGUgQ0MgY2xpZW50
IHdhbnQgdG8gd29yayB3aXRoIFJGQzQwMDZiaXMgb25seSBDQyBzZXJ2ZXIsIGFuZCB3YW50IHRv
IG1ha2Ugc3VyZSB0aGF0IHRoZSBzdWJzY3JpcHRpb24gSUQgaXMgdW5kZXJzdG9vZCBieSB0aGUg
c2VydmVyLCBpdCBtYXkgc2V0IHRoZSBNLWJpdC4gQW55IFJGQzQwMDYgc2VydmVyIHdpbGwgcmVw
bHkgd2l0aCBESUFNRVRFUl9BVlBfVU5TVVBQT1JURUQgKDUwMDEpDQrigKLCoMKgwqDCoMKgwqDC
oMKgIElmIHRoZSBDQyBjbGllbnQgaXMgbm90IHN1cmUgd2hldGhlciB0aGUgQ0Mgc2VydmVycyBh
cmUgUkZDNDAwNiBvciBSRkM0MDA2YmlzLCBvciBoYXZlIGEgbWl4IG9mIHNlcnZlcnMsIGFuZCB3
YW50IHRvIHdvcmsgd2l0aCBib3RoLCBpdCBtYXkgbm90IHNldCB0aGUgTS1iaXQNCm/CoMKgIElu
IHRoaXMgY2FzZSBpdCB3b3VsZCBzZW5kIGJvdGggQVZQcyBmb3IgdGhlIG9sZCB0eXBlcywgc28g
dGhhdCB0aGUgbmV3IEFWUCB3aWxsIGJlIGlnbm9yZWQgYnkgdGhlIFJGQzQwMDYgc2VydmVycw0K
b8KgwqAgSW4gYSBjYXNlIG9mIGEgbmV3IHR5cGUgb2Ygc3Vic2NyaXB0aW9uLCBub3QgY292ZXJl
ZCBpbiBSRkM0MDA2LCBpdCBtYXkgc2VuZCB0aGUgbmV3IEFWUCB3aXRoIHRoZSBNLWJpdCBzZXQs
IGNhdXNpbmcgYW55IG9sZCBzZXJ2ZXIgdG8gcmVwbHkgd2l0aCBESUFNRVRFUl9BVlBfVU5TVVBQ
T1JURUQgKDUwMDEpLiBJdCBtYXkgYWxzbyBzZW5kIHRoZSBuZXcgQVZQIHdpdGhvdXQgdGhlIE0t
Yml0IHNldCwgaGVyZSB0aGUgc2VydmVyIHdvdWxkIGp1c3QgaWdub3JlIHRoZSBBVlAsIGJ1dCB3
b3VsZCBwcm9iYWJseSByZXBseSBESUFNRVRFUl9NSVNTSU5HX0FWUCAoNTAwNSkgYXMgaXQgd2ls
bCBub3QgaGF2ZSBhbnkgc3Vic2NyaXB0aW9uIElEDQrCoA0KWXV2YWwNCsKgDQpGcm9tOiBHYXJk
ZWxsYSwgTWFyeXNlIChOb2tpYSAtIEZSKSBbbWFpbHRvOm1hcnlzZS5nYXJkZWxsYUBub2tpYS5j
b21dIA0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyNCwgMjAxNyA1OjI1IFBNDQpUbzogWXV2YWwg
TGlmc2hpdHo7IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBSRkM0MDA2YmlzIC0gU3Vic2Ny
aXB0aW9uLUlkLUV4dGVuc2lvbiBBVlANCsKgDQpIaSBZdXZhbCwgDQrCoA0KVGhhbmtzIGZvciBj
b250aW51aW5nIG9uIHRoaXMuDQpJIGFtIG5vdCBzdXJlIHRvIHVuZGVyc3RhbmQgdGhlIGRpZmZl
cmVuY2UgYmV0d2VlbiDigJxtYXnigJ0gYW5kIOKAnG11c3TigJ0sIHNpbmNlIHdpdGggwqDigJxN
YXnigJ0gd2UgY2FuIGVuZCBoYXZpbmcgdGhlIE0tYml0IHNldCBieSB0aGUgUkZDNDAwNmJpcyBD
QyBjbGllbnQuDQpJIGd1ZXNzIGZyb20gdGhlIHByb3RvY29s4oCZcyBwZXJzcGVjdGl2ZSDigJxt
YXnigJ0gYW5kIOKAnG11c3TigJ0gbWFrZXMgbm8gZGlmZmVyZW5jZSByaWdodD8NCsKgDQpCUg0K
TWFyeXNlDQrCoA0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIFl1dmFsIExpZnNoaXR6DQpTZW50OiB2ZW5kcmVkaSAxMyBqYW52aWVyIDIwMTcg
MTU6MjQNClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBbQUxVXSBbRGltZV0gUkZDNDAwNmJp
cyAtIFN1YnNjcmlwdGlvbi1JZC1FeHRlbnNpb24gQVZQDQrCoA0KSGkgQWxsLA0KQXMgcGFydCBv
ZiB0aGUgUkZDNDAwNmJpcyB3b3JrIHRoZXJlIGFyZSBzZXZlcmFsIEFWUHMgdGhhdCB3ZSBwbGFu
IG9uIG1ha2luZyBmdXR1cmUgcHJvb2YgKFNlZSBhbHNvOiBodHRwczovL3RyYWMuaWV0Zi5vcmcv
dHJhYy9kaW1lL3RpY2tldC85NSkuIEZvciBleGFtcGxlLCBTdWJzY3JpcHRpb24tSWQgQVZQIGNh
bm5vdCBiZSBleHRlbmRlZCB0byBuZXcgdHlwZXMgd2l0aG91dCBjaGFuZ2luZyB0aGUgZW51bWVy
YXRpb24gaW4gU3Vic2NyaXB0aW9uLUlkLVR5cGUgQVZQLCB3aGljaCBpbiB0dXJuIHJlcXVpcmVz
IGEgbmV3IGFwcGxpY2F0aW9uIElEIChzb21ldGhpbmcgd2UgcmVhbGx5IHdhbnQgdG8gYXZvaWQp
Lg0KVG8gc29sdmUgdGhpcyBpc3N1ZSB3ZSBwcm9wb3NlIGFkZGluZyBhIG5ldywgZXh0ZW5kYWJs
ZSBBVlAuIEluIHRoaXMgZXhhbXBsZToNCsKgDQpTdWJzY3JpcHRpb24tSWQtRXh0ZW5zaW9uIDo6
PSA8IEFWUCBIZWFkZXI6IFhYWCA+DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBbIFN1YnNjcmlwdGlvbi1JZC1FMTY0IF0NCsKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFsgU3Vic2Ny
aXB0aW9uLUlkLUlNU0kgXQ0KwqDCoMKgIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgWyBTdWJzY3JpcHRpb24tSWQtU0lQLVVSSSBdDQrCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBbIFN1YnNjcmlw
dGlvbi1JZC1OQUkgXQ0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgWyBTdWJzY3JpcHRpb24tSWQtUHJpdmF0ZSBdDQrCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKlsgQVZQIF0NCsKgDQpX
aGVuIGxvb2tpbmcgaW50byBTdWJzY3JpcHRpb24tSUQtRXh0ZW5zaW9uIEFWUCDCoGhlYWRlciBm
bGFncyBJIHJhbiBpbnRvIGEgcHJvYmxlbS4gVGhlIGV4aXN0aW5nIFN1YnNjcmlwdGlvbi1JRCBB
VlAgKGFuZCBpdHMgc3ViLUFWUHMpIGFyZSBhbGwgbWFya2VkIHdpdGggdGhlIE0tYml0IGFzIGEg
4oCcbXVzdOKAnSwgcHJvYmFibHkgYmVjYXVzZSB0aGV5IGhvbGQgdGhlIHN1YnNjcmliZXLigJlz
IG5hbWUgd2hpY2ggaXMgY3JpdGljYWwgaW5mb3JtYXRpb24uDQpIb3dldmVyLCBpbiBvcmRlciBm
b3IgYSBSRkM0MDA2YmlzIENDIGNsaWVudCB0byBiZSBhYmxlIHRvIGNvbW11bmljYXRlIHdpdGgg
YW4gUkZDNDAwNiBDQy1zZXJ2ZXIsIHRoZXkgd2lsbCBoYXZlIHRvIGJlIG1hcmtlZCBhcyDigJxt
YXnigJ0uIA0KwqANCldvdWxkIGFwcHJlY2lhdGUgeW91ciBwb2ludCBvZiB2aWV3IG9uIHRoYXQg
dG9waWM/DQrCoA0KQmVzdCBSZWdhcmRzLA0KwqANCll1dmFsDQrCoA0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRp
TUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K
DQo=


From nobody Sun Jan 29 10:20:52 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755DC129431 for ; Sun, 29 Jan 2017 10:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyJG8aS7rMG9 for ; Sun, 29 Jan 2017 10:20:47 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0547B12940A for ; Sun, 29 Jan 2017 10:20:47 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id z134so184602384lff.3 for ; Sun, 29 Jan 2017 10:20:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MjCyiSJ6+70AHaWVd+cKgx1JyNHUUVDX/q66TRAoTUE=; b=BzfHzpRVkl+4jmiPy21WUY4aMsUuDsc0t8BEg1c3s3pKmc04mpSLaebW8lQzd+xAdW sL9gQ/8LO4fpT3mMqV4NZLela4mrJvtmuEsMADriQ82log1BTjRKoEGGYbkMIG33zMBk YqbZC2db8hzCio712MwDLvCS9AB+H2pKM81VZKW33rpPIUA5QXeaC2pvNe8gL1F8N42n O6OYAWeRa4Q/icGobja8IRmW3bfqpHCgwvT9X5yLPN0NO1w0WVS7IKI90a3Vi7CZJvn2 9zxA/vTvhy5jc2E2y+RaOFcNyAZpWbSpPNGzFtwcDAPCLwRizFsH35kJW9iYXsuaAXSW 66Og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MjCyiSJ6+70AHaWVd+cKgx1JyNHUUVDX/q66TRAoTUE=; b=NEdTE4FqZ0QojJtBmiW2fwtSZM2dv4dqGXXHiWls7+XsjZ0HRgiinYxBwY79cYM0Pc nv1TrNCXz8Y4yQbscuc14wy/Vl+ZOeuN1NXIOc9ygQ3w1uEeZSh+qrEO5baKMLwLEXkg 3dN3q8CT772n5LV2lS4H7hz2W3dYlJE0HGg40TL9nSJeknsz0Y/ICPSihbT+RnWeXH5r lwrwVKBUqS5DQEnyNuGan8FqEGdWHDoc/8n06yTsxOnNPMDzj727GExmjnSa/p9U4COf eN6KvaiHYjd7rgvsquj13FF+xYAox3f5knXyVnpV5buwbdtYYNw21OnrnjugcJ6ILyIC j/PA==
X-Gm-Message-State: AIkVDXICuS+H53qRt5/W28uG1QOeV6Yu/H8sTWK02HF0Grckr7r/44mWknUcOBAy+mVLAfEDVDSeOoWuh+h2ow==
X-Received: by 10.25.79.79 with SMTP id a15mr5904002lfk.58.1485714045140; Sun, 29 Jan 2017 10:20:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Sun, 29 Jan 2017 10:20:44 -0800 (PST)
In-Reply-To: 
References:     
From: Misha Zaytsev 
Date: Sun, 29 Jan 2017 21:20:44 +0300
Message-ID: 
To: Yuval Lifshitz 
Content-Type: multipart/alternative; boundary=94eb2c1cdb0ae605c305473fc1bd
Archived-At: 
Cc: "dime@ietf.org" , "Gardella, Maryse \(Nokia - FR\)" 
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jan 2017 18:20:50 -0000

--94eb2c1cdb0ae605c305473fc1bd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Yuval,

Thanks a lot for your clarifications! Now it seems I see your concern.

As I can see the problem is that there is no possibility to extend the
defined AVPs of type Enumerated in a backward compatible way. For me it
means that all enumerate AVPs defined in RFC4006 (listed in section 12) is
a matter of your investigation. Not the grouped ones, but the ones that are
used as indicators in these grouped AVPs.

Following the recommendations in https://tools.ietf.org/html/
rfc7423#section-5.6 that you pointed out, I think bitmask based AVPs may be
a way out in the current situation. Such AVP will be marked as mandatory.
While only one bit of this bitmask MUST be set.

 Subscription-Id-Extension ::=3D < AVP Header: XXX >
                             [ Subscription-Id-Type-Indicator ]
                             [Subscrition-Id-Data]

Have you considered this option? Or probably I'm missing something..

However, if we follow the way you are proposing with several mutually
exclusive AVPs, then these AVPs should be marked as not mandatory. While in
the description of the appropriate grouped AVP it should be stated that
only one of these AVPs MUST be present.

/Misha


2017-01-29 11:29 GMT+03:00 Yuval Lifshitz :

> Hi Misha,
> There is nothing =E2=80=9Cwell known=E2=80=9D in these issues and I=E2=80=
=99ll be happy to clarify!
>
> (1) During IETF96 a question came regarding the support of the IMEI user
> equipment type =E2=80=93 currently not one of the enumerated types of the
> User-Equipment-Info-Type AVP (IMEISV is there but not IMEI). As a result =
of
> this discussion, and due to the enum extension limitations (see here:
> https://tools.ietf.org/html/rfc7423#section-5.6), we were asked to do an
> analysis on which enumerated AVPs requires extensibility. The results wer=
e
> captured in the following ticket: https://trac.ietf.org/trac/
> dime/ticket/95
> For better clarity I=E2=80=99m posting here the actual analysis of AVPs. =
Some of
> them didn=E2=80=99t need to be extensible (in our view), some of them wer=
e already
> extensible and the rest were added to the ticket:
>
>                      AVP  Section
>    Attribute Name    Code Defined Data Type
>    -----------------------------------------
>    CC-Money          413  8.22   Grouped    - not extensible, does not
> need to be
>    Cost-Information  423  8.7    Grouped    - not extensible, does not
> need to be
>    Final-Unit-       430  8.34   Grouped    - not extensible, will be
> replaced by QoS-Final-Unit-Indication that will be extensible
>      Indication
>    Granted-Service-  431  8.17   Grouped    - extensible
>      Unit
>    G-S-U-Pool-       457  8.30   Grouped    - not extensible, does not
> need to be
>      Reference
>    Multiple-Services 456  8.16   Grouped    - extensible
>     -Credit-Control
>    Redirect-Server   434  8.37   Grouped    - not extensible, has a
> problem similar to equipment type as it contains an enumerated type/value
> AVPs
>    Requested-Service 437  8.18   Grouped    - extensible
>      -Unit
>    Service-Parameter 440  8.43   Grouped    - not extensible, does not
> need to be
>      -Info
>    Subscription-Id   443  8.46   Grouped    - not extensible, has a
> problem similar to equipment type as it contains an enumerated type/value
> AVPs
>    Unit-Value        445  8.8    Grouped    - not extensible, does not
> need to be
>    Used-Service-Unit 446  8.19   Grouped    - extensible
>    User-Equipment    458  8.49   Grouped    - not extensible, will be
> replaced by an AVP that will be extensible
>      -Info
>
> Would appreciate your comments if you think differently about any of the
> AVPs above, or that we have missed other AVPs that needs to.
>
> (2) E.g adding new subscription ID.
>
> Unlike Subscription-Id-Type AVP which cannot be extended to a new type
> without a new application ID, a new AVP being proposed in RFC4006bis is:
>
>   Subscription-Id-Extension ::=3D < AVP Header: XXX >
>                              [ Subscription-Id-E164 ]
>                              [ Subscription-Id-IMSI ]
>                              [ Subscription-Id-SIP-URI ]
>                              [ Subscription-Id-NAI ]
>                              [ Subscription-Id-Private ]
>                            *[ AVP ]
>
> So, in order to add a new type (post RFC4006bis), you would need to submi=
t
> draft with an AVP definition in it to could be added to the
> Subscription-Id-Extension as it is extensible.
> This new draft would be compliant with RFC4006bis and will therefore not
> require a new application ID.
>
> Best Regards,
>
> Yuval
>
>
> From: Misha Zaytsev [mailto:misha.zaytsev.rus@gmail.com]
> Sent: Saturday, January 28, 2017 11:07 PM
> To: Yuval Lifshitz
> Cc: Gardella, Maryse (Nokia - FR); dime@ietf.org
> Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
> Hi Yuval,
>
> May I ask you several questions to be able to understand the whole
> situation:
>
> 1. Why are you proposing to add new extendable AVPs only for some of the
> AVPs listed in section 12?
> I think the same concern is applicable for all these AVPs, isn't?
>
> 2. Could you clarify what official procedure to assign new available
> values is meant here?
> It is not working w/o defining new Application-ID as you mentioned above?
>
>
> 12.16.  Subscription-Id-Type AVP
>
>    As defined in Section 8.47, the Subscription-Id-Type AVP includes
>    Enumerated type values 0 - 4.  IANA has created and is maintaining a
>    namespace for this AVP.  All remaining values are available for
>    assignment by a Designated Expert [RFC2434].
>
> Excuse me in advance if what I'm asking about are well-known things.
> But still please clarify them at least for me...
>
> Thanks a lot in advance!
>
> /Misha
>
> 2017-01-25 11:29 GMT+03:00 Yuval Lifshitz :
> Hi Maryse,
> The idea is the following:
> =E2=80=A2         If the CC client want to work with RFC4006bis only CC s=
erver,
> and want to make sure that the subscription ID is understood by the serve=
r,
> it may set the M-bit. Any RFC4006 server will reply with
> DIAMETER_AVP_UNSUPPORTED (5001)
> =E2=80=A2         If the CC client is not sure whether the CC servers are=
 RFC4006
> or RFC4006bis, or have a mix of servers, and want to work with both, it m=
ay
> not set the M-bit
> o   In this case it would send both AVPs for the old types, so that the
> new AVP will be ignored by the RFC4006 servers
> o   In a case of a new type of subscription, not covered in RFC4006, it
> may send the new AVP with the M-bit set, causing any old server to reply
> with DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP withou=
t
> the M-bit set, here the server would just ignore the AVP, but would
> probably reply DIAMETER_MISSING_AVP (5005) as it will not have any
> subscription ID
>
> Yuval
>
> From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]
> Sent: Tuesday, January 24, 2017 5:25 PM
> To: Yuval Lifshitz; dime@ietf.org
> Subject: RE: RFC4006bis - Subscription-Id-Extension AVP
>
> Hi Yuval,
>
> Thanks for continuing on this.
> I am not sure to understand the difference between =E2=80=9Cmay=E2=80=9D =
and =E2=80=9Cmust=E2=80=9D, since
> with  =E2=80=9CMay=E2=80=9D we can end having the M-bit set by the RFC400=
6bis CC client.
> I guess from the protocol=E2=80=99s perspective =E2=80=9Cmay=E2=80=9D and=
 =E2=80=9Cmust=E2=80=9D makes no
> difference right?
>
> BR
> Maryse
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz
> Sent: vendredi 13 janvier 2017 15:24
> To: dime@ietf.org
> Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
> Hi All,
> As part of the RFC4006bis work there are several AVPs that we plan on
> making future proof (See also: https://trac.ietf.org/trac/dime/ticket/95)=
.
> For example, Subscription-Id AVP cannot be extended to new types without
> changing the enumeration in Subscription-Id-Type AVP, which in turn
> requires a new application ID (something we really want to avoid).
> To solve this issue we propose adding a new, extendable AVP. In this
> example:
>
> Subscription-Id-Extension ::=3D < AVP Header: XXX >
>                              [ Subscription-Id-E164 ]
>                              [ Subscription-Id-IMSI ]
>                              [ Subscription-Id-SIP-URI ]
>                              [ Subscription-Id-NAI ]
>                              [ Subscription-Id-Private ]
>                             *[ AVP ]
>
> When looking into Subscription-ID-Extension AVP  header flags I ran into =
a
> problem. The existing Subscription-ID AVP (and its sub-AVPs) are all mark=
ed
> with the M-bit as a =E2=80=9Cmust=E2=80=9D, probably because they hold th=
e subscriber=E2=80=99s
> name which is critical information.
> However, in order for a RFC4006bis CC client to be able to communicate
> with an RFC4006 CC-server, they will have to be marked as =E2=80=9Cmay=E2=
=80=9D.
>
> Would appreciate your point of view on that topic?
>
> Best Regards,
>
> Yuval
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
>

--94eb2c1cdb0ae605c305473fc1bd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Yuval,

Thanks a lot for your clarifi=
cations! Now it seems I see your concern.

As I can=
 see the problem is that there is no possibility to extend the defined AVPs=
 of type Enumerated in a backward compatible way. For me it means that all =
enumerate AVPs defined in RFC4006 (listed in section 12) is a matter of you=
r investigation. Not the grouped ones, but the ones that are used as indica=
tors in these grouped AVPs.

Following the recommen=
dations in=C2=A0https://to=
ols.ietf.org/html/rfc7423#section-5.6=C2=A0that you pointed out, I=
 think bitmask based AVPs may be a way out in the current situation. Such A=
VP will be marked as mandatory. While only one bit of this bitmask MUST be =
set.

=C2=A0Subscription-Id-Extension ::=3D < AVP Header: XXX >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-I=
d-Type-Indicator=
=C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Subs=
crition-Id-Data]

Have you considered this option? Or pr=
obably I'm missing something..

However, if we follow=
 the way you are proposing with several mutually exclusive AVPs, then these=
 AVPs should be marked as not mandatory. While in the description of the ap=
propriate grouped AVP it should be stated that only one of these AVPs MUST =
be present.=C2=A0

/Misha=C2=A0


2017-01-29=
 11:29 GMT+03:00 Yuval Lifshitz <ylifshitz@sandvine.com>:
Hi Misha,

There is nothing =E2=80=9Cwell known=E2=80=9D in these issues and I=E2=80=
=99ll be happy to clarify!



(1) During IETF96 a question came regarding the support of the IMEI user eq=
uipment type =E2=80=93 currently not one of the enumerated types of the Use=
r-Equipment-Info-Type AVP (IMEISV is there but not IMEI). As a result of th=
is discussion, and due to the enum extension limitations (see here: https://tools.ietf.org/html/rfc7423#section-5.6), w=
e were asked to do an analysis on which enumerated AVPs requires extensibil=
ity. The results were captured in the following ticket: htt=
ps://trac.ietf.org/trac/dime/ticket/95

For better clarity I=E2=80=99m posting here the actual analysis of AVPs. So=
me of them didn=E2=80=99t need to be extensible (in our view), some of them=
 were already extensible and the rest were added to the ticket:



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AVP=C2=A0 Section=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Attribute Name=C2=A0=C2=A0=C2=A0 Code Defined Data Type
=C2=A0=C2=A0=C2=A0-----------------------------------------

=C2=A0=C2=A0 CC-Money=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 413=C2=A0 8.22=C2=A0=C2=A0 Grouped=C2=A0=C2=A0=C2=A0 - not extensible, doe=
s not need to be

=C2=A0=C2=A0 Cost-Information=C2=A0 423=C2=A0 8.7=C2=A0=C2=A0=C2=A0 Grouped=
=C2=A0=C2=A0=C2=A0 - not extensible, does not need to be

=C2=A0=C2=A0 Final-Unit-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 430=C2=A0 8.34=
=C2=A0=C2=A0 Grouped=C2=A0=C2=A0=C2=A0 - not extensible, will be replaced b=
y QoS-Final-Unit-Indication that will be extensible

=C2=A0=C2=A0=C2=A0=C2=A0 Indication=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Granted-Service-=C2=A0 431=C2=A0 8.17=C2=A0=C2=A0 Grouped=
=C2=A0=C2=A0=C2=A0 - extensible

=C2=A0=C2=A0=C2=A0=C2=A0 Unit=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0G-S-U-Pool-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 457=C2=A0=
 8.30=C2=A0=C2=A0 Grouped=C2=A0=C2=A0=C2=A0 - not extensible, does not need=
 to be

=C2=A0=C2=A0=C2=A0=C2=A0 Reference=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Multiple-Services 456=C2=A0 8.16=C2=A0=C2=A0 Grouped=C2=
=A0=C2=A0=C2=A0 - extensible

=C2=A0=C2=A0=C2=A0 -Credit-Control=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Redirect-Server=C2=A0=C2=A0 434=C2=A0 8.37=C2=A0=C2=A0 Gr=
ouped=C2=A0=C2=A0=C2=A0 - not extensible, has a problem similar to equipmen=
t type as it contains an enumerated type/value AVPs

=C2=A0=C2=A0 Requested-Service 437=C2=A0 8.18=C2=A0=C2=A0 Grouped=C2=A0=C2=
=A0=C2=A0 - extensible

=C2=A0=C2=A0=C2=A0=C2=A0 -Unit=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0

=C2=A0=C2=A0=C2=A0Service-Parameter 440=C2=A0 8.43=C2=A0=C2=A0 Grouped=C2=
=A0=C2=A0=C2=A0 - not extensible, does not need to be

=C2=A0=C2=A0=C2=A0=C2=A0 -Info=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0

=C2=A0=C2=A0=C2=A0Subscription-Id=C2=A0=C2=A0 443=C2=A0 8.46=C2=A0=C2=A0 Gr=
ouped=C2=A0=C2=A0=C2=A0 - not extensible, has a problem similar to equipmen=
t type as it contains an enumerated type/value AVPs

=C2=A0=C2=A0 Unit-Value=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 445=C2=A0=
 8.8=C2=A0 =C2=A0=C2=A0Grouped=C2=A0=C2=A0=C2=A0 - not extensible, does not=
 need to be

=C2=A0=C2=A0 Used-Service-Unit 446=C2=A0 8.19=C2=A0=C2=A0 Grouped=C2=A0=C2=
=A0=C2=A0 - extensible

=C2=A0=C2=A0 User-Equipment=C2=A0=C2=A0=C2=A0 458=C2=A0 8.49=C2=A0=C2=A0 Gr=
ouped=C2=A0=C2=A0=C2=A0 - not extensible, will be replaced by an AVP that w=
ill be extensible

=C2=A0=C2=A0=C2=A0=C2=A0 -Info=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0



Would appreciate your comments if you think differently about any of the AV=
Ps above, or that we have missed other AVPs that needs to.



(2) E.g adding new subscription ID.



Unlike Subscription-Id-Type AVP which cannot be extended to a new type with=
out a new application ID, a new AVP being proposed in RFC4006bis is:



=C2=A0 Subscription-Id-Extension ::=3D < AVP Header: XXX >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-E164 ]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-IMSI ]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-SIP-URI ]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-NAI ]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-Private ]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0*[ AVP ]



So, in order to add a new type (post RFC4006bis), you would need to =
submit draft with an AVP definition in it to could be added to the Subscrip=
tion-Id-Extension as it is extensible.

This new draft would be compliant with RFC4006bis and will therefore not re=
quire a new application ID.



Best Regards,



Yuval





From: Misha Zaytsev [mailto:=
misha.zaytsev.rus@gmail.com]

Sent: Saturday, January 28, 2017 11:07 PM

To: Yuval Lifshitz

Cc: Gardella, Maryse (Nokia - FR); dime@ie=
tf.org

Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP




Hi Yuval,



May I ask you several questions to be able to understand the whole situatio=
n:



1. Why are you proposing to add new extendable AVPs only for some of the AV=
Ps listed in section 12?

I think the same concern is applicable for all these AVPs, isn't?



2. Could you clarify what official procedure to assign new available values=
 is meant here?

It is not working w/o defining new Application-ID as you mentioned above?




12.16.=C2=A0 Subscription-Id-Type AVP



=C2=A0 =C2=A0As defined in Section 8.47, the Subscription-Id-Type AVP inclu=
des

=C2=A0 =C2=A0Enumerated type values 0 - 4.=C2=A0 IANA has created and is ma=
intaining a

=C2=A0 =C2=A0namespace for this AVP.=C2=A0 All remaining values are availab=
le for

=C2=A0 =C2=A0assignment by a Designated Expert [RFC2434].



Excuse me in advance if what I'm asking about are well-known things.
But still please clarify them at least for me...



Thanks a lot in advance!



/Misha



2017-01-25 11:29 GMT+03:00 Yuval Lifshitz <ylifshitz@sandvine.com>:

Hi Maryse,

The idea is the following:

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the CC client =
want to work with RFC4006bis only CC server, and want to make sure that the=
 subscription ID is understood by the server, it may set the M-bit. Any RFC=
4006 server will reply with DIAMETER_AVP_UNSUPPORTED (5001)

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the CC client =
is not sure whether the CC servers are RFC4006 or RFC4006bis, or have a mix=
 of servers, and want to work with both, it may not set the M-bit

o=C2=A0=C2=A0 In this case it would send both AVPs for the old types, so th=
at the new AVP will be ignored by the RFC4006 servers

o=C2=A0=C2=A0 In a case of a new type of subscription, not covered in RFC40=
06, it may send the new AVP with the M-bit set, causing any old server to r=
eply with DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP wit=
hout the M-bit set, here the server would just ignore the AVP, but would pr=
obably reply DIAMETER_MISSING_AVP (5005) as it will not have any subscripti=
on ID

=C2=A0

Yuval

=C2=A0

From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]

Sent: Tuesday, January 24, 2017 5:25 PM

To: Yuval Lifshitz; dime@ietf.org

Subject: RE: RFC4006bis - Subscription-Id-Extension AVP

=C2=A0

Hi Yuval,

=C2=A0

Thanks for continuing on this.

I am not sure to understand the difference between =E2=80=9Cmay=E2=80=9D an=
d =E2=80=9Cmust=E2=80=9D, since with =C2=A0=E2=80=9CMay=E2=80=9D we can end=
 having the M-bit set by the RFC4006bis CC client.

I guess from the protocol=E2=80=99s perspective =E2=80=9Cmay=E2=80=9D and =
=E2=80=9Cmust=E2=80=9D makes no difference right?

=C2=A0

BR

Maryse

=C2=A0

From: DiME [mailto:dime-bounces@ie=
tf.org] On Behalf Of Yuval Lifshitz

Sent: vendredi 13 janvier 2017 15:24

To: dime@ietf.org

Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP

=C2=A0

Hi All,

As part of the RFC4006bis work there are several AVPs that we plan on makin=
g future proof (See also: https://trac.ietf.org/trac/d=
ime/ticket/95). For example, Subscription-Id AVP cannot be extended to =
new types without changing the enumeration in Subscription-Id-Type AVP, whi=
ch in turn requires a new application ID (something we really want to avoid=
).

To solve this issue we propose adding a new, extendable AVP. In this exampl=
e:

=C2=A0

Subscription-Id-Extension ::=3D < AVP Header: XXX >

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 [ Subscription-Id-E164 ]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 [ Subscription-Id-IMSI ]

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0[ Subscription-Id-SIP-URI ]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 [ Subscription-Id-NAI ]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 [ Subscription-Id-Private ]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 *[ AVP ]

=C2=A0

When looking into Subscription-ID-Extension AVP =C2=A0header flags I ran in=
to a problem. The existing Subscription-ID AVP (and its sub-AVPs) are all m=
arked with the M-bit as a =E2=80=9Cmust=E2=80=9D, probably because they hol=
d the subscriber=E2=80=99s name which is critical information.

However, in order for a RFC4006bis CC client to be able to communicate with=
 an RFC4006 CC-server, they will have to be marked as =E2=80=9Cmay=E2=80=9D=
.

=C2=A0

Would appreciate your point of view on that topic?

=C2=A0

Best Regards,

=C2=A0

Yuval

=C2=A0



_______________________________________________

DiME mailing list

DiME@ietf.org

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







--94eb2c1cdb0ae605c305473fc1bd--


From nobody Mon Jan 30 00:29:29 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A5E12997F for ; Mon, 30 Jan 2017 00:29:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.452
X-Spam-Level: 
X-Spam-Status: No, score=-4.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVlyBMTU7_q7 for ; Mon, 30 Jan 2017 00:29:24 -0800 (PST)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AD91298BA for ; Mon, 30 Jan 2017 00:29:24 -0800 (PST)
Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 30 Jan 2017 03:29:22 -0500
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Mon, 30 Jan 2017 03:29:22 -0500
From: Yuval Lifshitz 
To: Misha Zaytsev 
Thread-Topic: [Dime] RFC4006bis - Subscription-Id-Extension AVP
Thread-Index: AdJtpzBPVPEgVuSXSxiP12VbbHIMngFfVP8wAO+8a8AAvDx6gAALc80gACEGUwAAEr8egA==
Date: Mon, 30 Jan 2017 08:29:21 +0000
Message-ID: 
References:      
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.142.6]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE497002DB6Bwtlexchp1sandvi_"
MIME-Version: 1.0
Archived-At: 
Cc: "dime@ietf.org" , "Gardella, Maryse \(Nokia - FR\)" 
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2017 08:29:26 -0000

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

SGkgTWlzaGEsDQpXZSBkaWRu4oCZdCBjb25zaWRlciB0aGUgb3B0aW9uIG9mIHVzaW5nIGEgYml0
bWFwLCBidXQgSeKAmW0gb3BlbiB0byB0aGlzIGlkZWEuIElNTywgaXQgd291bGQgYmUgbW9yZSBk
aWZmaWN1bHQgbWFuYWdpbmcgdGhlIGFkZGl0aW9uIG9mIG5ldyB2YWx1ZXMgaW4gdGhlIGNhc2Ug
b2YgYSBiaXRtYXAgdGhhbiBpbiB0aGUgY2FzZSBvZiBhZGRpbmcgbmV3IEFWUHMuICBPVE9ILCBh
ZGRpbmcgYSBiaXRtYXAgd2lsbCBiZSBsZXNzIGNoYW5nZXMgdG8gdGhlIFJGQy4NCkluIG91ciBw
cm9wb3NhbCB0aGUgQVZQcyBhcmUgbWFya2VkIGFzIG9wdGlvbmFsLCBhbmQgdGhlIE0tYml0ICpt
YXkqIGJlIHNldC4gSSBzZW50IGFuIGV4cGxhbmF0aW9uIHRvIE1hcnlzZSBvbiB0aGUgTS1iaXQg
4oCTIHBsZWFzZSBzZWUgYmVsb3csIGFuZCBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBjb21tZW50
cyBvbiB0aGF0Lg0KQXMgQUJORiBjYW5ub3Qgc2hvdyB0aGUgY29uY2VwdCBvZiDigJxvbmUgYW5k
IG9ubHkgb25lIEFWUOKAnSBJIHdpbGwgdXBkYXRlIHRoZSB0ZXh0IHRvIHN0YXRlIHRoYXQgZXhw
bGljaXRseSAoYWRkZWQ6IGh0dHBzOi8vZ2l0aHViLmNvbS9sYmVydHowMi9yZmM0MDA2YmlzL2lz
c3Vlcy8xOCkNCg0KWXV2YWwNCg0KRnJvbTogTWlzaGEgWmF5dHNldiBbbWFpbHRvOm1pc2hhLnph
eXRzZXYucnVzQGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRheSwgSmFudWFyeSAyOSwgMjAxNyA4OjIx
IFBNDQpUbzogWXV2YWwgTGlmc2hpdHoNCkNjOiBHYXJkZWxsYSwgTWFyeXNlIChOb2tpYSAtIEZS
KTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBSRkM0MDA2YmlzIC0gU3Vic2Ny
aXB0aW9uLUlkLUV4dGVuc2lvbiBBVlANCg0KSGkgWXV2YWwsDQoNClRoYW5rcyBhIGxvdCBmb3Ig
eW91ciBjbGFyaWZpY2F0aW9ucyEgTm93IGl0IHNlZW1zIEkgc2VlIHlvdXIgY29uY2Vybi4NCg0K
QXMgSSBjYW4gc2VlIHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlcmUgaXMgbm8gcG9zc2liaWxpdHkg
dG8gZXh0ZW5kIHRoZSBkZWZpbmVkIEFWUHMgb2YgdHlwZSBFbnVtZXJhdGVkIGluIGEgYmFja3dh
cmQgY29tcGF0aWJsZSB3YXkuIEZvciBtZSBpdCBtZWFucyB0aGF0IGFsbCBlbnVtZXJhdGUgQVZQ
cyBkZWZpbmVkIGluIFJGQzQwMDYgKGxpc3RlZCBpbiBzZWN0aW9uIDEyKSBpcyBhIG1hdHRlciBv
ZiB5b3VyIGludmVzdGlnYXRpb24uIE5vdCB0aGUgZ3JvdXBlZCBvbmVzLCBidXQgdGhlIG9uZXMg
dGhhdCBhcmUgdXNlZCBhcyBpbmRpY2F0b3JzIGluIHRoZXNlIGdyb3VwZWQgQVZQcy4NCg0KRm9s
bG93aW5nIHRoZSByZWNvbW1lbmRhdGlvbnMgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L3JmYzc0MjMjc2VjdGlvbi01LjYgdGhhdCB5b3UgcG9pbnRlZCBvdXQsIEkgdGhpbmsgYml0bWFz
ayBiYXNlZCBBVlBzIG1heSBiZSBhIHdheSBvdXQgaW4gdGhlIGN1cnJlbnQgc2l0dWF0aW9uLiBT
dWNoIEFWUCB3aWxsIGJlIG1hcmtlZCBhcyBtYW5kYXRvcnkuIFdoaWxlIG9ubHkgb25lIGJpdCBv
ZiB0aGlzIGJpdG1hc2sgTVVTVCBiZSBzZXQuDQoNCiBTdWJzY3JpcHRpb24tSWQtRXh0ZW5zaW9u
IDo6PSA8IEFWUCBIZWFkZXI6IFhYWCA+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsg
U3Vic2NyaXB0aW9uLUlkLVR5cGUtSW5kaWNhdG9yIF0NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgW1N1YnNjcml0aW9uLUlkLURhdGFdDQoNCkhhdmUgeW91IGNvbnNpZGVyZWQgdGhpcyBv
cHRpb24/IE9yIHByb2JhYmx5IEknbSBtaXNzaW5nIHNvbWV0aGluZy4uDQoNCkhvd2V2ZXIsIGlm
IHdlIGZvbGxvdyB0aGUgd2F5IHlvdSBhcmUgcHJvcG9zaW5nIHdpdGggc2V2ZXJhbCBtdXR1YWxs
eSBleGNsdXNpdmUgQVZQcywgdGhlbiB0aGVzZSBBVlBzIHNob3VsZCBiZSBtYXJrZWQgYXMgbm90
IG1hbmRhdG9yeS4gV2hpbGUgaW4gdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBhcHByb3ByaWF0ZSBn
cm91cGVkIEFWUCBpdCBzaG91bGQgYmUgc3RhdGVkIHRoYXQgb25seSBvbmUgb2YgdGhlc2UgQVZQ
cyBNVVNUIGJlIHByZXNlbnQuDQoNCi9NaXNoYQ0KDQoNCjIwMTctMDEtMjkgMTE6MjkgR01UKzAz
OjAwIFl1dmFsIExpZnNoaXR6IDx5bGlmc2hpdHpAc2FuZHZpbmUuY29tPG1haWx0bzp5bGlmc2hp
dHpAc2FuZHZpbmUuY29tPj46DQpIaSBNaXNoYSwNClRoZXJlIGlzIG5vdGhpbmcg4oCcd2VsbCBr
bm93buKAnSBpbiB0aGVzZSBpc3N1ZXMgYW5kIEnigJlsbCBiZSBoYXBweSB0byBjbGFyaWZ5IQ0K
DQooMSkgRHVyaW5nIElFVEY5NiBhIHF1ZXN0aW9uIGNhbWUgcmVnYXJkaW5nIHRoZSBzdXBwb3J0
IG9mIHRoZSBJTUVJIHVzZXIgZXF1aXBtZW50IHR5cGUg4oCTIGN1cnJlbnRseSBub3Qgb25lIG9m
IHRoZSBlbnVtZXJhdGVkIHR5cGVzIG9mIHRoZSBVc2VyLUVxdWlwbWVudC1JbmZvLVR5cGUgQVZQ
IChJTUVJU1YgaXMgdGhlcmUgYnV0IG5vdCBJTUVJKS4gQXMgYSByZXN1bHQgb2YgdGhpcyBkaXNj
dXNzaW9uLCBhbmQgZHVlIHRvIHRoZSBlbnVtIGV4dGVuc2lvbiBsaW1pdGF0aW9ucyAoc2VlIGhl
cmU6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NDIzI3NlY3Rpb24tNS42KSwgd2Ug
d2VyZSBhc2tlZCB0byBkbyBhbiBhbmFseXNpcyBvbiB3aGljaCBlbnVtZXJhdGVkIEFWUHMgcmVx
dWlyZXMgZXh0ZW5zaWJpbGl0eS4gVGhlIHJlc3VsdHMgd2VyZSBjYXB0dXJlZCBpbiB0aGUgZm9s
bG93aW5nIHRpY2tldDogaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZGltZS90aWNrZXQvOTUN
CkZvciBiZXR0ZXIgY2xhcml0eSBJ4oCZbSBwb3N0aW5nIGhlcmUgdGhlIGFjdHVhbCBhbmFseXNp
cyBvZiBBVlBzLiBTb21lIG9mIHRoZW0gZGlkbuKAmXQgbmVlZCB0byBiZSBleHRlbnNpYmxlIChp
biBvdXIgdmlldyksIHNvbWUgb2YgdGhlbSB3ZXJlIGFscmVhZHkgZXh0ZW5zaWJsZSBhbmQgdGhl
IHJlc3Qgd2VyZSBhZGRlZCB0byB0aGUgdGlja2V0Og0KDQogICAgICAgICAgICAgICAgICAgICBB
VlAgIFNlY3Rpb24NCiAgIEF0dHJpYnV0ZSBOYW1lICAgIENvZGUgRGVmaW5lZCBEYXRhIFR5cGUN
CiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICBDQy1Nb25l
eSAgICAgICAgICA0MTMgIDguMjIgICBHcm91cGVkICAgIC0gbm90IGV4dGVuc2libGUsIGRvZXMg
bm90IG5lZWQgdG8gYmUNCiAgIENvc3QtSW5mb3JtYXRpb24gIDQyMyAgOC43ICAgIEdyb3VwZWQg
ICAgLSBub3QgZXh0ZW5zaWJsZSwgZG9lcyBub3QgbmVlZCB0byBiZQ0KICAgRmluYWwtVW5pdC0g
ICAgICAgNDMwICA4LjM0ICAgR3JvdXBlZCAgICAtIG5vdCBleHRlbnNpYmxlLCB3aWxsIGJlIHJl
cGxhY2VkIGJ5IFFvUy1GaW5hbC1Vbml0LUluZGljYXRpb24gdGhhdCB3aWxsIGJlIGV4dGVuc2li
bGUNCiAgICAgSW5kaWNhdGlvbg0KICAgR3JhbnRlZC1TZXJ2aWNlLSAgNDMxICA4LjE3ICAgR3Jv
dXBlZCAgICAtIGV4dGVuc2libGUNCiAgICAgVW5pdA0KICAgRy1TLVUtUG9vbC0gICAgICAgNDU3
ICA4LjMwICAgR3JvdXBlZCAgICAtIG5vdCBleHRlbnNpYmxlLCBkb2VzIG5vdCBuZWVkIHRvIGJl
DQogICAgIFJlZmVyZW5jZQ0KICAgTXVsdGlwbGUtU2VydmljZXMgNDU2ICA4LjE2ICAgR3JvdXBl
ZCAgICAtIGV4dGVuc2libGUNCiAgICAtQ3JlZGl0LUNvbnRyb2wNCiAgIFJlZGlyZWN0LVNlcnZl
ciAgIDQzNCAgOC4zNyAgIEdyb3VwZWQgICAgLSBub3QgZXh0ZW5zaWJsZSwgaGFzIGEgcHJvYmxl
bSBzaW1pbGFyIHRvIGVxdWlwbWVudCB0eXBlIGFzIGl0IGNvbnRhaW5zIGFuIGVudW1lcmF0ZWQg
dHlwZS92YWx1ZSBBVlBzDQogICBSZXF1ZXN0ZWQtU2VydmljZSA0MzcgIDguMTggICBHcm91cGVk
ICAgIC0gZXh0ZW5zaWJsZQ0KICAgICAtVW5pdA0KICAgU2VydmljZS1QYXJhbWV0ZXIgNDQwICA4
LjQzICAgR3JvdXBlZCAgICAtIG5vdCBleHRlbnNpYmxlLCBkb2VzIG5vdCBuZWVkIHRvIGJlDQog
ICAgIC1JbmZvDQogICBTdWJzY3JpcHRpb24tSWQgICA0NDMgIDguNDYgICBHcm91cGVkICAgIC0g
bm90IGV4dGVuc2libGUsIGhhcyBhIHByb2JsZW0gc2ltaWxhciB0byBlcXVpcG1lbnQgdHlwZSBh
cyBpdCBjb250YWlucyBhbiBlbnVtZXJhdGVkIHR5cGUvdmFsdWUgQVZQcw0KICAgVW5pdC1WYWx1
ZSAgICAgICAgNDQ1ICA4LjggICAgR3JvdXBlZCAgICAtIG5vdCBleHRlbnNpYmxlLCBkb2VzIG5v
dCBuZWVkIHRvIGJlDQogICBVc2VkLVNlcnZpY2UtVW5pdCA0NDYgIDguMTkgICBHcm91cGVkICAg
IC0gZXh0ZW5zaWJsZQ0KICAgVXNlci1FcXVpcG1lbnQgICAgNDU4ICA4LjQ5ICAgR3JvdXBlZCAg
ICAtIG5vdCBleHRlbnNpYmxlLCB3aWxsIGJlIHJlcGxhY2VkIGJ5IGFuIEFWUCB0aGF0IHdpbGwg
YmUgZXh0ZW5zaWJsZQ0KICAgICAtSW5mbw0KDQpXb3VsZCBhcHByZWNpYXRlIHlvdXIgY29tbWVu
dHMgaWYgeW91IHRoaW5rIGRpZmZlcmVudGx5IGFib3V0IGFueSBvZiB0aGUgQVZQcyBhYm92ZSwg
b3IgdGhhdCB3ZSBoYXZlIG1pc3NlZCBvdGhlciBBVlBzIHRoYXQgbmVlZHMgdG8uDQoNCigyKSBF
LmcgYWRkaW5nIG5ldyBzdWJzY3JpcHRpb24gSUQuDQoNClVubGlrZSBTdWJzY3JpcHRpb24tSWQt
VHlwZSBBVlAgd2hpY2ggY2Fubm90IGJlIGV4dGVuZGVkIHRvIGEgbmV3IHR5cGUgd2l0aG91dCBh
IG5ldyBhcHBsaWNhdGlvbiBJRCwgYSBuZXcgQVZQIGJlaW5nIHByb3Bvc2VkIGluIFJGQzQwMDZi
aXMgaXM6DQoNCiAgU3Vic2NyaXB0aW9uLUlkLUV4dGVuc2lvbiA6Oj0gPCBBVlAgSGVhZGVyOiBY
WFggPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIFN1YnNjcmlwdGlvbi1JZC1FMTY0
IF0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWyBTdWJzY3JpcHRpb24tSWQtSU1TSSBd
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIFsgU3Vic2NyaXB0aW9uLUlkLVNJUC1VUkkg
XQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIFN1YnNjcmlwdGlvbi1JZC1OQUkgXQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbIFN1YnNjcmlwdGlvbi1JZC1Qcml2YXRlIF0N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICpbIEFWUCBdDQoNClNvLCBpbiBvcmRlciB0byBh
ZGQgYSBuZXcgdHlwZSAocG9zdCBSRkM0MDA2YmlzKSwgeW91IHdvdWxkIG5lZWQgdG8gc3VibWl0
IGRyYWZ0IHdpdGggYW4gQVZQIGRlZmluaXRpb24gaW4gaXQgdG8gY291bGQgYmUgYWRkZWQgdG8g
dGhlIFN1YnNjcmlwdGlvbi1JZC1FeHRlbnNpb24gYXMgaXQgaXMgZXh0ZW5zaWJsZS4NClRoaXMg
bmV3IGRyYWZ0IHdvdWxkIGJlIGNvbXBsaWFudCB3aXRoIFJGQzQwMDZiaXMgYW5kIHdpbGwgdGhl
cmVmb3JlIG5vdCByZXF1aXJlIGEgbmV3IGFwcGxpY2F0aW9uIElELg0KDQpCZXN0IFJlZ2FyZHMs
DQoNCll1dmFsDQoNCg0KRnJvbTogTWlzaGEgWmF5dHNldiBbbWFpbHRvOm1pc2hhLnpheXRzZXYu
cnVzQGdtYWlsLmNvbTxtYWlsdG86bWlzaGEuemF5dHNldi5ydXNAZ21haWwuY29tPl0NClNlbnQ6
IFNhdHVyZGF5LCBKYW51YXJ5IDI4LCAyMDE3IDExOjA3IFBNDQpUbzogWXV2YWwgTGlmc2hpdHoN
CkNjOiBHYXJkZWxsYSwgTWFyeXNlIChOb2tpYSAtIEZSKTsgZGltZUBpZXRmLm9yZzxtYWlsdG86
ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGltZV0gUkZDNDAwNmJpcyAtIFN1YnNjcmlw
dGlvbi1JZC1FeHRlbnNpb24gQVZQDQoNCkhpIFl1dmFsLA0KDQpNYXkgSSBhc2sgeW91IHNldmVy
YWwgcXVlc3Rpb25zIHRvIGJlIGFibGUgdG8gdW5kZXJzdGFuZCB0aGUgd2hvbGUgc2l0dWF0aW9u
Og0KDQoxLiBXaHkgYXJlIHlvdSBwcm9wb3NpbmcgdG8gYWRkIG5ldyBleHRlbmRhYmxlIEFWUHMg
b25seSBmb3Igc29tZSBvZiB0aGUgQVZQcyBsaXN0ZWQgaW4gc2VjdGlvbiAxMj8NCkkgdGhpbmsg
dGhlIHNhbWUgY29uY2VybiBpcyBhcHBsaWNhYmxlIGZvciBhbGwgdGhlc2UgQVZQcywgaXNuJ3Q/
DQoNCjIuIENvdWxkIHlvdSBjbGFyaWZ5IHdoYXQgb2ZmaWNpYWwgcHJvY2VkdXJlIHRvIGFzc2ln
biBuZXcgYXZhaWxhYmxlIHZhbHVlcyBpcyBtZWFudCBoZXJlPw0KSXQgaXMgbm90IHdvcmtpbmcg
dy9vIGRlZmluaW5nIG5ldyBBcHBsaWNhdGlvbi1JRCBhcyB5b3UgbWVudGlvbmVkIGFib3ZlPw0K
DQoNCjEyLjE2LiAgU3Vic2NyaXB0aW9uLUlkLVR5cGUgQVZQDQoNCiAgIEFzIGRlZmluZWQgaW4g
U2VjdGlvbiA4LjQ3LCB0aGUgU3Vic2NyaXB0aW9uLUlkLVR5cGUgQVZQIGluY2x1ZGVzDQogICBF
bnVtZXJhdGVkIHR5cGUgdmFsdWVzIDAgLSA0LiAgSUFOQSBoYXMgY3JlYXRlZCBhbmQgaXMgbWFp
bnRhaW5pbmcgYQ0KICAgbmFtZXNwYWNlIGZvciB0aGlzIEFWUC4gIEFsbCByZW1haW5pbmcgdmFs
dWVzIGFyZSBhdmFpbGFibGUgZm9yDQogICBhc3NpZ25tZW50IGJ5IGEgRGVzaWduYXRlZCBFeHBl
cnQgW1JGQzI0MzRdLg0KDQpFeGN1c2UgbWUgaW4gYWR2YW5jZSBpZiB3aGF0IEknbSBhc2tpbmcg
YWJvdXQgYXJlIHdlbGwta25vd24gdGhpbmdzLg0KQnV0IHN0aWxsIHBsZWFzZSBjbGFyaWZ5IHRo
ZW0gYXQgbGVhc3QgZm9yIG1lLi4uDQoNClRoYW5rcyBhIGxvdCBpbiBhZHZhbmNlIQ0KDQovTWlz
aGENCg0KMjAxNy0wMS0yNSAxMToyOSBHTVQrMDM6MDAgWXV2YWwgTGlmc2hpdHogPHlsaWZzaGl0
ekBzYW5kdmluZS5jb208bWFpbHRvOnlsaWZzaGl0ekBzYW5kdmluZS5jb20+PjoNCkhpIE1hcnlz
ZSwNClRoZSBpZGVhIGlzIHRoZSBmb2xsb3dpbmc6DQrigKIgICAgICAgICBJZiB0aGUgQ0MgY2xp
ZW50IHdhbnQgdG8gd29yayB3aXRoIFJGQzQwMDZiaXMgb25seSBDQyBzZXJ2ZXIsIGFuZCB3YW50
IHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBzdWJzY3JpcHRpb24gSUQgaXMgdW5kZXJzdG9vZCBieSB0
aGUgc2VydmVyLCBpdCBtYXkgc2V0IHRoZSBNLWJpdC4gQW55IFJGQzQwMDYgc2VydmVyIHdpbGwg
cmVwbHkgd2l0aCBESUFNRVRFUl9BVlBfVU5TVVBQT1JURUQgKDUwMDEpDQrigKIgICAgICAgICBJ
ZiB0aGUgQ0MgY2xpZW50IGlzIG5vdCBzdXJlIHdoZXRoZXIgdGhlIENDIHNlcnZlcnMgYXJlIFJG
QzQwMDYgb3IgUkZDNDAwNmJpcywgb3IgaGF2ZSBhIG1peCBvZiBzZXJ2ZXJzLCBhbmQgd2FudCB0
byB3b3JrIHdpdGggYm90aCwgaXQgbWF5IG5vdCBzZXQgdGhlIE0tYml0DQpvICAgSW4gdGhpcyBj
YXNlIGl0IHdvdWxkIHNlbmQgYm90aCBBVlBzIGZvciB0aGUgb2xkIHR5cGVzLCBzbyB0aGF0IHRo
ZSBuZXcgQVZQIHdpbGwgYmUgaWdub3JlZCBieSB0aGUgUkZDNDAwNiBzZXJ2ZXJzDQpvICAgSW4g
YSBjYXNlIG9mIGEgbmV3IHR5cGUgb2Ygc3Vic2NyaXB0aW9uLCBub3QgY292ZXJlZCBpbiBSRkM0
MDA2LCBpdCBtYXkgc2VuZCB0aGUgbmV3IEFWUCB3aXRoIHRoZSBNLWJpdCBzZXQsIGNhdXNpbmcg
YW55IG9sZCBzZXJ2ZXIgdG8gcmVwbHkgd2l0aCBESUFNRVRFUl9BVlBfVU5TVVBQT1JURUQgKDUw
MDEpLiBJdCBtYXkgYWxzbyBzZW5kIHRoZSBuZXcgQVZQIHdpdGhvdXQgdGhlIE0tYml0IHNldCwg
aGVyZSB0aGUgc2VydmVyIHdvdWxkIGp1c3QgaWdub3JlIHRoZSBBVlAsIGJ1dCB3b3VsZCBwcm9i
YWJseSByZXBseSBESUFNRVRFUl9NSVNTSU5HX0FWUCAoNTAwNSkgYXMgaXQgd2lsbCBub3QgaGF2
ZSBhbnkgc3Vic2NyaXB0aW9uIElEDQoNCll1dmFsDQoNCkZyb206IEdhcmRlbGxhLCBNYXJ5c2Ug
KE5va2lhIC0gRlIpIFttYWlsdG86bWFyeXNlLmdhcmRlbGxhQG5va2lhLmNvbTxtYWlsdG86bWFy
eXNlLmdhcmRlbGxhQG5va2lhLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI0LCAyMDE3
IDU6MjUgUE0NClRvOiBZdXZhbCBMaWZzaGl0ejsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBp
ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBSRkM0MDA2YmlzIC0gU3Vic2NyaXB0aW9uLUlkLUV4dGVu
c2lvbiBBVlANCg0KSGkgWXV2YWwsDQoNClRoYW5rcyBmb3IgY29udGludWluZyBvbiB0aGlzLg0K
SSBhbSBub3Qgc3VyZSB0byB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g4oCcbWF5
4oCdIGFuZCDigJxtdXN04oCdLCBzaW5jZSB3aXRoICDigJxNYXnigJ0gd2UgY2FuIGVuZCBoYXZp
bmcgdGhlIE0tYml0IHNldCBieSB0aGUgUkZDNDAwNmJpcyBDQyBjbGllbnQuDQpJIGd1ZXNzIGZy
b20gdGhlIHByb3RvY29s4oCZcyBwZXJzcGVjdGl2ZSDigJxtYXnigJ0gYW5kIOKAnG11c3TigJ0g
bWFrZXMgbm8gZGlmZmVyZW5jZSByaWdodD8NCg0KQlINCk1hcnlzZQ0KDQpGcm9tOiBEaU1FIFtt
YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc+
XSBPbiBCZWhhbGYgT2YgWXV2YWwgTGlmc2hpdHoNClNlbnQ6IHZlbmRyZWRpIDEzIGphbnZpZXIg
MjAxNyAxNToyNA0KVG86IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBbQUxVXSBbRGltZV0gUkZDNDAwNmJpcyAtIFN1YnNjcmlwdGlvbi1JZC1FeHRlbnNpb24g
QVZQDQoNCkhpIEFsbCwNCkFzIHBhcnQgb2YgdGhlIFJGQzQwMDZiaXMgd29yayB0aGVyZSBhcmUg
c2V2ZXJhbCBBVlBzIHRoYXQgd2UgcGxhbiBvbiBtYWtpbmcgZnV0dXJlIHByb29mIChTZWUgYWxz
bzogaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZGltZS90aWNrZXQvOTUpLiBGb3IgZXhhbXBs
ZSwgU3Vic2NyaXB0aW9uLUlkIEFWUCBjYW5ub3QgYmUgZXh0ZW5kZWQgdG8gbmV3IHR5cGVzIHdp
dGhvdXQgY2hhbmdpbmcgdGhlIGVudW1lcmF0aW9uIGluIFN1YnNjcmlwdGlvbi1JZC1UeXBlIEFW
UCwgd2hpY2ggaW4gdHVybiByZXF1aXJlcyBhIG5ldyBhcHBsaWNhdGlvbiBJRCAoc29tZXRoaW5n
IHdlIHJlYWxseSB3YW50IHRvIGF2b2lkKS4NClRvIHNvbHZlIHRoaXMgaXNzdWUgd2UgcHJvcG9z
ZSBhZGRpbmcgYSBuZXcsIGV4dGVuZGFibGUgQVZQLiBJbiB0aGlzIGV4YW1wbGU6DQoNClN1YnNj
cmlwdGlvbi1JZC1FeHRlbnNpb24gOjo9IDwgQVZQIEhlYWRlcjogWFhYID4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgWyBTdWJzY3JpcHRpb24tSWQtRTE2NCBdDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFsgU3Vic2NyaXB0aW9uLUlkLUlNU0kgXQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBbIFN1YnNjcmlwdGlvbi1JZC1TSVAtVVJJIF0NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgWyBTdWJzY3JpcHRpb24tSWQtTkFJIF0NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgWyBTdWJzY3JpcHRpb24tSWQtUHJpdmF0ZSBdDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgKlsgQVZQIF0NCg0KV2hlbiBsb29raW5nIGludG8gU3Vic2NyaXB0aW9uLUlE
LUV4dGVuc2lvbiBBVlAgIGhlYWRlciBmbGFncyBJIHJhbiBpbnRvIGEgcHJvYmxlbS4gVGhlIGV4
aXN0aW5nIFN1YnNjcmlwdGlvbi1JRCBBVlAgKGFuZCBpdHMgc3ViLUFWUHMpIGFyZSBhbGwgbWFy
a2VkIHdpdGggdGhlIE0tYml0IGFzIGEg4oCcbXVzdOKAnSwgcHJvYmFibHkgYmVjYXVzZSB0aGV5
IGhvbGQgdGhlIHN1YnNjcmliZXLigJlzIG5hbWUgd2hpY2ggaXMgY3JpdGljYWwgaW5mb3JtYXRp
b24uDQpIb3dldmVyLCBpbiBvcmRlciBmb3IgYSBSRkM0MDA2YmlzIENDIGNsaWVudCB0byBiZSBh
YmxlIHRvIGNvbW11bmljYXRlIHdpdGggYW4gUkZDNDAwNiBDQy1zZXJ2ZXIsIHRoZXkgd2lsbCBo
YXZlIHRvIGJlIG1hcmtlZCBhcyDigJxtYXnigJ0uDQoNCldvdWxkIGFwcHJlY2lhdGUgeW91ciBw
b2ludCBvZiB2aWV3IG9uIHRoYXQgdG9waWM/DQoNCkJlc3QgUmVnYXJkcywNCg0KWXV2YWwNCg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBt
YWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5vcmc+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWlzaGEsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGRpZG7igJl0IGNvbnNpZGVyIHRoZSBvcHRpb24g
b2YgdXNpbmcgYSBiaXRtYXAsIGJ1dCBJ4oCZbSBvcGVuIHRvIHRoaXMgaWRlYS4gSU1PLCBpdCB3
b3VsZCBiZSBtb3JlIGRpZmZpY3VsdCBtYW5hZ2luZyB0aGUgYWRkaXRpb24gb2YgbmV3IHZhbHVl
cyBpbiB0aGUgY2FzZQ0KIG9mIGEgYml0bWFwIHRoYW4gaW4gdGhlIGNhc2Ugb2YgYWRkaW5nIG5l
dyBBVlBzLiAmbmJzcDtPVE9ILCBhZGRpbmcgYSBiaXRtYXAgd2lsbCBiZSBsZXNzIGNoYW5nZXMg
dG8gdGhlIFJGQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gb3VyIHByb3Bvc2Fs
IHRoZSBBVlBzIGFyZSBtYXJrZWQgYXMgb3B0aW9uYWwsIGFuZCB0aGUgTS1iaXQgKjxiPm1heTwv
Yj4qIGJlIHNldC4gSSBzZW50IGFuIGV4cGxhbmF0aW9uIHRvIE1hcnlzZSBvbiB0aGUgTS1iaXQg
4oCTIHBsZWFzZSBzZWUgYmVsb3csIGFuZCBsZXQNCiBtZSBrbm93IGlmIHlvdSBoYXZlIGNvbW1l
bnRzIG9uIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIEFCTkYgY2Fubm90
IHNob3cgdGhlIGNvbmNlcHQgb2Yg4oCcb25lIGFuZCBvbmx5IG9uZSBBVlDigJ0gSSB3aWxsIHVw
ZGF0ZSB0aGUgdGV4dCB0byBzdGF0ZSB0aGF0IGV4cGxpY2l0bHkgKGFkZGVkOg0KPGEgaHJlZj0i
aHR0cHM6Ly9naXRodWIuY29tL2xiZXJ0ejAyL3JmYzQwMDZiaXMvaXNzdWVzLzE4Ij5odHRwczov
L2dpdGh1Yi5jb20vbGJlcnR6MDIvcmZjNDAwNmJpcy9pc3N1ZXMvMTg8L2E+KTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
WXV2YWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pc2hhIFph
eXRzZXYgW21haWx0bzptaXNoYS56YXl0c2V2LnJ1c0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50
OjwvYj4gU3VuZGF5LCBKYW51YXJ5IDI5LCAyMDE3IDg6MjEgUE08YnI+DQo8Yj5Ubzo8L2I+IFl1
dmFsIExpZnNoaXR6PGJyPg0KPGI+Q2M6PC9iPiBHYXJkZWxsYSwgTWFyeXNlIChOb2tpYSAtIEZS
KTsgZGltZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFJGQzQwMDZi
aXMgLSBTdWJzY3JpcHRpb24tSWQtRXh0ZW5zaW9uIEFWUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkhpIFl1dmFsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+VGhhbmtzIGEgbG90IGZvciB5b3VyIGNsYXJpZmljYXRpb25zISBOb3cg
aXQgc2VlbXMgSSBzZWUgeW91ciBjb25jZXJuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBJIGNhbiBzZWUgdGhlIHByb2JsZW0gaXMgdGhh
dCB0aGVyZSBpcyBubyBwb3NzaWJpbGl0eSB0byBleHRlbmQgdGhlIGRlZmluZWQgQVZQcyBvZiB0
eXBlIEVudW1lcmF0ZWQgaW4gYSBiYWNrd2FyZCBjb21wYXRpYmxlIHdheS4gRm9yIG1lIGl0IG1l
YW5zIHRoYXQgYWxsIGVudW1lcmF0ZSBBVlBzIGRlZmluZWQgaW4gUkZDNDAwNiAobGlzdGVkIGlu
IHNlY3Rpb24gMTIpIGlzIGEgbWF0dGVyIG9mIHlvdXIgaW52ZXN0aWdhdGlvbi4NCiBOb3QgdGhl
IGdyb3VwZWQgb25lcywgYnV0IHRoZSBvbmVzIHRoYXQgYXJlIHVzZWQgYXMgaW5kaWNhdG9ycyBp
biB0aGVzZSBncm91cGVkIEFWUHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkZvbGxvd2luZyB0aGUgcmVjb21tZW5kYXRpb25zIGluJm5ic3A7
PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0MjMjc2VjdGlvbi01LjYi
IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5odHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvcmZjNzQyMyNzZWN0aW9uLTUuNjwvc3Bhbj48L2E+Jm5ic3A7dGhh
dCB5b3UgcG9pbnRlZCBvdXQsIEkgdGhpbmsgYml0bWFzayBiYXNlZA0KIEFWUHMgbWF5IGJlIGEg
d2F5IG91dCBpbiB0aGUgY3VycmVudCBzaXR1YXRpb24uIFN1Y2ggQVZQIHdpbGwgYmUgbWFya2Vk
IGFzIG1hbmRhdG9yeS4gV2hpbGUgb25seSBvbmUgYml0IG9mIHRoaXMgYml0bWFzayBNVVNUIGJl
IHNldC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjojNTAwMDUwIj4mbmJzcDtTdWJz
Y3JpcHRpb24tSWQtRXh0ZW5zaW9uIDo6PSAmbHQ7IEFWUCBIZWFkZXI6IFhYWCAmZ3Q7PGJyPg0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbIFN1YnNjcmlw
dGlvbi1JZC1UeXBlLUluZGljYXRvciZuYnNwO108YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tTdWJzY3JpdGlvbi1JZC1EYXRhXTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSGF2ZSB5b3Ug
Y29uc2lkZXJlZCB0aGlzIG9wdGlvbj8gT3IgcHJvYmFibHkgSSdtIG1pc3Npbmcgc29tZXRoaW5n
Li48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIs
IGlmIHdlIGZvbGxvdyB0aGUgd2F5IHlvdSBhcmUgcHJvcG9zaW5nIHdpdGggc2V2ZXJhbCBtdXR1
YWxseSBleGNsdXNpdmUgQVZQcywgdGhlbiB0aGVzZSBBVlBzIHNob3VsZCBiZSBtYXJrZWQgYXMg
bm90IG1hbmRhdG9yeS4gV2hpbGUgaW4gdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBhcHByb3ByaWF0
ZSBncm91cGVkIEFWUCBpdCBzaG91bGQgYmUgc3RhdGVkIHRoYXQgb25seSBvbmUgb2YgdGhlc2UN
CiBBVlBzIE1VU1QgYmUgcHJlc2VudC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L01pc2hhJm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjAxNy0wMS0yOSAxMToyOSBH
TVQmIzQzOzAzOjAwIFl1dmFsIExpZnNoaXR6ICZsdDs8YSBocmVmPSJtYWlsdG86eWxpZnNoaXR6
QHNhbmR2aW5lLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlsaWZzaGl0ekBzYW5kdmluZS5jb208L2E+
Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE1pc2hhLDxicj4N
ClRoZXJlIGlzIG5vdGhpbmcg4oCcd2VsbCBrbm93buKAnSBpbiB0aGVzZSBpc3N1ZXMgYW5kIEni
gJlsbCBiZSBoYXBweSB0byBjbGFyaWZ5ITxicj4NCjxicj4NCigxKSBEdXJpbmcgSUVURjk2IGEg
cXVlc3Rpb24gY2FtZSByZWdhcmRpbmcgdGhlIHN1cHBvcnQgb2YgdGhlIElNRUkgdXNlciBlcXVp
cG1lbnQgdHlwZSDigJMgY3VycmVudGx5IG5vdCBvbmUgb2YgdGhlIGVudW1lcmF0ZWQgdHlwZXMg
b2YgdGhlIFVzZXItRXF1aXBtZW50LUluZm8tVHlwZSBBVlAgKElNRUlTViBpcyB0aGVyZSBidXQg
bm90IElNRUkpLiBBcyBhIHJlc3VsdCBvZiB0aGlzIGRpc2N1c3Npb24sIGFuZCBkdWUgdG8gdGhl
IGVudW0gZXh0ZW5zaW9uDQogbGltaXRhdGlvbnMgKHNlZSBoZXJlOiA8YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQyMyNzZWN0aW9uLTUuNiIgdGFyZ2V0PSJfYmxhbmsi
Pg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0MjMjc2VjdGlvbi01LjY8L2E+KSwg
d2Ugd2VyZSBhc2tlZCB0byBkbyBhbiBhbmFseXNpcyBvbiB3aGljaCBlbnVtZXJhdGVkIEFWUHMg
cmVxdWlyZXMgZXh0ZW5zaWJpbGl0eS4gVGhlIHJlc3VsdHMgd2VyZSBjYXB0dXJlZCBpbiB0aGUg
Zm9sbG93aW5nIHRpY2tldDoNCjxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2Rp
bWUvdGlja2V0Lzk1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv
ZGltZS90aWNrZXQvOTU8L2E+PGJyPg0KRm9yIGJldHRlciBjbGFyaXR5IEnigJltIHBvc3Rpbmcg
aGVyZSB0aGUgYWN0dWFsIGFuYWx5c2lzIG9mIEFWUHMuIFNvbWUgb2YgdGhlbSBkaWRu4oCZdCBu
ZWVkIHRvIGJlIGV4dGVuc2libGUgKGluIG91ciB2aWV3KSwgc29tZSBvZiB0aGVtIHdlcmUgYWxy
ZWFkeSBleHRlbnNpYmxlIGFuZCB0aGUgcmVzdCB3ZXJlIGFkZGVkIHRvIHRoZSB0aWNrZXQ6PGJy
Pg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IEFWUCZuYnNwOyBTZWN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5i
c3A7QXR0cmlidXRlIE5hbWUmbmJzcDsmbmJzcDsmbmJzcDsgQ29kZSBEZWZpbmVkIERhdGEgVHlw
ZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tPGJyPg0KJm5ic3A7Jm5ic3A7IENDLU1vbmV5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQxMyZuYnNwOyA4LjIyJm5ic3A7Jm5i
c3A7IEdyb3VwZWQmbmJzcDsmbmJzcDsmbmJzcDsgLSBub3QgZXh0ZW5zaWJsZSwgZG9lcyBub3Qg
bmVlZCB0byBiZTxicj4NCiZuYnNwOyZuYnNwOyBDb3N0LUluZm9ybWF0aW9uJm5ic3A7IDQyMyZu
YnNwOyA4LjcmbmJzcDsmbmJzcDsmbmJzcDsgR3JvdXBlZCZuYnNwOyZuYnNwOyZuYnNwOyAtIG5v
dCBleHRlbnNpYmxlLCBkb2VzIG5vdCBuZWVkIHRvIGJlPGJyPg0KJm5ic3A7Jm5ic3A7IEZpbmFs
LVVuaXQtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQzMCZuYnNwOyA4LjM0
Jm5ic3A7Jm5ic3A7IEdyb3VwZWQmbmJzcDsmbmJzcDsmbmJzcDsgLSBub3QgZXh0ZW5zaWJsZSwg
d2lsbCBiZSByZXBsYWNlZCBieSBRb1MtRmluYWwtVW5pdC1JbmRpY2F0aW9uIHRoYXQgd2lsbCBi
ZSBleHRlbnNpYmxlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZGljYXRpb24mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnI+DQom
bmJzcDsmbmJzcDsmbmJzcDtHcmFudGVkLVNlcnZpY2UtJm5ic3A7IDQzMSZuYnNwOyA4LjE3Jm5i
c3A7Jm5ic3A7IEdyb3VwZWQmbmJzcDsmbmJzcDsmbmJzcDsgLSBleHRlbnNpYmxlPGJyPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVuaXQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Ry1TLVUtUG9vbC0mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgNDU3Jm5ic3A7IDguMzAmbmJzcDsmbmJzcDsgR3JvdXBlZCZuYnNw
OyZuYnNwOyZuYnNwOyAtIG5vdCBleHRlbnNpYmxlLCBkb2VzIG5vdCBuZWVkIHRvIGJlPGJyPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZmVyZW5jZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZu
YnNwO011bHRpcGxlLVNlcnZpY2VzIDQ1NiZuYnNwOyA4LjE2Jm5ic3A7Jm5ic3A7IEdyb3VwZWQm
bmJzcDsmbmJzcDsmbmJzcDsgLSBleHRlbnNpYmxlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC1D
cmVkaXQtQ29udHJvbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwOyZu
YnNwOyZuYnNwO1JlZGlyZWN0LVNlcnZlciZuYnNwOyZuYnNwOyA0MzQmbmJzcDsgOC4zNyZuYnNw
OyZuYnNwOyBHcm91cGVkJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gbm90IGV4dGVuc2libGUsIGhhcyBh
IHByb2JsZW0gc2ltaWxhciB0byBlcXVpcG1lbnQgdHlwZSBhcyBpdCBjb250YWlucyBhbiBlbnVt
ZXJhdGVkIHR5cGUvdmFsdWUgQVZQczxicj4NCiZuYnNwOyZuYnNwOyBSZXF1ZXN0ZWQtU2Vydmlj
ZSA0MzcmbmJzcDsgOC4xOCZuYnNwOyZuYnNwOyBHcm91cGVkJm5ic3A7Jm5ic3A7Jm5ic3A7IC0g
ZXh0ZW5zaWJsZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtVW5pdCZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1NlcnZpY2UtUGFyYW1ldGVy
IDQ0MCZuYnNwOyA4LjQzJm5ic3A7Jm5ic3A7IEdyb3VwZWQmbmJzcDsmbmJzcDsmbmJzcDsgLSBu
b3QgZXh0ZW5zaWJsZSwgZG9lcyBub3QgbmVlZCB0byBiZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAtSW5mbyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxicj4NCiZuYnNwOyZuYnNw
OyZuYnNwO1N1YnNjcmlwdGlvbi1JZCZuYnNwOyZuYnNwOyA0NDMmbmJzcDsgOC40NiZuYnNwOyZu
YnNwOyBHcm91cGVkJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gbm90IGV4dGVuc2libGUsIGhhcyBhIHBy
b2JsZW0gc2ltaWxhciB0byBlcXVpcG1lbnQgdHlwZSBhcyBpdCBjb250YWlucyBhbiBlbnVtZXJh
dGVkIHR5cGUvdmFsdWUgQVZQczxicj4NCiZuYnNwOyZuYnNwOyBVbml0LVZhbHVlJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQ0NSZuYnNwOyA4LjgmbmJzcDsgJm5i
c3A7Jm5ic3A7R3JvdXBlZCZuYnNwOyZuYnNwOyZuYnNwOyAtIG5vdCBleHRlbnNpYmxlLCBkb2Vz
IG5vdCBuZWVkIHRvIGJlPGJyPg0KJm5ic3A7Jm5ic3A7IFVzZWQtU2VydmljZS1Vbml0IDQ0NiZu
YnNwOyA4LjE5Jm5ic3A7Jm5ic3A7IEdyb3VwZWQmbmJzcDsmbmJzcDsmbmJzcDsgLSBleHRlbnNp
YmxlPGJyPg0KJm5ic3A7Jm5ic3A7IFVzZXItRXF1aXBtZW50Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQ1
OCZuYnNwOyA4LjQ5Jm5ic3A7Jm5ic3A7IEdyb3VwZWQmbmJzcDsmbmJzcDsmbmJzcDsgLSBub3Qg
ZXh0ZW5zaWJsZSwgd2lsbCBiZSByZXBsYWNlZCBieSBhbiBBVlAgdGhhdCB3aWxsIGJlIGV4dGVu
c2libGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLUluZm8mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDs8YnI+DQo8YnI+DQpXb3VsZCBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgaWYg
eW91IHRoaW5rIGRpZmZlcmVudGx5IGFib3V0IGFueSBvZiB0aGUgQVZQcyBhYm92ZSwgb3IgdGhh
dCB3ZSBoYXZlIG1pc3NlZCBvdGhlciBBVlBzIHRoYXQgbmVlZHMgdG8uPGJyPg0KPGJyPg0KKDIp
IEUuZyBhZGRpbmcgbmV3IHN1YnNjcmlwdGlvbiBJRC48YnI+DQo8YnI+DQpVbmxpa2UgU3Vic2Ny
aXB0aW9uLUlkLVR5cGUgQVZQIHdoaWNoIGNhbm5vdCBiZSBleHRlbmRlZCB0byBhIG5ldyB0eXBl
IHdpdGhvdXQgYSBuZXcgYXBwbGljYXRpb24gSUQsIGEgbmV3IEFWUCBiZWluZyBwcm9wb3NlZCBp
biBSRkM0MDA2YmlzIGlzOjxicj4NCjxicj4NCiZuYnNwOyBTdWJzY3JpcHRpb24tSWQtRXh0ZW5z
aW9uIDo6PSAmbHQ7IEFWUCBIZWFkZXI6IFhYWCAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbIFN1YnNjcmlwdGlvbi1JZC1FMTY0IF08YnI+
DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1sgU3Vic2Ny
aXB0aW9uLUlkLUlNU0kgXTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7WyBTdWJzY3JpcHRpb24tSWQtU0lQLVVSSSBdPGJyPg0KJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbIFN1YnNjcmlwdGlvbi1JZC1OQUkg
XTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7WyBT
dWJzY3JpcHRpb24tSWQtUHJpdmF0ZSBdPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOypbIEFWUCBdPGJyPg0KPGJyPg0KU28sIGluIG9yZGVyIHRvIGFkZCBhIG5l
dyB0eXBlIChwb3N0IFJGQzQwMDZiaXMpLCB5b3Ugd291bGQgbmVlZCB0byBzdWJtaXQgZHJhZnQg
d2l0aCBhbiBBVlAgZGVmaW5pdGlvbiBpbiBpdCB0byBjb3VsZCBiZSBhZGRlZCB0byB0aGUgU3Vi
c2NyaXB0aW9uLUlkLUV4dGVuc2lvbiBhcyBpdCBpcyBleHRlbnNpYmxlLjxicj4NClRoaXMgbmV3
IGRyYWZ0IHdvdWxkIGJlIGNvbXBsaWFudCB3aXRoIFJGQzQwMDZiaXMgYW5kIHdpbGwgdGhlcmVm
b3JlIG5vdCByZXF1aXJlIGEgbmV3IGFwcGxpY2F0aW9uIElELjxicj4NCjxicj4NCkJlc3QgUmVn
YXJkcyw8YnI+DQo8YnI+DQpZdXZhbDxicj4NCjxicj4NCjxicj4NCkZyb206IE1pc2hhIFpheXRz
ZXYgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWlzaGEuemF5dHNldi5ydXNAZ21haWwuY29tIj5t
aXNoYS56YXl0c2V2LnJ1c0BnbWFpbC5jb208L2E+XTxicj4NClNlbnQ6IFNhdHVyZGF5LCBKYW51
YXJ5IDI4LCAyMDE3IDExOjA3IFBNPGJyPg0KVG86IFl1dmFsIExpZnNoaXR6PGJyPg0KQ2M6IEdh
cmRlbGxhLCBNYXJ5c2UgKE5va2lhIC0gRlIpOyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9y
ZyI+ZGltZUBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW0RpbWVdIFJGQzQwMDZiaXMg
LSBTdWJzY3JpcHRpb24tSWQtRXh0ZW5zaW9uIEFWUDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi
cj4NCkhpIFl1dmFsLDxicj4NCjxicj4NCk1heSBJIGFzayB5b3Ugc2V2ZXJhbCBxdWVzdGlvbnMg
dG8gYmUgYWJsZSB0byB1bmRlcnN0YW5kIHRoZSB3aG9sZSBzaXR1YXRpb246PGJyPg0KPGJyPg0K
MS4gV2h5IGFyZSB5b3UgcHJvcG9zaW5nIHRvIGFkZCBuZXcgZXh0ZW5kYWJsZSBBVlBzIG9ubHkg
Zm9yIHNvbWUgb2YgdGhlIEFWUHMgbGlzdGVkIGluIHNlY3Rpb24gMTI/PGJyPg0KSSB0aGluayB0
aGUgc2FtZSBjb25jZXJuIGlzIGFwcGxpY2FibGUgZm9yIGFsbCB0aGVzZSBBVlBzLCBpc24ndD88
YnI+DQo8YnI+DQoyLiBDb3VsZCB5b3UgY2xhcmlmeSB3aGF0IG9mZmljaWFsIHByb2NlZHVyZSB0
byBhc3NpZ24gbmV3IGF2YWlsYWJsZSB2YWx1ZXMgaXMgbWVhbnQgaGVyZT88YnI+DQpJdCBpcyBu
b3Qgd29ya2luZyB3L28gZGVmaW5pbmcgbmV3IEFwcGxpY2F0aW9uLUlEIGFzIHlvdSBtZW50aW9u
ZWQgYWJvdmU/PGJyPg0KPGJyPg0KPGJyPg0KMTIuMTYuJm5ic3A7IFN1YnNjcmlwdGlvbi1JZC1U
eXBlIEFWUDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtBcyBkZWZpbmVkIGluIFNlY3Rpb24gOC40
NywgdGhlIFN1YnNjcmlwdGlvbi1JZC1UeXBlIEFWUCBpbmNsdWRlczxicj4NCiZuYnNwOyAmbmJz
cDtFbnVtZXJhdGVkIHR5cGUgdmFsdWVzIDAgLSA0LiZuYnNwOyBJQU5BIGhhcyBjcmVhdGVkIGFu
ZCBpcyBtYWludGFpbmluZyBhPGJyPg0KJm5ic3A7ICZuYnNwO25hbWVzcGFjZSBmb3IgdGhpcyBB
VlAuJm5ic3A7IEFsbCByZW1haW5pbmcgdmFsdWVzIGFyZSBhdmFpbGFibGUgZm9yPGJyPg0KJm5i
c3A7ICZuYnNwO2Fzc2lnbm1lbnQgYnkgYSBEZXNpZ25hdGVkIEV4cGVydCBbUkZDMjQzNF0uPGJy
Pg0KPGJyPg0KRXhjdXNlIG1lIGluIGFkdmFuY2UgaWYgd2hhdCBJJ20gYXNraW5nIGFib3V0IGFy
ZSB3ZWxsLWtub3duIHRoaW5ncy48YnI+DQpCdXQgc3RpbGwgcGxlYXNlIGNsYXJpZnkgdGhlbSBh
dCBsZWFzdCBmb3IgbWUuLi48YnI+DQo8YnI+DQpUaGFua3MgYSBsb3QgaW4gYWR2YW5jZSE8YnI+
DQo8YnI+DQovTWlzaGE8YnI+DQo8YnI+DQoyMDE3LTAxLTI1IDExOjI5IEdNVCYjNDM7MDM6MDAg
WXV2YWwgTGlmc2hpdHogJmx0OzxhIGhyZWY9Im1haWx0bzp5bGlmc2hpdHpAc2FuZHZpbmUuY29t
Ij55bGlmc2hpdHpAc2FuZHZpbmUuY29tPC9hPiZndDs6PGJyPg0KSGkgTWFyeXNlLDxicj4NClRo
ZSBpZGVhIGlzIHRoZSBmb2xsb3dpbmc6PGJyPg0K4oCiJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHRoZSBDQyBjbGllbnQgd2FudCB0byB3b3JrIHdp
dGggUkZDNDAwNmJpcyBvbmx5IENDIHNlcnZlciwgYW5kIHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQg
dGhlIHN1YnNjcmlwdGlvbiBJRCBpcyB1bmRlcnN0b29kIGJ5IHRoZSBzZXJ2ZXIsIGl0IG1heSBz
ZXQgdGhlIE0tYml0LiBBbnkgUkZDNDAwNiBzZXJ2ZXIgd2lsbCByZXBseSB3aXRoIERJQU1FVEVS
X0FWUF9VTlNVUFBPUlRFRCAoNTAwMSk8YnI+DQrigKImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIENDIGNsaWVudCBpcyBub3Qgc3VyZSB3aGV0
aGVyIHRoZSBDQyBzZXJ2ZXJzIGFyZSBSRkM0MDA2IG9yIFJGQzQwMDZiaXMsIG9yIGhhdmUgYSBt
aXggb2Ygc2VydmVycywgYW5kIHdhbnQgdG8gd29yayB3aXRoIGJvdGgsIGl0IG1heSBub3Qgc2V0
IHRoZSBNLWJpdDxicj4NCm8mbmJzcDsmbmJzcDsgSW4gdGhpcyBjYXNlIGl0IHdvdWxkIHNlbmQg
Ym90aCBBVlBzIGZvciB0aGUgb2xkIHR5cGVzLCBzbyB0aGF0IHRoZSBuZXcgQVZQIHdpbGwgYmUg
aWdub3JlZCBieSB0aGUgUkZDNDAwNiBzZXJ2ZXJzPGJyPg0KbyZuYnNwOyZuYnNwOyBJbiBhIGNh
c2Ugb2YgYSBuZXcgdHlwZSBvZiBzdWJzY3JpcHRpb24sIG5vdCBjb3ZlcmVkIGluIFJGQzQwMDYs
IGl0IG1heSBzZW5kIHRoZSBuZXcgQVZQIHdpdGggdGhlIE0tYml0IHNldCwgY2F1c2luZyBhbnkg
b2xkIHNlcnZlciB0byByZXBseSB3aXRoIERJQU1FVEVSX0FWUF9VTlNVUFBPUlRFRCAoNTAwMSku
IEl0IG1heSBhbHNvIHNlbmQgdGhlIG5ldyBBVlAgd2l0aG91dCB0aGUgTS1iaXQgc2V0LCBoZXJl
IHRoZSBzZXJ2ZXIgd291bGQNCiBqdXN0IGlnbm9yZSB0aGUgQVZQLCBidXQgd291bGQgcHJvYmFi
bHkgcmVwbHkgRElBTUVURVJfTUlTU0lOR19BVlAgKDUwMDUpIGFzIGl0IHdpbGwgbm90IGhhdmUg
YW55IHN1YnNjcmlwdGlvbiBJRDxicj4NCiZuYnNwOzxicj4NCll1dmFsPGJyPg0KJm5ic3A7PGJy
Pg0KRnJvbTogR2FyZGVsbGEsIE1hcnlzZSAoTm9raWEgLSBGUikgW21haWx0bzo8YSBocmVmPSJt
YWlsdG86bWFyeXNlLmdhcmRlbGxhQG5va2lhLmNvbSI+bWFyeXNlLmdhcmRlbGxhQG5va2lhLmNv
bTwvYT5dPGJyPg0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyNCwgMjAxNyA1OjI1IFBNPGJyPg0K
VG86IFl1dmFsIExpZnNoaXR6OyA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBp
ZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSRTogUkZDNDAwNmJpcyAtIFN1YnNjcmlwdGlvbi1J
ZC1FeHRlbnNpb24gQVZQPGJyPg0KJm5ic3A7PGJyPg0KSGkgWXV2YWwsPGJyPg0KJm5ic3A7PGJy
Pg0KVGhhbmtzIGZvciBjb250aW51aW5nIG9uIHRoaXMuPGJyPg0KSSBhbSBub3Qgc3VyZSB0byB1
bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g4oCcbWF54oCdIGFuZCDigJxtdXN04oCd
LCBzaW5jZSB3aXRoICZuYnNwO+KAnE1heeKAnSB3ZSBjYW4gZW5kIGhhdmluZyB0aGUgTS1iaXQg
c2V0IGJ5IHRoZSBSRkM0MDA2YmlzIENDIGNsaWVudC48YnI+DQpJIGd1ZXNzIGZyb20gdGhlIHBy
b3RvY29s4oCZcyBwZXJzcGVjdGl2ZSDigJxtYXnigJ0gYW5kIOKAnG11c3TigJ0gbWFrZXMgbm8g
ZGlmZmVyZW5jZSByaWdodD88YnI+DQombmJzcDs8YnI+DQpCUjxicj4NCk1hcnlzZTxicj4NCiZu
YnNwOzxicj4NCkZyb206IERpTUUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2Vz
QGlldGYub3JnIj5kaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgWXV2YWwg
TGlmc2hpdHo8YnI+DQpTZW50OiB2ZW5kcmVkaSAxMyBqYW52aWVyIDIwMTcgMTU6MjQ8YnI+DQpU
bzogPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0K
U3ViamVjdDogW0FMVV0gW0RpbWVdIFJGQzQwMDZiaXMgLSBTdWJzY3JpcHRpb24tSWQtRXh0ZW5z
aW9uIEFWUDxicj4NCiZuYnNwOzxicj4NCkhpIEFsbCw8YnI+DQpBcyBwYXJ0IG9mIHRoZSBSRkM0
MDA2YmlzIHdvcmsgdGhlcmUgYXJlIHNldmVyYWwgQVZQcyB0aGF0IHdlIHBsYW4gb24gbWFraW5n
IGZ1dHVyZSBwcm9vZiAoU2VlIGFsc286DQo8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcv
dHJhYy9kaW1lL3RpY2tldC85NSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdHJhYy5pZXRmLm9y
Zy90cmFjL2RpbWUvdGlja2V0Lzk1PC9hPikuIEZvciBleGFtcGxlLCBTdWJzY3JpcHRpb24tSWQg
QVZQIGNhbm5vdCBiZSBleHRlbmRlZCB0byBuZXcgdHlwZXMgd2l0aG91dCBjaGFuZ2luZyB0aGUg
ZW51bWVyYXRpb24gaW4gU3Vic2NyaXB0aW9uLUlkLVR5cGUgQVZQLCB3aGljaCBpbiB0dXJuDQog
cmVxdWlyZXMgYSBuZXcgYXBwbGljYXRpb24gSUQgKHNvbWV0aGluZyB3ZSByZWFsbHkgd2FudCB0
byBhdm9pZCkuPGJyPg0KVG8gc29sdmUgdGhpcyBpc3N1ZSB3ZSBwcm9wb3NlIGFkZGluZyBhIG5l
dywgZXh0ZW5kYWJsZSBBVlAuIEluIHRoaXMgZXhhbXBsZTo8YnI+DQombmJzcDs8YnI+DQpTdWJz
Y3JpcHRpb24tSWQtRXh0ZW5zaW9uIDo6PSAmbHQ7IEFWUCBIZWFkZXI6IFhYWCAmZ3Q7PGJyPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFsg
U3Vic2NyaXB0aW9uLUlkLUUxNjQgXTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbIFN1YnNjcmlwdGlvbi1JZC1JTVNJIF08YnI+DQom
bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7WyBT
dWJzY3JpcHRpb24tSWQtU0lQLVVSSSBdPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFsgU3Vic2NyaXB0aW9uLUlkLU5BSSBdPGJyPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFsg
U3Vic2NyaXB0aW9uLUlkLVByaXZhdGUgXTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqWyBBVlAgXTxicj4NCiZuYnNwOzxicj4NCldoZW4gbG9v
a2luZyBpbnRvIFN1YnNjcmlwdGlvbi1JRC1FeHRlbnNpb24gQVZQICZuYnNwO2hlYWRlciBmbGFn
cyBJIHJhbiBpbnRvIGEgcHJvYmxlbS4gVGhlIGV4aXN0aW5nIFN1YnNjcmlwdGlvbi1JRCBBVlAg
KGFuZCBpdHMgc3ViLUFWUHMpIGFyZSBhbGwgbWFya2VkIHdpdGggdGhlIE0tYml0IGFzIGEg4oCc
bXVzdOKAnSwgcHJvYmFibHkgYmVjYXVzZSB0aGV5IGhvbGQgdGhlIHN1YnNjcmliZXLigJlzIG5h
bWUgd2hpY2ggaXMgY3JpdGljYWwgaW5mb3JtYXRpb24uPGJyPg0KSG93ZXZlciwgaW4gb3JkZXIg
Zm9yIGEgUkZDNDAwNmJpcyBDQyBjbGllbnQgdG8gYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB3aXRo
IGFuIFJGQzQwMDYgQ0Mtc2VydmVyLCB0aGV5IHdpbGwgaGF2ZSB0byBiZSBtYXJrZWQgYXMg4oCc
bWF54oCdLjxicj4NCiZuYnNwOzxicj4NCldvdWxkIGFwcHJlY2lhdGUgeW91ciBwb2ludCBvZiB2
aWV3IG9uIHRoYXQgdG9waWM/PGJyPg0KJm5ic3A7PGJyPg0KQmVzdCBSZWdhcmRzLDxicj4NCiZu
YnNwOzxicj4NCll1dmFsPGJyPg0KJm5ic3A7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpEaU1FIG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5EaU1FQGlldGYub3JnPC9hPjxicj4NCjxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_C43C255C7106314F8D13D03FA20CFE497002DB6Bwtlexchp1sandvi_--


From nobody Tue Jan 31 08:49:28 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36274129FBF for ; Tue, 31 Jan 2017 08:49:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.057
X-Spam-Level: 
X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo4kzOVcSIso for ; Tue, 31 Jan 2017 08:49:24 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0098.outbound.protection.outlook.com [104.47.1.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB0E129FBB for ; Tue, 31 Jan 2017 08:49:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=upQMeBsBdGCcmqKBF7ZCZBKutTNn04FyQ/oNK0yfi24=; b=O5Zd02EL3ITNQbbwrv9BY23MSczrc1lMSZ5+cYSOYNzU6s/uHprHBTP0HURGU3zbSdHOc8pldFUOl0tBzpBXtgaM1eL++MaG0hQXPfarQdwzk8szq/6N4aneGAMJS0XWN2NShEcVUfjb8FngciXI+vvOp26cBsIK1AA53/6mmGo=
Received: from HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) by HE1PR0701MB2860.eurprd07.prod.outlook.com (10.168.91.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Tue, 31 Jan 2017 16:49:21 +0000
Received: from HE1PR0701MB2857.eurprd07.prod.outlook.com ([10.168.91.147]) by HE1PR0701MB2857.eurprd07.prod.outlook.com ([10.168.91.147]) with mapi id 15.01.0874.019; Tue, 31 Jan 2017 16:49:20 +0000
From: "Gardella, Maryse (Nokia - FR)" 
To: Yuval Lifshitz , "dime@ietf.org" 
Thread-Topic: RFC4006bis - Subscription-Id-Extension AVP
Thread-Index: AdJtpzBPVPEgVuSXSxiP12VbbHIMngFfVP8wAO+8a8ABMmjOsA==
Date: Tue, 31 Jan 2017 16:49:20 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=maryse.gardella@nokia.com; 
x-originating-ip: [135.245.240.250]
x-ms-office365-filtering-correlation-id: 12144459-4c74-4f8b-63ea-08d449f91a92
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2860; 
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2860; 7:wPLHwHQamMkbZETMBnjeNYwaKd0tCF6JNF2MZWg828DEfGu3hUy6qnt/92R3Jn635zjcn6qC0l0tQia2z0HtPXAGUm1rqtYzBVlfoSvV1P+FbaewiGSeqwLFDoXhZAS+7f0Fm0vDxDBf6in3ts55eHZDc/w8S1H7R88RPzvNhOFYtTcuQ7/pQxln/Gco20fqWqQmSiHqNQ1+Kei5f9YgPkOd9+pJx7oHg50RI7UkSvy/TNAwJodL8Ydh7kxGEBuKvIDG7mAERNKPpR4Kz9D8Xdu7bRQ5Qo0GMR6AyjK91rLyx52T1A8W2pKm3qgm9xGzFW4U7gFlxYJTar8i/PC7dhWWgcCqLUlklVIiL9StmU66Atb/p1DLgs+XY0c6Y38W2sjwYBGjrN3bF96WZplaJ2vhQctbSBSt5qMHtsAqAgwA/krUfQDLXbJVa+bZtmvCp/Jnvw4sUltgcSYwwquSYrbBmk/xYm1+cRUtzo9omaDm4WM+zo/xtOpFt7IAzLYJriCZob059uSzpP4EYYr/CAAwgCnJ/sKsBg/jil4ORi9bVFtmtUS4wjnUCp0c8JkP
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(82608151540597)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:HE1PR0701MB2860; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2860; 
x-forefront-prvs: 0204F0BDE2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39840400002)(39850400002)(39410400002)(39450400003)(53754006)(51914003)(199003)(189002)(377454003)(55016002)(7696004)(33656002)(99286003)(2501003)(25786008)(122556002)(107886002)(101416001)(606005)(6116002)(3846002)(97736004)(5660300001)(102836003)(5001770100001)(6436002)(790700001)(2906002)(6506006)(3280700002)(189998001)(66066001)(2950100002)(76176999)(38730400001)(77096006)(68736007)(54356999)(230783001)(3660700001)(92566002)(86362001)(19609705001)(53936002)(81156014)(9686003)(7906003)(50986999)(7736002)(6306002)(8676002)(74316002)(236005)(54896002)(8936002)(81166006)(106356001)(2900100001)(229853002)(105586002)(9326002)(21314002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2860; H:HE1PR0701MB2857.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB28577DCAD16325E9CCB0289DFC4A0HE1PR0701MB2857_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 16:49:20.5746 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2860
Archived-At: 
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2017 16:49:27 -0000

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

Hi Yuval,

Thanks for these explanations.


*         With "If the CC client want to work with RFC4006bis only CC serve=
r, and want to make sure that the subscription ID is understood by the serv=
er, it may set the M-bit. Any RFC4006 server will reply with DIAMETER_AVP_U=
NSUPPORTED (5001)
=3D> Does this mean it is acceptable here, for a CC client to use the same =
application ID, extended with a new AVP and M-bit set, based on "CC Applica=
tion-level requirement" consideration? i.e. and not considering the rejecti=
on as a backward compatibility issue?

*         With "If the CC client is not sure whether the CC servers are RFC=
4006 or RFC4006bis... it may not set the M-bit

o   In this case it would send both AVPs for the old types, so that the new=
 AVP will be ignored by the RFC4006 servers

=3D> what would be the RFC4006bis server behavior receiving 2 AVPs with old=
 type?

o   In a case of a new type of subscription, not covered in RFC4006,
it may send the new AVP with the M-bit set, causing any old server to reply=
 with DIAMETER_AVP_UNSUPPORTED (5001).

=3D> same Q as for first bullet

it may also send the new AVP without the M-bit set, here the server would j=
ust ignore the AVP, but would probably reply DIAMETER_MISSING_AVP (5005) as=
 it will not have any subscription ID

=3D> is it really the case the RFC4006bis server could alternatively, inste=
ad of ignoring the AVP, send an Error? Based on application level decision?


I am just trying to understand the implication of the "may", and especially=
 if it is really a mean to avoid creating a new Application Id while comply=
ing  with the rule, and also in case of M-bit not set, if possible for a se=
rver to reply with an error (instead of ignoring) if AVP not understood.

Maryse

From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com]
Sent: mercredi 25 janvier 2017 09:30
To: Gardella, Maryse (Nokia - FR) ; dime@ietf.or=
g
Cc: Yuval Lifshitz 
Subject: RE: RFC4006bis - Subscription-Id-Extension AVP

Hi Maryse,
The idea is the following:

*         If the CC client want to work with RFC4006bis only CC server, and=
 want to make sure that the subscription ID is understood by the server, it=
 may set the M-bit. Any RFC4006 server will reply with DIAMETER_AVP_UNSUPPO=
RTED (5001)

*         If the CC client is not sure whether the CC servers are RFC4006 o=
r RFC4006bis, or have a mix of servers, and want to work with both, it may =
not set the M-bit

o   In this case it would send both AVPs for the old types, so that the new=
 AVP will be ignored by the RFC4006 servers

o   In a case of a new type of subscription, not covered in RFC4006, it may=
 send the new AVP with the M-bit set, causing any old server to reply with =
DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP without the M=
-bit set, here the server would just ignore the AVP, but would probably rep=
ly DIAMETER_MISSING_AVP (5005) as it will not have any subscription ID

Yuval

From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]
Sent: Tuesday, January 24, 2017 5:25 PM
To: Yuval Lifshitz; dime@ietf.org
Subject: RE: RFC4006bis - Subscription-Id-Extension AVP

Hi Yuval,

Thanks for continuing on this.
I am not sure to understand the difference between "may" and "must", since =
with  "May" we can end having the M-bit set by the RFC4006bis CC client.
I guess from the protocol's perspective "may" and "must" makes no differenc=
e right?

BR
Maryse

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz
Sent: vendredi 13 janvier 2017 15:24
To: dime@ietf.org
Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP

Hi All,
As part of the RFC4006bis work there are several AVPs that we plan on makin=
g future proof (See also: https://trac.ietf.org/trac/dime/ticket/95). For e=
xample, Subscription-Id AVP cannot be extended to new types without changin=
g the enumeration in Subscription-Id-Type AVP, which in turn requires a new=
 application ID (something we really want to avoid).
To solve this issue we propose adding a new, extendable AVP. In this exampl=
e:

Subscription-Id-Extension ::=3D < AVP Header: XXX >
                             [ Subscription-Id-E164 ]
                             [ Subscription-Id-IMSI ]
                             [ Subscription-Id-SIP-URI ]
                             [ Subscription-Id-NAI ]
                             [ Subscription-Id-Private ]
                            *[ AVP ]

When looking into Subscription-ID-Extension AVP  header flags I ran into a =
problem. The existing Subscription-ID AVP (and its sub-AVPs) are all marked=
 with the M-bit as a "must", probably because they hold the subscriber's na=
me which is critical information.
However, in order for a RFC4006bis CC client to be able to communicate with=
 an RFC4006 CC-server, they will have to be marked as "may".

Would appreciate your point of view on that topic?

Best Regards,

Yuval


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











Hi Yuval, 


 


Thanks for these explanations. 


 


·        
With “If=
 the CC client want to work with RFC4006bis only CC server, and want to mak=
e sure that the subscription ID is understood by the server, it may set the=
 M-bit. Any RFC4006 server will reply with
 DIAMETER_AVP_UNSUPPORTED (5001)


=3D> Does this mean =
it is acceptable here, for a CC client
to use the same application ID, extended with a new AVP and M-bit se=
t, based on “CC Application-level requirement” consideration? i=
.e. and not considering the rejection as a backward compatibility issue?


•    &n=
bsp;   
With “If the CC=
 client is not sure whether the CC servers are RFC4006 or RFC4006bis…=
 it may not set the M-bit



o  
In this case i=
t would send both AVPs for the old types, so that the new AVP will be ignor=
ed by the RFC4006 servers


=3D> what wou=
ld be the RFC4006bis server behavior receiving 2 AVPs with old type?




o  
In a case of a=
 new type of subscription, not covered in RFC4006,


it may send the new AVP with the M-bit set, causing any old server t=
o reply with DIAMETER_AVP_UNSUPPORTED (5001).


=3D> same Q a=
s for first bullet



it may also send the new AVP without the M-bit set, here the =
server would just ignore the AVP, but would probably reply DIAMETER_MISSING=
_AVP (5005) as it will not have any subscription
 ID


=3D> is it re=
ally the case the RFC4006bis server could alternatively, instead of ignorin=
g the AVP, send an Error? Based on application level decision?

 


I am just trying to understand the implication of th=
e “may”, and especially if it is really a mean to avoid creatin=
g a new Application Id while complying  with the rule, and also in cas=
e of M-bit not set, if possible for a server to reply
 with an error (instead of ignoring) if AVP not understood.   &nb=
sp;


 


Maryse


 






From: Yuval Lifshitz [mailto:ylifshitz@sandvi=
ne.com] 

Sent: mercredi 25 janvier 2017 09:30

To: Gardella, Maryse (Nokia - FR) <maryse.gardella@nokia.com>;=
 dime@ietf.org

Cc: Yuval Lifshitz <ylifshitz@sandvine.com>

Subject: RE: RFC4006bis - Subscription-Id-Extension AVP





 


Hi Maryse,<=
/span>


The idea is the follow=
ing: 



·        
If the CC clie=
nt want to work with RFC4006bis only CC server, and want to make sure that =
the subscription ID is understood by the server, it may set the M-bit. Any =
RFC4006 server will reply with DIAMETER_AVP_UNSUPPORTED
 (5001)


·        
If the CC clie=
nt is not sure whether the CC servers are RFC4006 or RFC4006bis, or have a =
mix of servers, and want to work with both, it may not set the M-bit



o  
In this case i=
t would send both AVPs for the old types, so that the new AVP will be ignor=
ed by the RFC4006 servers



o  
In a case of a=
 new type of subscription, not covered in RFC4006, it may send the new AVP =
with the M-bit set, causing any old server to reply with DIAMETER_AVP_UNSUP=
PORTED (5001). It may also send the
 new AVP without the M-bit set, here the server would just ignore the AVP, =
but would probably reply DIAMETER_MISSING_AVP (5005) as it will not have an=
y subscription ID


 


Yuval


 






From: Gardella, Maryse (Nokia - FR) [<=
a href=3D"mailto:maryse.gardella@nokia.com">mailto:maryse.gardella@nokia.co=
m]


Sent: Tuesday, January 24, 2017 5:25 PM

To: Yuval Lifshitz; dime@ietf.org

Subject: RE: RFC4006bis - Subscription-Id-Extension AVP






 


Hi Yuval, 


 


Thanks for continuing on this.


I am not sure to understand the difference between &=
#8220;may” and “must”, since with  “May”=
 we can end having the M-bit set by the RFC4006bis CC client.

I guess from the protocol’s perspective “=
;may” and “must” makes no difference right?

 


BR


Maryse


 






From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Yuval Lifshitz

Sent: vendredi 13 janvier 2017 15:24

To: dime@ietf.org

Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP






 


Hi All,


As part of the RFC4006bis work there are several AVP=
s that we plan on making future proof (See also:
https://trac.ietf.org=
/trac/dime/ticket/95). For example, Subscription-Id AVP cannot be exten=
ded to new types without changing the enumeration in Subscription-Id-Type A=
VP, which in turn requires a new application
 ID (something we really want to avoid).


To solve this issue we propose adding a new, extenda=
ble AVP. In this example:


 


Subscription-Id-Extension ::=3D < AVP Heade=
r: XXX >


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-E164 ]


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-IMSI ]


        &nb=
sp;            =
        [ Subscription-Id-SIP-URI ]=



       &nbs=
p;            &=
nbsp;        [ Subscription-Id-NAI ]


       &nbs=
p;            &=
nbsp;        [ Subscription-Id-Private ]=



       &nbs=
p;            &=
nbsp;       *[ AVP ]


 


When looking into Subscription-ID-Extension AVP &nbs=
p;header flags I ran into a problem. The existing Subscription-ID AVP (and =
its sub-AVPs) are all marked with the M-bit as a “must”, probab=
ly because they hold the subscriber’s name which is
 critical information.


However, in order for a RFC4006bis CC client to be a=
ble to communicate with an RFC4006 CC-server, they will have to be marked a=
s “may”.



 


Would appreciate your point of view on that topic?


 


Best Regards,


 


Yuval


 






--_000_HE1PR0701MB28577DCAD16325E9CCB0289DFC4A0HE1PR0701MB2857_--


From nobody Tue Jan 31 12:07:19 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28C5129A16 for ; Tue, 31 Jan 2017 12:07:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb5K0j9Fj5Lz for ; Tue, 31 Jan 2017 12:07:15 -0800 (PST)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CB9129537 for ; Tue, 31 Jan 2017 12:07:14 -0800 (PST)
Received: by mail-lf0-x22a.google.com with SMTP id v186so217514428lfa.1 for ; Tue, 31 Jan 2017 12:07:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YlLiQgCuG7EiIGH04n/8P+ZOhYTgEnd+TIp3vvUyUxQ=; b=OGFUlC4cRKCmsJUGAuVSLnnyY6ZdcMq2NGux+vcvr9iWOex2RB9IVhheX+e368zpAu Lfs80XTGd921et5Kca6oOUKg0J7zIAZznnfy2EsCkByg6UO6XZUzWqubwE6YW9tS9Wc2 k1Xm7BVM6zdtzv7jZ0WZclRqsCy9kExafUXjTg+RBLEj2yFzq8oy723IWIuUvOXNtdXm YlebfVv8ugWz0QBktWaVe4FxWB9cfckM0nnMFGv0DICvGFKw7NWJEypStoDnfgiGWg1r jcGjMqPw1UiKVjev7ZBIQMRBKkO1dGmvZKA0WsMvIpTg1UAPfFH8hmOLWOA5wfGlDnks sIIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YlLiQgCuG7EiIGH04n/8P+ZOhYTgEnd+TIp3vvUyUxQ=; b=c1p6a9FxZk9XeKisTZsBVB78gysMeDL34XTMWArD/7OVHUF7vVXka5fNwuhv7eBqIb 0padZmxAMTei/2DUPqPpmMV7v2OxxV58KET0D9Q2oekpixbnljO+Nm5oXF6CHoAeJycA eI2e4JiPEQkWw43HSAVZy4J35KmcKX9jcZlrMdWMdXtVR60vChhfA2QPh7T5B6V/bEsc 2a5Z6JsyAlYc1jZb5OhJDaObLxVA1lAT/yvwA0g6WMu1Y06Ry7jM6reuoLhJMkFWSzOy EUGFuXj1qFyz3yi+NU/NYRdq6nwLQWu0Olfhcc/vM7Irbliyvp3XbKrPzt0uhTbpoG/i BwRA==
X-Gm-Message-State: AIkVDXIZpIdt5ArmQLEOV8sx4X1VMXT/v9kD0fy+XKSxiFKsrSdgys6QJJalpy3/4EQSX82q2PSLp+TrQHLvLg==
X-Received: by 10.46.72.18 with SMTP id v18mr10183056lja.5.1485893232427; Tue, 31 Jan 2017 12:07:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Tue, 31 Jan 2017 12:07:11 -0800 (PST)
In-Reply-To: 
References:       
From: Misha Zaytsev 
Date: Tue, 31 Jan 2017 23:07:11 +0300
Message-ID: 
To: Yuval Lifshitz 
Content-Type: multipart/alternative; boundary=f403045ea2824b0c950547697a78
Archived-At: 
Cc: "dime@ietf.org" , "Gardella, Maryse \(Nokia - FR\)" 
Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2017 20:07:18 -0000

--f403045ea2824b0c950547697a78
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Yuval,

I almost agree with your explanations that you sent to Maryse, except one
bullet:

In a case of a new type of subscription, not covered in RFC4006, it may
send the new AVP with the M-bit set, causing any old server to reply with
DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP without the
M-bit set, here the server would just ignore the AVP, but would probably
reply DIAMETER_MISSING_AVP (5005) as it will not have any subscription ID

RFC4006 server should not reply with DIAMETER_MISSING_AVP (5005) result
code according to RFC6733, since Subscription-Id AVP is *not* marked as
required in CCR definition:

      A received command that is missing AVPs that are defined as
      required in the commands CCF; examples are AVPs indicated as
      *{AVP}*.  The receiver issues an answer with the Result-Code set to
      DIAMETER_MISSING_AVP and creates an AVP with the AVP Code and
      other fields set as expected in the missing AVP.  The created AVP
      is then added to the Failed-AVP AVP.


The remaining part is according to the RFC6733 from my point of view.


All in all, to set M-bit or not, depends on what reaction you want to
see from RFC4006 server.


/Misha



2017-01-30 11:29 GMT+03:00 Yuval Lifshitz :

> Hi Misha,
>
> We didn=E2=80=99t consider the option of using a bitmap, but I=E2=80=99m =
open to this
> idea. IMO, it would be more difficult managing the addition of new values
> in the case of a bitmap than in the case of adding new AVPs.  OTOH, addin=
g
> a bitmap will be less changes to the RFC.
>
> In our proposal the AVPs are marked as optional, and the M-bit **may** be
> set. I sent an explanation to Maryse on the M-bit =E2=80=93 please see be=
low, and
> let me know if you have comments on that.
>
> As ABNF cannot show the concept of =E2=80=9Cone and only one AVP=E2=80=9D=
 I will update
> the text to state that explicitly (added: https://github.com/lbertz02/
> rfc4006bis/issues/18)
>
>
>
> Yuval
>
>
>
> *From:* Misha Zaytsev [mailto:misha.zaytsev.rus@gmail.com]
> *Sent:* Sunday, January 29, 2017 8:21 PM
>
> *To:* Yuval Lifshitz
> *Cc:* Gardella, Maryse (Nokia - FR); dime@ietf.org
> *Subject:* Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
>
> Hi Yuval,
>
>
>
> Thanks a lot for your clarifications! Now it seems I see your concern.
>
>
>
> As I can see the problem is that there is no possibility to extend the
> defined AVPs of type Enumerated in a backward compatible way. For me it
> means that all enumerate AVPs defined in RFC4006 (listed in section 12) i=
s
> a matter of your investigation. Not the grouped ones, but the ones that a=
re
> used as indicators in these grouped AVPs.
>
>
>
> Following the recommendations in https://tools.ietf.org/
> html/rfc7423#section-5.6 that you pointed out, I think bitmask based AVPs
> may be a way out in the current situation. Such AVP will be marked as
> mandatory. While only one bit of this bitmask MUST be set.
>
>
>
>  Subscription-Id-Extension ::=3D < AVP Header: XXX >
>                              [ Subscription-Id-Type-Indicator ]
>                              [Subscrition-Id-Data]
>
>
> Have you considered this option? Or probably I'm missing something..
>
>
>
> However, if we follow the way you are proposing with several mutually
> exclusive AVPs, then these AVPs should be marked as not mandatory. While =
in
> the description of the appropriate grouped AVP it should be stated that
> only one of these AVPs MUST be present.
>
>
>
> /Misha
>
>
>
>
>
> 2017-01-29 11:29 GMT+03:00 Yuval Lifshitz :
>
> Hi Misha,
> There is nothing =E2=80=9Cwell known=E2=80=9D in these issues and I=E2=80=
=99ll be happy to clarify!
>
> (1) During IETF96 a question came regarding the support of the IMEI user
> equipment type =E2=80=93 currently not one of the enumerated types of the
> User-Equipment-Info-Type AVP (IMEISV is there but not IMEI). As a result =
of
> this discussion, and due to the enum extension limitations (see here:
> https://tools.ietf.org/html/rfc7423#section-5.6), we were asked to do an
> analysis on which enumerated AVPs requires extensibility. The results wer=
e
> captured in the following ticket: https://trac.ietf.org/trac/
> dime/ticket/95
> For better clarity I=E2=80=99m posting here the actual analysis of AVPs. =
Some of
> them didn=E2=80=99t need to be extensible (in our view), some of them wer=
e already
> extensible and the rest were added to the ticket:
>
>                      AVP  Section
>    Attribute Name    Code Defined Data Type
>    -----------------------------------------
>    CC-Money          413  8.22   Grouped    - not extensible, does not
> need to be
>    Cost-Information  423  8.7    Grouped    - not extensible, does not
> need to be
>    Final-Unit-       430  8.34   Grouped    - not extensible, will be
> replaced by QoS-Final-Unit-Indication that will be extensible
>      Indication
>    Granted-Service-  431  8.17   Grouped    - extensible
>      Unit
>    G-S-U-Pool-       457  8.30   Grouped    - not extensible, does not
> need to be
>      Reference
>    Multiple-Services 456  8.16   Grouped    - extensible
>     -Credit-Control
>    Redirect-Server   434  8.37   Grouped    - not extensible, has a
> problem similar to equipment type as it contains an enumerated type/value
> AVPs
>    Requested-Service 437  8.18   Grouped    - extensible
>      -Unit
>    Service-Parameter 440  8.43   Grouped    - not extensible, does not
> need to be
>      -Info
>    Subscription-Id   443  8.46   Grouped    - not extensible, has a
> problem similar to equipment type as it contains an enumerated type/value
> AVPs
>    Unit-Value        445  8.8    Grouped    - not extensible, does not
> need to be
>    Used-Service-Unit 446  8.19   Grouped    - extensible
>    User-Equipment    458  8.49   Grouped    - not extensible, will be
> replaced by an AVP that will be extensible
>      -Info
>
> Would appreciate your comments if you think differently about any of the
> AVPs above, or that we have missed other AVPs that needs to.
>
> (2) E.g adding new subscription ID.
>
> Unlike Subscription-Id-Type AVP which cannot be extended to a new type
> without a new application ID, a new AVP being proposed in RFC4006bis is:
>
>   Subscription-Id-Extension ::=3D < AVP Header: XXX >
>                              [ Subscription-Id-E164 ]
>                              [ Subscription-Id-IMSI ]
>                              [ Subscription-Id-SIP-URI ]
>                              [ Subscription-Id-NAI ]
>                              [ Subscription-Id-Private ]
>                            *[ AVP ]
>
> So, in order to add a new type (post RFC4006bis), you would need to submi=
t
> draft with an AVP definition in it to could be added to the
> Subscription-Id-Extension as it is extensible.
> This new draft would be compliant with RFC4006bis and will therefore not
> require a new application ID.
>
> Best Regards,
>
> Yuval
>
>
> From: Misha Zaytsev [mailto:misha.zaytsev.rus@gmail.com]
> Sent: Saturday, January 28, 2017 11:07 PM
> To: Yuval Lifshitz
> Cc: Gardella, Maryse (Nokia - FR); dime@ietf.org
> Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
>
> Hi Yuval,
>
> May I ask you several questions to be able to understand the whole
> situation:
>
> 1. Why are you proposing to add new extendable AVPs only for some of the
> AVPs listed in section 12?
> I think the same concern is applicable for all these AVPs, isn't?
>
> 2. Could you clarify what official procedure to assign new available
> values is meant here?
> It is not working w/o defining new Application-ID as you mentioned above?
>
>
> 12.16.  Subscription-Id-Type AVP
>
>    As defined in Section 8.47, the Subscription-Id-Type AVP includes
>    Enumerated type values 0 - 4.  IANA has created and is maintaining a
>    namespace for this AVP.  All remaining values are available for
>    assignment by a Designated Expert [RFC2434].
>
> Excuse me in advance if what I'm asking about are well-known things.
> But still please clarify them at least for me...
>
> Thanks a lot in advance!
>
> /Misha
>
> 2017-01-25 11:29 GMT+03:00 Yuval Lifshitz :
> Hi Maryse,
> The idea is the following:
> =E2=80=A2         If the CC client want to work with RFC4006bis only CC s=
erver,
> and want to make sure that the subscription ID is understood by the serve=
r,
> it may set the M-bit. Any RFC4006 server will reply with
> DIAMETER_AVP_UNSUPPORTED (5001)
> =E2=80=A2         If the CC client is not sure whether the CC servers are=
 RFC4006
> or RFC4006bis, or have a mix of servers, and want to work with both, it m=
ay
> not set the M-bit
> o   In this case it would send both AVPs for the old types, so that the
> new AVP will be ignored by the RFC4006 servers
> o   In a case of a new type of subscription, not covered in RFC4006, it
> may send the new AVP with the M-bit set, causing any old server to reply
> with DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP withou=
t
> the M-bit set, here the server would just ignore the AVP, but would
> probably reply DIAMETER_MISSING_AVP (5005) as it will not have any
> subscription ID
>
> Yuval
>
> From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]
> Sent: Tuesday, January 24, 2017 5:25 PM
> To: Yuval Lifshitz; dime@ietf.org
> Subject: RE: RFC4006bis - Subscription-Id-Extension AVP
>
> Hi Yuval,
>
> Thanks for continuing on this.
> I am not sure to understand the difference between =E2=80=9Cmay=E2=80=9D =
and =E2=80=9Cmust=E2=80=9D, since
> with  =E2=80=9CMay=E2=80=9D we can end having the M-bit set by the RFC400=
6bis CC client.
> I guess from the protocol=E2=80=99s perspective =E2=80=9Cmay=E2=80=9D and=
 =E2=80=9Cmust=E2=80=9D makes no
> difference right?
>
> BR
> Maryse
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz
> Sent: vendredi 13 janvier 2017 15:24
> To: dime@ietf.org
> Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP
>
> Hi All,
> As part of the RFC4006bis work there are several AVPs that we plan on
> making future proof (See also: https://trac.ietf.org/trac/dime/ticket/95)=
.
> For example, Subscription-Id AVP cannot be extended to new types without
> changing the enumeration in Subscription-Id-Type AVP, which in turn
> requires a new application ID (something we really want to avoid).
> To solve this issue we propose adding a new, extendable AVP. In this
> example:
>
> Subscription-Id-Extension ::=3D < AVP Header: XXX >
>                              [ Subscription-Id-E164 ]
>                              [ Subscription-Id-IMSI ]
>                              [ Subscription-Id-SIP-URI ]
>                              [ Subscription-Id-NAI ]
>                              [ Subscription-Id-Private ]
>                             *[ AVP ]
>
> When looking into Subscription-ID-Extension AVP  header flags I ran into =
a
> problem. The existing Subscription-ID AVP (and its sub-AVPs) are all mark=
ed
> with the M-bit as a =E2=80=9Cmust=E2=80=9D, probably because they hold th=
e subscriber=E2=80=99s
> name which is critical information.
> However, in order for a RFC4006bis CC client to be able to communicate
> with an RFC4006 CC-server, they will have to be marked as =E2=80=9Cmay=E2=
=80=9D.
>
> Would appreciate your point of view on that topic?
>
> Best Regards,
>
> Yuval
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
>
>

--f403045ea2824b0c950547697a78
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Yuval,

I almost agree with your expl=
anations that you sent to Maryse, except one bullet:

In a case of a new type of subscription, not covered in RFC=
4006, it may send the new AVP with the M-bit set, causing any old server to=
 reply with DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP w=
ithout the M-bit set, here the server would just ignore the AVP, but would =
probably reply DIAMETER_MISSING_AVP (5005) as it will not have any subscrip=
tion ID

RFC4006 server s=
hould not reply with DIAMETER_MISSING_AVP (5005) result code according to R=
FC6733, since Subscription-Id AVP is not marked as required in CCR d=
efinition:

      A received command that is missing AVPs that are defined as
      required in the commands CCF; examples are AVPs indicated as
      {AVP}.  The receiver issues an answer with the Result-Code set=
 to
      DIAMETER_MISSING_AVP and creates an AVP with the AVP Code and
      other fields set as expected in the missing AVP.  The created AVP
      is then added to the Failed-AVP AVP.

The remaining part is according to the RFC6733 from my point of view.=


All in all, to set M-bit or not, depends on what reaction you w=
ant to see from RFC4006 server.

/Misha


2017=
-01-30 11:29 GMT+03:00 Yuval Lifshitz <ylifshitz@sandvine.com>=
:











Hi Misha,


We didn=E2=80=99t conside=
r the option of using a bitmap, but I=E2=80=99m open to this idea. IMO, it =
would be more difficult managing the addition of new values in the case
 of a bitmap than in the case of adding new AVPs.=C2=A0 OTOH, adding a bitm=
ap will be less changes to the RFC.


In our proposal the AVPs =
are marked as optional, and the M-bit *may* be set. I sent an explan=
ation to Maryse on the M-bit =E2=80=93 please see below, and let
 me know if you have comments on that.


As ABNF cannot show the c=
oncept of =E2=80=9Cone and only one AVP=E2=80=9D I will update the text to =
state that explicitly (added:
https://github.com/lbertz02/rfc4006bis/issues/18)


=C2=A0


Yuval


=C2=A0


From: Misha Za=
ytsev [mailto:misha.zaytsev.rus@gmail.com]


Sent: Sunday, January 29, 2017 8:21 PM


To: Yuval Lifshitz

Cc: Gardella, Maryse (Nokia - FR); dime@ietf.org

Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP


=C2=A0




Hi Yuval,




=C2=A0






Thanks a lot for your clarifications! Now it seems I=
 see your concern.






=C2=A0






As I can see the problem is that there is no possibi=
lity to extend the defined AVPs of type Enumerated in a backward compatible=
 way. For me it means that all enumerate AVPs defined in RFC4006 (listed in=
 section 12) is a matter of your investigation.
 Not the grouped ones, but the ones that are used as indicators in these gr=
ouped AVPs.






=C2=A0






Following the recommendations in=C2=A0https://tools.ietf.org/html/rfc7423#section-5.6=C2=A0that you pointed out, I think bitmask based
 AVPs may be a way out in the current situation. Such AVP will be marked as=
 mandatory. While only one bit of this bitmask MUST be set.





=C2=A0






=C2=A0=
Subscription-Id-Extension ::=3D < AVP Header: XXX >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-Type-Indicator=C2=A0]=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Subscrition-Id-Data]





Have you considered this option? Or probably I'm missing something..=





=C2=A0






However, if we follow the way you are proposing with=
 several mutually exclusive AVPs, then these AVPs should be marked as not m=
andatory. While in the description of the appropriate grouped AVP it should=
 be stated that only one of these
 AVPs MUST be present.=C2=A0






=C2=A0






/Misha=C2=A0




=C2=A0










=C2=A0




2017-01-29 11:29 GMT+03:00 Yuval Lifshitz <ylifshitz@sandvine.co=
m>:


Hi Misha,

There is nothing =E2=80=9Cwell known=E2=80=9D in these issues and I=E2=80=
=99ll be happy to clarify!



(1) During IETF96 a question came regarding the support of the IMEI user eq=
uipment type =E2=80=93 currently not one of the enumerated types of the Use=
r-Equipment-Info-Type AVP (IMEISV is there but not IMEI). As a result of th=
is discussion, and due to the enum extension
 limitations (see here: 
https://tools.ietf.org/html/rfc7423#section-5.6), we were asked to=
 do an analysis on which enumerated AVPs requires extensibility. The result=
s were captured in the following ticket:
htt=
ps://trac.ietf.org/trac/dime/ticket/95

For better clarity I=E2=80=99m posting here the actual analysis of AVPs. So=
me of them didn=E2=80=99t need to be extensible (in our view), some of them=
 were already extensible and the rest were added to the ticket:



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AVP=C2=A0 Section=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Attribute Name=C2=A0=C2=A0=C2=A0 Code Defined Data Type
=C2=A0=C2=A0=C2=A0-----------------------------------------

=C2=A0=C2=A0 CC-Money=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 413=C2=A0 8.22=C2=A0=C2=A0 Grouped=C2=A0=C2=A0=C2=A0 - not extensible, doe=
s not need to be

=C2=A0=C2=A0 Cost-Information=C2=A0 423=C2=A0 8.7=C2=A0=C2=A0=C2=A0 Grouped=
=C2=A0=C2=A0=C2=A0 - not extensible, does not need to be

=C2=A0=C2=A0 Final-Unit-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 430=C2=A0 8.34=
=C2=A0=C2=A0 Grouped=C2=A0=C2=A0=C2=A0 - not extensible, will be replaced b=
y QoS-Final-Unit-Indication that will be extensible

=C2=A0=C2=A0=C2=A0=C2=A0 Indication=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Granted-Service-=C2=A0 431=C2=A0 8.17=C2=A0=C2=A0 Grouped=
=C2=A0=C2=A0=C2=A0 - extensible

=C2=A0=C2=A0=C2=A0=C2=A0 Unit=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0G-S-U-Pool-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 457=C2=A0=
 8.30=C2=A0=C2=A0 Grouped=C2=A0=C2=A0=C2=A0 - not extensible, does not need=
 to be

=C2=A0=C2=A0=C2=A0=C2=A0 Reference=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Multiple-Services 456=C2=A0 8.16=C2=A0=C2=A0 Grouped=C2=
=A0=C2=A0=C2=A0 - extensible

=C2=A0=C2=A0=C2=A0 -Credit-Control=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Redirect-Server=C2=A0=C2=A0 434=C2=A0 8.37=C2=A0=C2=A0 Gr=
ouped=C2=A0=C2=A0=C2=A0 - not extensible, has a problem similar to equipmen=
t type as it contains an enumerated type/value AVPs

=C2=A0=C2=A0 Requested-Service 437=C2=A0 8.18=C2=A0=C2=A0 Grouped=C2=A0=C2=
=A0=C2=A0 - extensible

=C2=A0=C2=A0=C2=A0=C2=A0 -Unit=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0

=C2=A0=C2=A0=C2=A0Service-Parameter 440=C2=A0 8.43=C2=A0=C2=A0 Grouped=C2=
=A0=C2=A0=C2=A0 - not extensible, does not need to be

=C2=A0=C2=A0=C2=A0=C2=A0 -Info=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0

=C2=A0=C2=A0=C2=A0Subscription-Id=C2=A0=C2=A0 443=C2=A0 8.46=C2=A0=C2=A0 Gr=
ouped=C2=A0=C2=A0=C2=A0 - not extensible, has a problem similar to equipmen=
t type as it contains an enumerated type/value AVPs

=C2=A0=C2=A0 Unit-Value=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 445=C2=A0=
 8.8=C2=A0 =C2=A0=C2=A0Grouped=C2=A0=C2=A0=C2=A0 - not extensible, does not=
 need to be

=C2=A0=C2=A0 Used-Service-Unit 446=C2=A0 8.19=C2=A0=C2=A0 Grouped=C2=A0=C2=
=A0=C2=A0 - extensible

=C2=A0=C2=A0 User-Equipment=C2=A0=C2=A0=C2=A0 458=C2=A0 8.49=C2=A0=C2=A0 Gr=
ouped=C2=A0=C2=A0=C2=A0 - not extensible, will be replaced by an AVP that w=
ill be extensible

=C2=A0=C2=A0=C2=A0=C2=A0 -Info=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0



Would appreciate your comments if you think differently about any of the AV=
Ps above, or that we have missed other AVPs that needs to.



(2) E.g adding new subscription ID.



Unlike Subscription-Id-Type AVP which cannot be extended to a new type with=
out a new application ID, a new AVP being proposed in RFC4006bis is:



=C2=A0 Subscription-Id-Extension ::=3D < AVP Header: XXX >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-E164 ]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-IMSI ]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-SIP-URI ]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-NAI ]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ Subscription-Id-Private ]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0*[ AVP ]



So, in order to add a new type (post RFC4006bis), you would need to submit =
draft with an AVP definition in it to could be added to the Subscription-Id=
-Extension as it is extensible.

This new draft would be compliant with RFC4006bis and will therefore not re=
quire a new application ID.



Best Regards,



Yuval





From: Misha Zaytsev [mailto:misha.zaytsev.rus@gmail.com]

Sent: Saturday, January 28, 2017 11:07 PM

To: Yuval Lifshitz

Cc: Gardella, Maryse (Nokia - FR); dime@ietf.org

Subject: Re: [Dime] RFC4006bis - Subscription-Id-Extension AVP








Hi Yuval,



May I ask you several questions to be able to understand the whole situatio=
n:



1. Why are you proposing to add new extendable AVPs only for some of the AV=
Ps listed in section 12?

I think the same concern is applicable for all these AVPs, isn't?



2. Could you clarify what official procedure to assign new available values=
 is meant here?

It is not working w/o defining new Application-ID as you mentioned above?




12.16.=C2=A0 Subscription-Id-Type AVP



=C2=A0 =C2=A0As defined in Section 8.47, the Subscription-Id-Type AVP inclu=
des

=C2=A0 =C2=A0Enumerated type values 0 - 4.=C2=A0 IANA has created and is ma=
intaining a

=C2=A0 =C2=A0namespace for this AVP.=C2=A0 All remaining values are availab=
le for

=C2=A0 =C2=A0assignment by a Designated Expert [RFC2434].



Excuse me in advance if what I'm asking about are well-known things.
But still please clarify them at least for me...



Thanks a lot in advance!



/Misha



2017-01-25 11:29 GMT+03:00 Yuval Lifshitz <ylifshitz@sandvine.com>:

Hi Maryse,

The idea is the following:

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the CC client =
want to work with RFC4006bis only CC server, and want to make sure that the=
 subscription ID is understood by the server, it may set the M-bit. Any RFC=
4006 server will reply with DIAMETER_AVP_UNSUPPORTED (5001)

=E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the CC client =
is not sure whether the CC servers are RFC4006 or RFC4006bis, or have a mix=
 of servers, and want to work with both, it may not set the M-bit

o=C2=A0=C2=A0 In this case it would send both AVPs for the old types, so th=
at the new AVP will be ignored by the RFC4006 servers

o=C2=A0=C2=A0 In a case of a new type of subscription, not covered in RFC40=
06, it may send the new AVP with the M-bit set, causing any old server to r=
eply with DIAMETER_AVP_UNSUPPORTED (5001). It may also send the new AVP wit=
hout the M-bit set, here the server would
 just ignore the AVP, but would probably reply DIAMETER_MISSING_AVP (5005) =
as it will not have any subscription ID

=C2=A0

Yuval

=C2=A0

From: Gardella, Maryse (Nokia - FR) [mailto:maryse.gardella@nokia.com]

Sent: Tuesday, January 24, 2017 5:25 PM

To: Yuval Lifshitz; dime=
@ietf.org

Subject: RE: RFC4006bis - Subscription-Id-Extension AVP

=C2=A0

Hi Yuval,

=C2=A0

Thanks for continuing on this.

I am not sure to understand the difference between =E2=80=9Cmay=E2=80=9D an=
d =E2=80=9Cmust=E2=80=9D, since with =C2=A0=E2=80=9CMay=E2=80=9D we can end=
 having the M-bit set by the RFC4006bis CC client.

I guess from the protocol=E2=80=99s perspective =E2=80=9Cmay=E2=80=9D and =
=E2=80=9Cmust=E2=80=9D makes no difference right?

=C2=A0

BR

Maryse

=C2=A0

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz

Sent: vendredi 13 janvier 2017 15:24

To: dime@ietf.org
Subject: [ALU] [Dime] RFC4006bis - Subscription-Id-Extension AVP

=C2=A0

Hi All,

As part of the RFC4006bis work there are several AVPs that we plan on makin=
g future proof (See also:
htt=
ps://trac.ietf.org/trac/dime/ticket/95). For example, Subscription=
-Id AVP cannot be extended to new types without changing the enumeration in=
 Subscription-Id-Type AVP, which in turn
 requires a new application ID (something we really want to avoid).

To solve this issue we propose adding a new, extendable AVP. In this exampl=
e:

=C2=A0

Subscription-Id-Extension ::=3D < AVP Header: XXX >

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 [ Subscription-Id-E164 ]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 [ Subscription-Id-IMSI ]

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0[ Subscription-Id-SIP-URI ]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 [ Subscription-Id-NAI ]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 [ Subscription-Id-Private ]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 *[ AVP ]

=C2=A0

When looking into Subscription-ID-Extension AVP =C2=A0header flags I ran in=
to a problem. The existing Subscription-ID AVP (and its sub-AVPs) are all m=
arked with the M-bit as a =E2=80=9Cmust=E2=80=9D, probably because they hol=
d the subscriber=E2=80=99s name which is critical information.

However, in order for a RFC4006bis CC client to be able to communicate with=
 an RFC4006 CC-server, they will have to be marked as =E2=80=9Cmay=E2=80=9D=
.

=C2=A0

Would appreciate your point of view on that topic?

=C2=A0

Best Regards,

=C2=A0

Yuval

=C2=A0



_______________________________________________

DiME mailing list

DiME@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/dime








=C2=A0












--f403045ea2824b0c950547697a78--


From nobody Tue Jan 31 17:13:32 2017
Return-Path: 
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A071296AA; Tue, 31 Jan 2017 17:13:31 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.41.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148591161114.5931.18258611553220397596.idtracker@ietfa.amsl.com>
Date: Tue, 31 Jan 2017 17:13:31 -0800
Archived-At: 
Cc: dime-chairs@ietf.org, dime@ietf.org, jounikor@gmail.com
Subject: [Dime] dime - New Meeting Session Request for IETF 98
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Feb 2017 01:13:31 -0000

A new meeting session request has just been submitted by Jouni Korhonen, a Chair of the dime working group.


---------------------------------------------------------
Working Group Name: Diameter Maintenance and Extensions
Area Name: Operations and Management Area
Session Requester: Jouni Korhonen

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 150
Conflicts to Avoid: 
 First Priority:  detnet tsvwg tsvarea quic iccrg
 Second Priority: 6man v6ops  intarea 



People who must be present:
  Stephen Farrell
  Lionel Morand
  Jouni Korhonen

Resources Requested:
  Meetecho support in room

Special Requests:
  
---------------------------------------------------------